Managing Kubernetes Secrets with External Secrets Operator

Kubernetes provides a native 'Secret' object, but by default, these are merely base64 encoded strings stored in the etcd database. If a developer has read access to the namespace, or if etcd is compromised, the plaintext credentials are easily exposed.

The modern DevOps standard is to utilize an external source of truth, such as AWS Secrets Manager, and sync those credentials into Kubernetes dynamically. The External Secrets Operator (ESO) is a Kubernetes controller that integrates with external APIs to fetch secrets and automatically construct native Kubernetes Secret objects.

This allows applications to consume secrets as environment variables or mounted volumes seamlessly, while the actual rotation and access control policies remain centralized in AWS. To deploy this, you configure a `SecretStore` Custom Resource linking your AWS account, and an `ExternalSecret` defining which specific values to fetch.

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: aws-secrets-manager
  namespace: production
spec:
  provider:
    aws:
      service: SecretsManager
      region: us-east-1
      auth:
        jwt:
          serviceAccountRef:
            name: eso-service-account
---
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
  namespace: production
spec:
  refreshInterval: "1h"
  secretStoreRef:
    name: aws-secrets-manager
    kind: SecretStore
  target:
    name: app-db-secret
  data:
  - secretKey: password
    remoteRef:
      key: prod/database/credentials
      property: password