Configuring secrets

What are secrets

Sensitive information referred to as secrets 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.

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.

Secrets are crucial for the functioning of applications for example database passwords or cache keys. Without access to these secrets, applications might fail or operate in a significantly impaired manner.

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

Applications often need secrets to run correctly, making them indispensable. Removing or mishandling secrets can disrupt operations.

How Validated Patterns implements secrets management

Validated Patterns supports the tokenization approach for secret management. Tokenization involves keeping actual secret values out of version control (for example git) by using tokens or references that can pull secrets from secure storage during runtime. An external storage system pulls the real secrets at runtime.

This approach requires integration with external secret management systems some examples of which are HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and CyberArk’s Conjur.

The External Secrets Operator (ESO) is integral to the validated patterns framework, enabling secure secret management by fetching secrets from various secret stores and projecting them into Kubernetes namespaces. ESO supports integration with providers such as HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP, IBM Secrets Manager, and others.

ESO

Supports a range of secret providers, ensuring no vendor lock-in.
Keeps secrets out of version-controlled repositories, using token references in Git instead.
Allows teams to manage secrets securely while maintaining efficient Git workflows.

As of November 15, 2024, ESO is not officially supported by Red Hat as a product.

ESO’s custom file format and utilities streamlines secret management by allowing file references and supporting encrypted secret storage. The design prioritizes security through multi-layer encryption and simplifies key management. In particular the ini key type is especially helpful for handling AWS credentials, where mismanagement could lead to unauthorized use and potential financial or operational issues.

Validated Patterns primary backend secret store is HashiCorp Vault. HashiCorp Vault acts as a centralized service for securely managing secrets, such as passwords, API keys, and certificates.

Unlike other secret management systems tied to specific cloud providers for example AWS Secrets Manager or Azure Key Vault, Vault can be deployed across different clouds, on bare-metal systems, and in hybrid environments. This cross-platform support made it a popular and practical choice for maintaining a consistent secrets management strategy.

Secret management in validated patterns follows GitOps best practices while maintaining security. Here’s how to configure your secrets:

Using Vault for Secret Management

Access the Vault instance deployed by the pattern.
1. Click the nine box in the UI, choose the Vault and you are taken to the Vault’s UI.
2. Log in with the root token from the vaultkeys secret in the imperative space. Retrieve this be running the following command:
  $ oc extract -n imperative secret/vaultkeys --to=- --keys=vault_data_json 2>/dev/null | jq -r ".root_token"

Adding a Secret to the Multicloud GitOps Pattern

Follow these steps add a new secret to your forked local branch:

Navigate to the Multicloud GitOps pattern repository by running the following command:
```
$ cd <repository-name>
```
Switch to the branch you created in "Getting Started with Multicloud GitOps" by running the following command:
```
$ git checkout my-branch
```
Edit the existing ~/values-secret-multicloud-gitops.yaml
```
$ vi ~/values-secret-multicloud-gitops.yaml
```

Add the following block to define a new top-level secret called mysecret:

secrets:
  - name: mysecret
    vaultPrefixes:
    - global
    fields:
    - name: foo
      onMissingValue: generate
    - name: bar
      onMissingValue: generate

Load the secrets into the Vault by running the following command:
```
$ ./pattern.sh make load-secrets
```
Verify the secret in the Vault UI.
1. Access the Vault’s web UI.
2. From the Dashboard menu navigate to the secret/ secrets engine where your secrets are stored.
3. Expand the global folder.
4. Verify that the mysecret entry exists and contains the foo and bar fields with auto-generated values.

Creating a new external secret in OpenShift GitOps

Follow these steps to create and deploy a new external secret in your GitOps repository.

Navigate to the charts/all/config-demo/templates directory in your repository:
```
$ cd charts/all/config-demo/templates
```
Create a new YAML file named mysecret-external-secret.yaml:
```
$ vi mysecret-external-secret.yaml
```
Open the file in your preferred text editor:
```
$ vi mysecret-external-secret.yaml
```

Add the following content to define a new external secret using the format of the existing template:

---
apiVersion: "external-secrets.io/v1beta1"
kind: ExternalSecret
metadata:
  name: config-demo-mysecret (1)
  namespace: config-demo
spec:
  refreshInterval: 15s (2)
  secretStoreRef: (3)
    name: {{ .Values.secretStore.name }}
    kind: {{ .Values.secretStore.kind }}
  target:
    name: config-demo-mysecret
    template:
      type: Opaque
  dataFrom: (4)
  - extract:
      key: {{ .Values.configdemomysecret.key }}

1	Specifies the name of the new secret to be created in the `config-demo` namespace.
2	Sets how frequently the external secret is refreshed.
3	References the Vault or secret store as defined in the Helm values.
4	Uses `extract` to source all key-value pairs from the specified key in the Vault.

Edit the chart’s values.yaml file to reflect this new external secret:

$ vi ~/multicloud-gitops/charts/all/config-demo/values.yaml

Add the following content:

configdemomysecret:
  key: secret/data/global/config-demo

Add the new file to git:

$ git add .

Commit your changes:

$ git commit -m "Added mysecret-external-secret to create mysecret-secret in config-demo"

Push your branch to the origin of your fork:
```
$ git push origin my-branch
```

Ensure that ArgoCD is monitoring the charts/all/config-demo directory.
Wait for ArgoCD to synchronize and apply the new changes. You can observe the synchronization status in the ArgoCD web UI.
The new config-demo-mysecret should be created and visible in the config-demo project, populated with the relevant data extracted from the Vault.
Verify the secret in the Cluster:
1. Once ArgoCD has applied the changes, verify that the config-demo-mysecret has been created in the config-demo namespace:
  $ oc get secret config-demo-mysecret -n config-demo
2. Check the contents of the secret if necessary:
  $ oc describe secret config-demo-mysecret -n config-demo
  Expected output
  NAME TYPE DATA AGE config-demo-mysecret Opaque 1 25s
3. In the OpenShift Container Platform web console, select the config-demo Project.
4. Select the config-demo-mysecret to review the secret details.

Next Steps

Explore the deployed components in your OpenShift console
Review the GitOps repositories created by the pattern
Try modifying the configuration to understand the GitOps workflow
Consider exploring other validated patterns that build on this foundation

Remember to consult the official documentation at Validated Patterns for detailed information about specific features and advanced configurations.