What is a potential risk when using secrets in Kubernetes?

What is a potential risk when using secrets in Kubernetes?

• A. Secrets are always encrypted at rest.
• B. If someone gains access to etcd or retrieves the secret as yaml, they could potentially get the value.
• C. Secrets are never at risk if etcd is compromised.
• D. Secret values are automatically rotated by Kubernetes.

Answer: (B)

The risk comes from how Kubernetes stores secret data. Secrets are kept in etcd, and by default they are only base64-encoded, not encrypted. If someone gains access to etcd directly, or can retrieve the secret’s YAML representation from the API, they can decode or read the secret value. Enabling encryption at rest for etcd and strictly controlling who can read secrets (RBAC, API access) are essential to reduce this risk. The other statements aren’t accurate: encryption at rest isn’t guaranteed by default, etcd compromise can expose secrets, and Kubernetes doesn’t automatically rotate secret values.

The risk comes from how Kubernetes stores secret data. Secrets are kept in etcd, and by default they are only base64-encoded, not encrypted. If someone gains access to etcd directly, or can retrieve the secret’s YAML representation from the API, they can decode or read the secret value. Enabling encryption at rest for etcd and strictly controlling who can read secrets (RBAC, API access) are essential to reduce this risk. The other statements aren’t accurate: encryption at rest isn’t guaranteed by default, etcd compromise can expose secrets, and Kubernetes doesn’t automatically rotate secret values.