|
| 1 | +--- |
| 2 | +menu: |
| 3 | + learn: |
| 4 | + parent: Patterns quick start |
| 5 | +title: Configuring secrets |
| 6 | +aliases: /infrastructure/using-validated-pattern-operator/ |
| 7 | +weight: 21 |
| 8 | +--- |
| 9 | + |
| 10 | +:toc: |
| 11 | +:imagesdir: /images |
| 12 | +:_content-type: ASSEMBLY |
| 13 | +include::modules/comm-attributes.adoc[] |
| 14 | + |
| 15 | +== What are secrets |
| 16 | + |
| 17 | +Secrets refer to any piece of sensitive information that should not be exposed publicly or handled insecurely. This can include passwords, private keys, certificates (particularly the private parts), database connection strings, and other confidential data. |
| 18 | + |
| 19 | +A simple way to think of secrets is as anything that security teams or responsible system administrators would ensure stays protected and not published in a public space. |
| 20 | + |
| 21 | +== Characteristics and Importance |
| 22 | +Secrets are crucial for the functioning of applications for example database passwords or cache keys. Without access to these secrets, applications may fail or operate in a significantly impaired manner. |
| 23 | + |
| 24 | +Secrets often vary between different deployments of the same application for example separate load balancer certificates for different instances. Using the same secret across multiple deployments is generally discouraged as it increases the risk of exposure |
| 25 | + |
| 26 | +Applications often need secrets to run correctly, making them indispensable. Removing or mishandling secrets can disrupt operations. |
| 27 | + |
| 28 | +== Security and Management Concerns |
| 29 | +Directly storing secrets in Git repositories is problematic as this can lead to accidental exposure. Secrets should be managed securely and kept out of source control systems. |
| 30 | +Secrets can come in many formats and may have various naming conventions (e.g., usernames and passwords might have different labels). Applications can have strict or specific requirements for how secrets are presented, necessitating flexibility in their management. |
| 31 | + |
| 32 | +== Challenges in Handling Secrets |
| 33 | +Secrets must be handled carefully to prevent exposure, especially in a GitOps framework where the desired state is stored as code. While storing non-sensitive information (e.g., container images, version numbers) in a Git repository is safe, secrets require additional security measures. |
| 34 | +Administrators must ensure that different secret formats are managed properly and can be adapted to meet the specific needs of various applications. |
| 35 | + |
| 36 | +== Configuring secrets |
| 37 | + |
| 38 | +Multicloud GitOps is a foundational pattern that demonstrates GitOps principles for managing applications across multiple clusters. It provides: |
| 39 | + |
| 40 | +* A GitOps framework using ArgoCD |
| 41 | +* Infrastructure-as-Code practices |
| 42 | +* Multi-cluster management capabilities |
| 43 | +* Template for secure secret management |
| 44 | + |
| 45 | +The Multicloud GitOps pattern is recommended as your first pattern because: |
| 46 | + |
| 47 | +. It establishes core GitOps practices |
| 48 | +. Provides a minimal but complete implementation |
| 49 | +. Serves as a foundation for other patterns |
| 50 | +. Demonstrates key validated patterns concepts |
| 51 | + |
| 52 | +[NOTE] |
| 53 | +==== |
| 54 | +Other patterns build upon these concepts, making this an ideal starting point for your validated patterns journey. |
| 55 | +==== |
| 56 | + |
| 57 | +== Deploying the Multicloud GitOps pattern |
| 58 | + |
| 59 | + |
| 60 | + |
| 61 | +//Include Procedure module here |
| 62 | +[id="installing-validated-patterns-operator_{context}"] |
| 63 | +== Installing the {validated-patterns-op} |
| 64 | + |
| 65 | + |
| 66 | +//Include Procedure module here |
| 67 | +[id="create-pattern-instance_{context}"] |
| 68 | +== Creating the Multicloud GitOps instance |
| 69 | + |
| 70 | +. |
0 commit comments