Skip to main content
Version: Next

External Secrets Operator Example configuration

The External Secrets Operator (ESO) is a Kubernetes Operator that automates the process of retrieving secrets from external secret management systems (e.g., HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) and injecting them into Kubernetes Secrets. It simplifies secret management by keeping Kubernetes Secrets synchronized with external stores, eliminating manual updates and ensuring consistency.

How to Configure External Secrets Operator to Sync Secrets from Vault​

The following example configuration for ESO is configured to fetch and sync secrets from Vault. This assumes that Vault has already been set up with the following example values:

  • An access endpoint https://vault.build.test.smoothglue.io
  • A Key-Value (KV) secrets engine enabled at path eks-eso to store secrets (which ESO will then sync to the target Kubernetes cluster as Kubernetes Secrets)
  • A secret sg-cloud-test-run/namespaces/testorg01/testsecret in this secrets engine, whose key boo and value car needs to be synced by ESO to a Kubernetes Secret example in the target cluster namespace testorg01
  • A JSON Web Token (JWT) based authentication backend jwt-eks-sg-cloud-test-run that is used by ESO to authenticate to Vault; it has an associated role eks-eso-sg-cloud-test-run for ESO to use
  1. Create a SecretStore resource on the target cluster, which defines how ESO should connect to and authenticate with Vault:
  • kubectl apply -f SecretStore.yaml, where SecretStore.yaml has the following contents:
apiVersion: external-secrets.io/v1
kind: SecretStore
metadata:
  name: vault
  namespace: testorg01
spec:
  provider:
    vault:
      auth:
        jwt:
          kubernetesServiceAccountToken:
            audiences:
            - https://vault.build.test.smoothglue.io
            serviceAccountRef:
              name: default
          path: jwt-eks-sg-cloud-test-run
          role: eks-eso-sg-cloud-test-run
      path: eks-eso
      server: https://vault.build.test.smoothglue.io
      version: v2
  1. Create an ExternalSecret resource on the target cluster, which defines how ESO should synchronize secrets from Vault into a native Kubernetes Secret resource:
  • kubectl apply -f ExternalSecret.yaml, where ExternalSecret.yaml has the following contents:
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: example
  namespace: testorg01
spec:
  data:
  - remoteRef:
      conversionStrategy: Default
      decodingStrategy: None
      key: sg-cloud-test-run/namespaces/testorg01/testsecret
      metadataPolicy: None
      property: boo
    secretKey: exampleKey
  refreshInterval: 15s
  secretStoreRef:
    kind: SecretStore
    name: vault
  target:
    creationPolicy: Owner
    deletionPolicy: Retain
    name: example
  1. Validate the contents of the synced Kubernetes Secret on the target cluster, to ensure its key and value match what was configured in Vault.
  • kubectl get secret -n testorg01 example -oyaml
apiVersion: v1
data:
  exampleKey: Y2Fy
kind: Secret
...

$ echo "Y2Fy" | base64 -d
car

Configuration For Using Vault With Custom Certificate Authority Certificates​

If the Vault instance that ESO is syncing secrets from has a certificate signed by a custom Certificate Authority (CA), then you will need to configure ESO to use that custom CA certificate as explained below. Note that this is not required if the Vault certificate is signed by a public CA.

  1. Create a secret (named for example cacerts) in the external-secrets namespace that has the base64 encoded certificate of the CA.

  2. Add the following to your bigbang-values.yaml in order to add this certificate to the ESO trusted certificate chain.

addons:
  externalSecrets:
    enabled: true
    values:
      extraVolumeMounts:
      - mountPath: /etc/ssl/certs
        name: cacert
      extraVolumes:
      - name: cacert
        secret:
          defaultMode: 420
          optional: true
          secretName: cacerts