[EKS] [Feature]: Allow custom KMS keys to encrypt etcd

[Kausheel]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Which service(s) is this request for? EKS

Tell us about the problem you're trying to solve

Currently, the etcd Nodes for EKS are encrypted using AWS controlled KMS keys, as per the below snippet from the documentation:

"All of the data stored by the etcd nodes and associated Amazon EBS volumes is encrypted. Amazon EKS uses master encryption keys that generate volume encryption keys which are managed by the Amazon EKS service." - https://docs.aws.amazon.com/en_us/eks/latest/userguide/clusters.html

However, some users may prefer to implement their own KMS keys for compliance purposes. It seems this currently isn't possible in EKS. This would be a useful feature for users who are interested in adopting EKS but require control over encryption keys for compliance reasons.

Perhaps we could allow users to specify a KMS key as a parameter for CreateCluster() ?

[tabern]

@Kausheel can you give more information on the compliance criteria you cannot meet today? The EKS control plane is compliant with SOC, PCI, HIPAA, etc...

We are working on an additional feature around envelope encryption with CMK for Kubernetes secrets https://github.com/aws/containers-roadmap/issues/530 - would this meet your needs?

[Kausheel]

Thanks for getting back to me @tabern.

The Secrets encryption in #530 looks great, but the use case for what I'm describing in this Issue is more about exposing the KMS configuration for the etcd Nodes to the user.

For example, the RDS Service currently allows users to provide their own KMS Keys for encrypting the database, logs, and snapshots.

An example workflow which RDS offers is to simply run aws create-db-instance --storage-encrypted --kms-key-id. An equivalent workflow for EKS may look something like aws eks create-cluster --kms-key-id xxxx.

ElastiCache and S3 also allow users to encrypt data at rest using customer managed KMS Keys.

I think EKS would benefit from offering this level of control over the KMS Keys used for etcd.

References:

• https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/at-rest-encryption.html
• https://docs.aws.amazon.com/AmazonS3/latest/dev/bucket-encryption.html
• https://docs.aws.amazon.com/kms/latest/developerguide/services-rds.html

[tabern]

@Kausheel check out https://github.com/aws/containers-roadmap/issues/530#issuecomment-595465485 which we just shipped! Can you confirm if this meets your needs? If yes, we can close this issue. Note, this does support adding KMS as part of createCluster.

[Kausheel]

Hi @tabern, the new feature in #530 looks great for encrypting Secrets.

This feature request is more around enabling users to supply the KMS keys for encrypting the entire etcd EBS volume. KMS encryption is already implemented for the EBS volumes of the etcd nodes, as per our documentation which I highlighted above. This feature request is basically for allowing users to supply their own KMS key to encrypt etcd (not just secrets, the whole EBS volume).

Other services like S3, ElastiCache and RDS also offer this type of feature as I've described above. They allow users to implement encryption-at-rest using KMS keys supplied by the user. EKS already implements KMS for encrypting the etcd nodes, what I'm requesting is the ability to pass our own KMS key.

The use case for this may be niche (mainly users interested in compliance I suppose), but I think it would be useful to offer. There seem to be a few upvotes on this issue already so it looks like other users are interested too.