Course contentsShow
← Docker, Kubernetes & CI/CD
Lesson 312 of 8025. Advanced Kubernetes ConfigurationFree lesson

Enabling Encryption at Rest for Etcd

Configure the Kubernetes API server to use encryption providers to secure sensitive data stored within the underlying etcd database.

In this lesson, you will learn how to protect your cluster's sensitive data by enabling encryption at rest for the etcd database, ensuring that even if your storage media is compromised, your secrets remain unreadable.

Why Encrypt at Rest?

By default, Kubernetes stores data, including Secrets, in etcd as plain text. If an attacker gains unauthorized access to the etcd data files or creates a snapshot of the volume, they can easily read your sensitive credentials. Enabling encryption at rest adds a layer of security by using an encryption provider to scramble this data before it is written to the database.

Configuring the API Server

Encryption is managed by the Kubernetes API server. You provide a configuration file, known as an EncryptionConfiguration object, which instructs the API server on how to encrypt data.

To enable this, you must update the API server manifest file on your control plane node to include the --encryption-provider-config flag, pointing to your config file:

# Example snippet for the API Server configuration
--encryption-provider-config=/etc/kubernetes/enc/enc-config.yaml

Inside your enc-config.yaml file, you define the encryption key and the providers (like aescbc or secretbox) that the API server will use:

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

How It Works

When you create a new Secret, the API server consults this configuration and encrypts the value using the provided key before sending it to etcd. When you request the Secret later, the API server transparently decrypts it. The identity provider is included as a fallback—it ensures that any existing data not yet encrypted remains accessible, though you should migrate those secrets to the new encrypted format to ensure total security.

Key Takeaway: Enabling encryption at rest transforms sensitive data stored in etcd from plain text into an encrypted format, providing a critical security barrier against unauthorized physical or filesystem access.