Let’s create a secret called external-secrets, where we will pass the MongoDB credentials in
JSON format. To do so, run the following command:
$ echo -ne \
‘{“MONGO_INITDB_ROOT_USERNAME”: “root”, “MONGO_INITDB_ROOT_PASSWORD”: “itsasecret”}’ \ | gcloud secrets create external-secrets –locations=us-central1 \ –replication-policy=user-managed –data-file=-Created version [1] of the secret [external-secrets].
In the preceding command, we echo a JSON containing MONGO_INITDB_ROOT_USERNAME and PASSWORD directly into the gcloud secrets create command. We have specified a particular location to avoid replicating it in other regions as a cost-saving measure. However, it’s highly recommended to replicate secrets to prevent potential loss in case of a zonal outage. The JSON is stored as a new version of our secret. Secret Manager utilizes versioning for secrets, so any new value assigned to the secret (external-secrets) is versioned and stored within Secret Manager. You can reference a specific version either by its version number or by using the latest keyword to access the most recent version.
As seen in the output, we’ve created the first version of our secret (version 1). Typically, this is done during development and should remain outside the CI/CD process. Instead of storing the Secret resource manifest in your source code repository, you can keep it in Secret Manager.
Now that we’ve created the secret, we must access it within our application. To achieve this, we require a tool to access the secret stored in Secret Manager from the Kubernetes cluster. For this purpose, we will use External Secrets Operator.
Accessing external secrets using External Secrets Operator
External Secrets Operator (https://external-secrets.io/latest/) is a Kubernetes operator used in Kubernetes clusters to manage external secrets securely. It is designed to automate the retrieval and management of secrets stored in external secret stores such as AWS Secret Manager, GCP Secret Manager, Hashicorp Vault, and so on, and inject them into Kubernetes pods as Kubernetes Secrets. Operators are a way to extend Kubernetes functionality and automate tasks.
How it works
External Secrets Operator serves as a bridge between the Kubernetes cluster and external secret management systems. We define an ExternalSecret custom resource within the Kubernetes cluster, which the operator monitors. When an ExternalSecret resource is created or updated, the operator interacts with the external secret store specified in the ClusterSecretStore CRD to retrieve the secret data. It then creates or updates the corresponding Kubernetes Secrets. This process is illustrated in the following diagram:
Figure 13.6 – External Secret Operator
Now, this process has a lot of benefits, some of which are as follows:
- Enhanced Security: Secrets remain in a dedicated, secure secret store
- Automation: Automates the retrieval and rotation of secrets
- Simplified Deployment: Eases the management of secrets within Kubernetes applications
- Compatibility: Works with various external secret stores, making it versatile
Now, let’s go ahead and install External Secrets Operator on our Kubernetes cluster.
