Are Kubernetes Secrets encrypted by default? No, and how to fix it

No. The Kubernetes documentation states that by default the API server stores plain text representations of resources in etcd, with no at-rest encryption. To change that you pass an EncryptionConfiguration file to the API server, then rewrite existing Secrets so they are stored encrypted.

What the default looks like

The default provider is called identity. The docs say plainly that it provides no confidentiality protection. Anyone who can read an etcd snapshot or backup can read your Secrets, and that includes a stolen disk image or a copied backup file.

Managed Kubernetes services often handle this layer for you, but the setting and the key custody differ by provider. Check your provider's documentation rather than assuming.

How EncryptionConfiguration works

You give the kube-apiserver a configuration file through a flag. The file lists resources, and each resource entry has an ordered list of providers.

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: BASE64_ENCODED_32_BYTE_KEY
      - identity: {}

The first provider in the list encrypts every write. On reads, each provider is tried in order until one can decrypt the data. That is why identity sits last: it lets the server read old plain text objects while new writes are encrypted.

The API server flag that points to this file is shown below.

kube-apiserver --encryption-provider-config=/etc/kubernetes/enc.yaml

Local keys versus an external KMS

The aescbc, aesgcm and secretbox providers keep their keys in the configuration file on the control plane host. The docs note that anyone who can read that file and etcd can decrypt the data. A KMS provider keeps the key in an external key management service, which separates the two. The fetched page example is marked as not for production, so read the current provider guidance before choosing.

Verify and rewrite

Turning encryption on only affects objects written afterwards. To check, read the raw etcd entry and look at the stored prefix.

ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 | hexdump -C

An encrypted value starts with a prefix such as k8s:enc:aescbc:v1:key1. Readable text means it is not encrypted.

To encrypt what is already stored, rewrite every Secret.

kubectl get secrets --all-namespaces -o json | kubectl replace -f -

Once everything is rewritten and verified, remove identity from the provider list so plain text can no longer be read back.

What encryption at rest does not do

It does not stop a user with RBAC permission to read Secrets, because the API server decrypts for authorized callers. Pair it with tight access rules, covered in who can read Kubernetes Secrets.

Quick check

Sources

• Encrypting Confidential Data at Rest, Kubernetes documentation
• Good practices for Kubernetes Secrets

Last reviewed: 19 October 2026.