---
menu:
  learn:
    parent: Patterns quick start
title: Configuring secrets
aliases: /infrastructure/using-validated-pattern-operator/
weight: 21
---

:toc:
:imagesdir: /images
:_content-type: ASSEMBLY
include::modules/comm-attributes.adoc[]

== 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.

[NOTE]
====
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.

== Configuring Secrets

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.

.. Click the nine box in the UI, choose the *Vault* and you are taken to the Vault’s UI. 

.. Log in with the root token from the vaultkeys secret in the imperative space. Retrieve this be running the following command:
+
[source,bash]
----
$ 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:
+
[source,terminal]
----
$ cd <repository-name>
----

. Switch to the branch you created in "Getting Started with Multicloud GitOps" by running the following command:
+
[source,terminal]
----
$ git checkout my-branch
----

. Edit the existing `~/values-secret-multicloud-gitops.yaml`
+
[source,terminal]
----
$ vi ~/values-secret-multicloud-gitops.yaml
----

. Add the following block to define a new top-level secret called `mysecret`:
+
[source,yaml]
----
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: 
+
[source,terminal]
----
$ ./pattern.sh make load-secrets
----
If this command fails, for whatever reason, you most likely will not get a helpful error message since we avoid logging sensitive information by default.
In this situation, it's often helpful to run the following command before you try loading the secrets again in order to see a more detailed error message.
[source,terminal]

+
----
$ export EXTRA_PLAYBOOK_OPTS='-e hide_sensitive_output="false" -vvv'
----
*This is intended as a temporary debug measure and should not be part of a normal production workflow since it may very well log secrets to stdout.*

. Verify the secret in the Vault UI.

.. Access the Vault's web UI.

.. From the Dashboard menu navigate to the `secret/` secrets engine where your secrets are stored.

.. Expand the `global` folder. 

.. 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:
+
[source,terminal]
----
$ cd charts/all/config-demo/templates
----

. Create a new YAML file named `mysecret-external-secret.yaml`:
+
[source,terminal]
----
$ vi mysecret-external-secret.yaml
----

. Open the file in your preferred text editor:
+
[source,terminal]
----
$ vi mysecret-external-secret.yaml
----

. Add the following content to define a new external secret using the format of the existing template:
+
[source,yaml]
----
---
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: 
+
[source,terminal]
----
$ vi ~/multicloud-gitops/charts/all/config-demo/values.yaml
----

.. Add the following content: 
+
[source,yaml]
----
configdemomysecret:
  key: secret/data/global/config-demo
----

. Add the new file to git:
+
[source,terminal]
----
$ git add .
----

.. Commit your changes:
+
[source,terminal]
----
$ git commit -m "Added mysecret-external-secret to create mysecret-secret in config-demo"
----

.. Push your branch to the origin of your fork:
+
[source,terminal]
----
$ 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:

.. Once ArgoCD has applied the changes, verify that the `config-demo-mysecret` has been created in the `config-demo` namespace:
+
[source,terminal]
----
$ oc get secret config-demo-mysecret -n config-demo
----

.. Check the contents of the secret if necessary:
+
[source,terminal]
----
$ oc describe secret config-demo-mysecret -n config-demo
----
+
.Expected output
+
[source,terminal]
----
NAME                   TYPE     DATA   AGE
config-demo-mysecret   Opaque   1      25s
----

.. In the OpenShift Container Platform web console, select the *config-demo* *Project*. 

.. Select the *config-demo-mysecret* to review the secret details. 
+
image::multicloud-gitops/config-demo-mysecret.png[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

[IMPORTANT]
====
Remember to consult the official documentation at link:https://validatedpatterns.io/[Validated Patterns] for detailed information about specific features and advanced configurations.
====
