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?
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.
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. https://kubernetes.io/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/
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.
Lastly a tutorial as well: https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating_csi_driver_tutorial.html
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.
Use KMS grant to access to encrypted KMS - CMK S3 bucketasked 3 months ago
[MOVED] How to use openpgp card to store secret access key?asked 6 months ago
Why does api-gw-cache-enabled-and-encrypted require caching for NIST 800-171 compliance?asked 3 months ago
CDK: How to create an encrypted Aurora MySQL-compatible cluster using an un-encrypted snapshotEXPERTasked 4 months ago
Why kubernetes secret needs to be encrypted?asked 14 days ago
greengrass v2 - secret manager - throws "not supported" exceptionasked a year ago
Encrypted VPN Connectivity from VMC on AWS SDDC to On-Premise DCasked 2 months ago
Update CF custom header valueasked 3 months ago
What is Cognito's App Client Secret purpose?Accepted Answerasked 5 years ago
Lightsail instance needs to be constantly rebootedasked 3 months ago