By using AWS re:Post, you agree to the Terms of Use
/Why kubernetes secret needs to be encrypted?/

Why kubernetes secret needs to be encrypted?


Based on this article (link), Implementing envelope encryption is considered a security best practice for applications that store sensitive data and is part of a defense in depth security strategy.

But from what I know, etcd (where kubernetes secret stored) is part of control plane and control plane is managed by AWS (link). Should it be secure already ? Why do we need to encrypt it?

2 Answers

Everything in the cloud follows shared responsibility model.

Nothing should be assumed secure "already".

etcd is indeed managed by AWS, but AWS does not implement by default additional encryption on top of whatever Kubernetes has.

Secrets is one of the worst names in my opinion in K8s. By default secrets are stored in a base64 encoded format in etcd. It's not safe as it can be decoded very easily.

If it indeed is secret, you should encrypt it before it's being stored in etcd.

Maybe the official document explains this very well -

Kubernetes Secrets are, by default, stored unencrypted in the API server's underlying data store (etcd). Anyone with API access can retrieve or modify a Secret, and so can anyone with access to etcd. Additionally, anyone who is authorized to create a Pod in a namespace can use that access to read any Secret in that namespace; this includes indirect access such as the ability to create a Deployment.
answered 14 days ago
  • hi @Jason_S. thank you for your answer. so person who can exploit this is anyone who is authorized to create a Pod in a namespace.

    I have more question. You mention that "Anyone with API access can retrieve or modify a Secret". What API do you refer to ? Is it API call between pod or something else ?

  • Hi - that would be get GET operation for secrets. It's an API call made to the control plane. You can restrict access through RBAC / ABAC. Of course, you should ALWAYS encrypt secrets regardless of your access policies.


I would suggest (if your use-case applies of course) to consider storing your EKS secrets in AWS Parameter store or AWS Secrets Manager. In both cases, they are the official place for such purpose, as well as the ability to encrypt those secrets with a KMS key (including a CMK key). You can then provide your users or systems access to the secret via access to the KMS key (in order to decrypt the secret) as needed.

More info here:

and here:

Lastly a tutorial as well:

As to why secrets need to be encrypted - Well, from either physical theft of the storage at AWS itself (EKS runs on some disk storage, and if the secrets are not encrypted, they can be potentially retrieved if stolen), or, from the components within EKS (such as etcd, pods, config files, etc) if the access control mechanisms are not done properly. Storing secrets in Parameter Store or Secrets Manager as well as using a KMS key ensures that those secrets are protected from both physical theft and security misconfigurations such as the case with etcd. This is a requirement for many security compliance purposes.

Hope this helps.

answered 13 days ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions