Decrypting Kubernetes API Data Encrypted at Rest

--- title: Decrypt Confidential Data that is Already Encrypted at Rest content_type: task weight: 215 ---  All of the APIs in Kubernetes that let you write persistent API resource data support at-rest encryption. For example, you can enable at-rest encryption for {{< glossary_tooltip text="Secrets" term_id="secret" >}}. This at-rest encryption is additional to any system-level encryption for the etcd cluster or for the filesystem(s) on hosts where you are running the kube-apiserver. This page shows how to switch from encryption of API data at rest, so that API data are stored unencrypted. You might want to do this to improve performance; usually, though, if it was a good idea to encrypt some data, it's also a good idea to leave them encrypted. {{< note >}} This task covers encryption for resource data stored using the {{< glossary_tooltip text="Kubernetes API" term_id="kubernetes-api" >}}. For example, you can encrypt Secret objects, including the key-value data they contain. If you wanted to manage encryption for data in filesystems that are mounted into containers, you instead need to either: - use a storage integration that provides encrypted {{< glossary_tooltip text="volumes" term_id="volume" >}} - encrypt the data within your own application {{< /note >}} ## {{% heading "prerequisites" %}} * {{< include "task-tutorial-prereqs.md" >}} * This task assumes that you are running the Kubernetes API server as a {{< glossary_tooltip text="static pod" term_id="static-pod" >}} on each control plane node. * Your cluster's control plane **must** use etcd v3.x (major version 3, any minor version). * To encrypt a custom resource, your cluster must be running Kubernetes v1.26 or newer. * You should have some API data that are already encrypted. {{< version-check >}}  ## Determine whether encryption at rest is already enabled By default, the API server uses an `identity` provider that stores plain-text representations of resources. **The default `identity` provider does not provide any confidentiality protection.** The `kube-apiserver` process accepts an argument `--encryption-provider-config` that specifies a path to a configuration file. The contents of that file, if you specify one, control how Kubernetes API data is encrypted in etcd. If it is not specified, you do not have encryption at rest enabled. The format of that configuration file is YAML, representing a configuration API kind named [`EncryptionConfiguration`](/docs/reference/config-api/apiserver-config.v1/). You can see an example configuration in [Encryption at rest configuration](/docs/tasks/administer-cluster/encrypt-data/#understanding-the-encryption-at-rest-configuration). If `--encryption-provider-config` is set, check which resources (such as `secrets`) are configured for encryption, and what provider is used. Make sure that the preferred provider for that resource type is **not** `identity`; you only set `identity` (_no encryption_) as default when you want to disable encryption at rest. Verify that the first-listed provider for a resource is something **other** than `identity`,

This document provides instructions on how to switch from encrypting Kubernetes API data at rest to storing it unencrypted. It emphasizes that this task is specifically for data stored via the Kubernetes API (e.g., Secrets) and not for data in filesystems mounted into containers, which require different encryption methods. It covers prerequisites such as running the API server as a static pod, using etcd v3.x, and having encrypted API data already. It also details how to determine whether encryption at rest is already enabled and how the `identity` provider is used by default, which means no encryption.