Fix code scanning alert - EKS should have the encryption of secrets enabled

[dcmcand]

Tracking issue for:

• https://github.com/nebari-dev/nebari/security/code-scanning/35

[tylergraff]

@dcmcand the link in the description leads to a 404 page for me. Am I missing permissions to view it?

[joneszc]

@dcmcand @tylergraf

Proposing PR#2723 here to add option for a user to specify a KMS-key ARN in nebari-config.yaml, which will set EKS to encrypt secrets:

amazon_web_services:
  eks_kms_arn: 'arn:aws:kms:us-east-1:010101010:key/3xxxxxxx-xxxxx-xxxxx-xxxxx' 

[viniciusdc]

This relies on the user setting up the KMS key beforehand; I think it is fine to allow users to provide theirs, but I would prefer that Nebari create its own (and manage it) by default. What do you think @dcmcand @joneszc

[tylergraff]

For our use-case, we need to allow organizations to create their own keys to match their own policy, or possibly re-use existing KMS keys. We don't have a use-case for Nebari to create and manage its own key by default, so we are considering that to be out of scope for this issue.

[viniciusdc]

For our use case, we need to allow organizations to create their own keys to match their own policy or possibly reuse existing KMS keys. We don't have a use case for Nebari to create and manage its own key by default, so we consider it out of scope for this issue.

It is entirely understandable. However, IMO, allowing the user to configure custom KMS encryption keys would be another issue.

This issue attempts to solve the problem that the cluster currently does not have any encryption set up by default, which is a security concern. They are similar but address different use cases. The linked PR only addressed the security problem when that flag is passed, which is not a problem if we enforced that policy, but the main concept of Nebari is to be easily deployed by people who don't have a full understanding of Kubernetes and cloud providers.

I would suggest to open a new issue regarding the custom KMS and encryption bits 😄, btw, thanks for the contribution 🚀

[joneszc]

For our use case, we need to allow organizations to create their own keys to match their own policy or possibly reuse existing KMS keys. We don't have a use case for Nebari to create and manage its own key by default, so we are considering that to be out of scope for this issue.

It is entirely understandable, though. IMO, this would be another issue: allowing the user to configure custom KMS encryption keys.

This issue attempts to solve the problem that the cluster currently does not have encryption set up by default, which is a security concern. They are similar but address different use-cases.

@viniciusdc @tylergraff
Do you view it as necessary for Nebari to create an additional KMS key, for EKS?
...in addition to keys created for:

• s3
• terraform-state s3
• mlflow-plugin s3
• DynamoDB--once we get around to securing the DynamoDB table

Could we create a single/global default Nebari KMS key that will likewise facilitate mitigation of the critical "KMS Key With Vulnerable Policy" vulnerabilities, which currently result from the existing Nebari KMS keys?

Also, I created this RFD, focusing on KMS/encryption-related vulnerabilities since they could be resolved as a group with consideration of a global Nebari KMS key.

[Adam-D-Lewis]

More background info: https://docs.aws.amazon.com/eks/latest/userguide/enable-kms.html

[viniciusdc]

@joneszc

Could we create a single/global default Nebari KMS key that will likewise facilitate mitigation of the critical "KMS Key With Vulnerable Policy" vulnerabilities, which currently result from the existing Nebari KMS keys?

I think that's an excellent idea, but I am not entirely sure (without testing) how existing resources from an already deployed Nebari cluster would behave if their underlying KMS key was changed. That would require exploration.

Also, the S3 bucket listed above will be removed in this release as its was not being used by anything.

Also, I created this nebari-dev/governance#55, focusing on KMS/encryption-related vulnerabilities since they could be resolved as a group with consideration of a global Nebari KMS key.

Excelent, I would suggest to update the RFD with a bit more context, likely the same as your previous comment. The idea for a global key can be discussed there. In the mean time, your PR for allowing a custom KMS key entry only partially addresses this issue, so feel free to create a new one e.g [ENH] Allows users to pass custom KMS keys for AWS eks cluster encryption