Questão de Kubernetes Security #019e3a4f

Summary

The correct statement is that Secrets data is base64 encoded and stored unencrypted by default. This is a common misconception: while base64 encoding obfuscates the data, it does not provide encryption. Kubernetes Secrets are stored in etcd, and unless encryption at rest is explicitly configured, the data is stored as plaintext (base64 decoded) in etcd.

How it Works

Kubernetes Secrets are designed to store sensitive information such as passwords, tokens, and keys. When you create a Secret, the data is base64 encoded for transport and storage in the Kubernetes API. However, base64 is not encryption; it is simply an encoding scheme that can be easily reversed. By default, Secrets are stored unencrypted in etcd, the cluster's key-value store. This means anyone with access to etcd can read the Secret data. To protect Secrets at rest, you must enable encryption at rest by configuring the EncryptionConfiguration resource and specifying a provider like aescbc or kms.

Why the Correct Statement is Right

• Secrets data is base64 encoded and stored unencrypted by default: This is accurate. The base64 encoding is applied to allow binary data to be represented as a string in YAML/JSON manifests. However, no encryption is applied by default. The data can be decoded easily, and it is stored as plaintext in etcd unless encryption at rest is enabled.

Why the Incorrect Statements are Wrong

• A Secret is part of a Pod specification: This is incorrect. A Secret is a separate Kubernetes API object that is referenced by a Pod specification. The Pod spec can reference a Secret via environment variables or volume mounts, but the Secret itself is not defined within the Pod spec.

• Secrets data is encrypted with the cluster private key by default: This is false. Kubernetes does not encrypt Secrets by default. While some distributions or cloud providers may enable encryption by default, the upstream Kubernetes default is no encryption. The cluster private key is not used for Secret encryption; encryption at rest requires explicit configuration.

• A Secret can only be used for confidential data: This is misleading. While Secrets are intended for sensitive data, there is no technical restriction preventing their use for non-confidential data. However, best practice is to use ConfigMaps for non-sensitive configuration data and Secrets for sensitive data. The statement is not entirely correct because Secrets can technically store any data, but they are designed for confidential information.