KubernetesHow-ToBeginner · 4 min read

How to Encrypt Secrets in Kubernetes: Simple Guide

To encrypt secrets in Kubernetes, enable Encryption at Rest by configuring the EncryptionConfiguration file and updating the API server to use it. This ensures that secret data stored in etcd is encrypted using providers like aescbc or kms.

📐

Syntax

The encryption configuration file defines how Kubernetes encrypts secrets at rest in etcd. It includes:

apiVersion: The version of the encryption config format.
kind: Always EncryptionConfiguration.
resources: List of Kubernetes resources to encrypt, usually secrets.
providers: Encryption methods in order of preference, e.g., aescbc, kms, or identity (no encryption).

The API server is started with the --encryption-provider-config flag pointing to this file.

yaml

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-encoded-secret-key>
      - identity: {}

💻

Example

This example shows how to create an encryption config file using aescbc and enable it on the API server.

bash

# Create a 32-byte base64 key
head -c 32 /dev/urandom | base64

# Save the output as the secret key in the config file

cat <<EOF > encryption-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-key-from-above>
      - identity: {}
EOF

# Restart kube-apiserver with:
# --encryption-provider-config=/path/to/encryption-config.yaml

# Verify encryption by creating a secret and checking etcd data encrypted

Output

Generated base64 key Created encryption-config.yaml API server restarted with encryption enabled Secrets stored encrypted in etcd

⚠️

Common Pitfalls

Not restarting the API server after adding the encryption config means encryption won't apply.
Using identity provider first disables encryption; it should be last as fallback.
Failing to base64 encode the secret key correctly causes errors.
Not rotating keys properly can cause data access issues.

yaml

Wrong order example:
resources:
  - resources:
      - secrets
    providers:
      - identity: {}
      - aescbc:
          keys:
            - name: key1
              secret: <base64-key>

Right order example:
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-key>
      - identity: {}

📊

Quick Reference

Step	Description
Generate a 32-byte base64 key	Use a secure random generator like head or openssl
Create encryption config file	Define resources and providers in YAML format
Configure API server	Add --encryption-provider-config flag with config file path
Restart API server	Apply changes to enable encryption
Verify encryption	Check etcd data or create secrets to confirm encryption

✅

Key Takeaways

Enable Encryption at Rest by configuring the API server with an encryption provider.

Use a strong base64-encoded key with the aescbc provider for secret encryption.

Always place the identity provider last to avoid disabling encryption.

Restart the kube-apiserver after adding the encryption config to apply changes.

Regularly rotate encryption keys to maintain security.