search

nebari-dev / nebari

🪴 Nebari - your open source data science platform
https://nebari.dev
BSD 3-Clause "New" or "Revised" License
279 stars 90 forks source link

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

Open dcmcand opened 1 month ago

dcmcand commented 1 month ago

Tracking issue for:

tylergraff commented 1 month ago

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

joneszc commented 1 month ago

@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'
image
viniciusdc commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 :smile:, btw, thanks for the contribution :rocket:

joneszc commented 3 weeks ago

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:

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 commented 3 weeks ago

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

viniciusdc commented 3 weeks ago

@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 https://github.com/nebari-dev/governance/issues/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