Multi-Cloud Secrets Management for SMBs with External Secrets Operator

Secure and simplify secrets across multiple cloud environments. Implement External Secrets Operator in Kubernetes for seamless integration with cloud key vaults.

For Small to Medium-sized Businesses (SMBs) operating in a multi-cloud or hybrid-cloud environment, managing sensitive data like API keys, database credentials, and certificates can quickly become a significant security and operational headache. Storing secrets directly in Kubernetes manifests is a major anti-pattern, and manually syncing them across multiple clusters and cloud provider vaults is error-prone and time-consuming. This is where the Kubernetes External Secrets Operator (ESO) becomes an invaluable tool, enabling seamless integration with external secrets management systems like AWS Secrets Manager, Azure Key Vault, or Google Secret Manager.

This article will guide you through the process of implementing External Secrets Operator in your Kubernetes clusters to establish a robust, automated, and secure multi-cloud secrets management solution. This approach builds upon best practices for securing credentials without enterprise tools, adapting them for a dynamic multi-cloud landscape.

The Challenge of Multi-Cloud Secrets Management

As SMBs grow, so does their infrastructure complexity. Running applications across AWS, Azure, and Google Cloud, or even on-premise, means dealing with disparate secrets management solutions. Each cloud provider offers its own robust vault (e.g., AWS Secrets Manager, Azure Key Vault, GCP Secret Manager), but connecting these to your Kubernetes workloads securely and efficiently across different environments presents several hurdles:

• Manual Syncing: Copying secrets from cloud vaults into Kubernetes Secret objects is a manual process, prone to errors, and creates a security risk by duplicating sensitive data.
• Lack of Centralization: Without a unified approach, teams might create secrets in different vaults, leading to inconsistencies and difficulties in auditing.
• Rotation Complexity: Manual secret rotation is tedious and often neglected, increasing the attack surface.
• Compliance Burden: Ensuring that secrets are managed according to compliance standards (e.g., SOC 2, HIPAA) becomes much harder without automation.

While topics like “securing builds with SBOMs and image signing” address supply chain security, secrets management is a foundational layer often overlooked.

Introducing External Secrets Operator (ESO)

External Secrets Operator is a Kubernetes operator that integrates external secret management systems into Kubernetes. It acts as a bridge, allowing you to define ExternalSecret objects in Kubernetes which reference secrets stored in external vaults. ESO then fetches these secrets and automatically creates or updates native Kubernetes Secret objects with the retrieved data.

Key Benefits of ESO:

• Seamless Integration: Connects directly to various cloud provider secrets managers (AWS, Azure, GCP), HashiCorp Vault, and more.
• Automated Sync: Automatically syncs secrets from external vaults to Kubernetes, eliminating manual intervention.
• Enhanced Security: Secrets never reside permanently in your Git repository and are only materialized as native Kubernetes Secret objects within the cluster when needed.
• Rotation Support: When secrets are rotated in the external vault, ESO automatically fetches the updated values and refreshes the corresponding Kubernetes Secret.
• Multi-Cloud Agnostic: Provides a consistent way to manage secrets regardless of the underlying cloud provider.

Deploying External Secrets Operator in Your Cluster

To begin, you’ll need a Kubernetes cluster and Helm installed. We will deploy ESO using Helm.

Installation with Helm

Add the External Secrets Helm repository:

helm repo add external-secrets https://charts.external-secrets.io
helm repo update

Install the External Secrets Operator:

kubectl create namespace external-secrets
helm install external-secrets external-secrets/external-secrets \
    -n external-secrets \
    --set installCRDs=true

The --set installCRDs=true flag ensures that the Custom Resource Definitions (CRDs) for ExternalSecret, SecretStore, and ClusterSecretStore are installed.

Configuring a SecretStore for AWS Secrets Manager

Once ESO is running, you need to tell it where to find your external secrets. This is done using a SecretStore or ClusterSecretStore resource. A SecretStore is namespaced, while a ClusterSecretStore is cluster-scoped and can be used by ExternalSecret objects in any namespace.

For AWS Secrets Manager, you will need an IAM role with permissions to access your secrets. This role should be assumed by the Kubernetes service account running ESO (or a specific application pod if you configure Workload Identity).

IAM Policy Example (for AWS Secrets Manager)

Create an IAM policy like this:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "secretsmanager:GetSecretValue",
                "secretsmanager:DescribeSecret"
            ],
            "Resource": [
                "arn:aws:secretsmanager:REGION:ACCOUNT_ID:secret:your-secret-name-*"
            ]
        }
    ]
}

Attach this policy to an IAM role that your Kubernetes service account can assume (e.g., via IRSA on EKS or similar mechanisms on other clouds). For simplicity, let us assume the ESO controller itself has the necessary permissions. In a production scenario, use fine-grained IAM roles for each application.

SecretStore Definition

Create a SecretStore to connect to AWS Secrets Manager. Save this as aws-secretstore.yaml:

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: aws-secret-store
  namespace: my-app-namespace
spec:
  provider:
    aws:
      service: SecretsManager
      region: us-east-1
      auth:
        jwt:
          serviceAccountRef:
            name: external-secrets-controller
            namespace: external-secrets

Apply it:

kubectl apply -f aws-secretstore.yaml

This SecretStore tells ESO how to authenticate with AWS Secrets Manager.

Creating an ExternalSecret and Syncing it to Kubernetes

Now, let us define an ExternalSecret that references a secret in AWS Secrets Manager and instructs ESO to create a native Kubernetes Secret from it.

AWS Secrets Manager Secret Example

Imagine you have a secret in AWS Secrets Manager named my-database-credentials with a JSON value like:

{
    "username": "dbuser",
    "password": "***"
}

ExternalSecret Definition

Create my-external-secret.yaml in the my-app-namespace:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: my-app-db-secret
  namespace: my-app-namespace
spec:
  refreshInterval: "1h"
  secretStoreRef:
    name: aws-secret-store
    kind: SecretStore
  target:
    name: my-app-db-credentials
    creationPolicy: Owner
  data:
    - secretKey: db_username
      remoteRef:
        key: my-database-credentials
        property: username
    - secretKey: db_password
      remoteRef:
        key: my-database-credentials
        property: password

Apply this ExternalSecret:

kubectl apply -f my-external-secret.yaml

ESO will now fetch the values from my-database-credentials in AWS Secrets Manager, extract username and password, and create a Kubernetes Secret named my-app-db-credentials in my-app-namespace. You can verify this:

kubectl get secret my-app-db-credentials -n my-app-namespace -o yaml

Conclusion

External Secrets Operator provides a robust and elegant solution for multi-cloud secrets management in Kubernetes. By decoupling secrets from your application manifests and delegating their lifecycle to specialized external vaults, SMBs can significantly enhance their security posture, simplify operations, and ensure compliance. This automation reduces the risk of human error and allows your DevOps teams to focus on delivering value, rather than manually managing sensitive credentials across disparate environments. Embracing tools like ESO is a critical step towards a more mature and secure cloud-native strategy.

Struggling with secrets management or multi-cloud complexity? Book a free 30-minute consultation with our DevOps experts to streamline your operations.