nebari-dev
[BUG] - Nebari attempts to use an existing KMS even if its not configured
Describe the bug
I am using Nebari with AWS, and in my region I have KMS's owned by IAM roles, which nebari deployment does not have access to and should not.
Even though I have not defined amazon_web_services: eks_kms_arn in the config, Nebari attempts to reuse a KMS. (We have multiple KMS configured in that region, it appears to attempt to use the first kms returned by aws kms list-keys --region <myregion>)
ClientError: An error occurred (AccessDeniedException) when calling the DescribeKey operation: User: arn:aws:iam::<myuser> is not authorized to perform: kms:DescribeKey on resource: arn:aws:kms:us-west-2:<key arn> because no resource-based policy allows the kms:DescribeKey action
Workaround:
Deploying to a region without any existing KMS keys works—Nebari creates and uses a new one successfully. But when we go to production, we will need to deploy to a region that has multiple KMS already set up that nebari should not use.
Expected behavior
If amazon_web_services.eks_kms_arn is not explicitly set, Nebari should not attempt to reuse any existing KMS keys that are not created as part of the current deployment.
I don't know if there is a way to detect whether a KMS is managed by nebari, so an acceptable alternative would be a blacklist of KMS arns to specifically not use.
OS and architecture in which you are running Nebari
fedora
How to Reproduce the problem?
Deploy nebari with aws to a region with existing KMS restricted to an IAM role that nebari does not have access to.
Hi @asmacdo, thanks for bringing up this bug. A 1 minute look at the source shows the issue is likely around https://github.com/nebari-dev/nebari/blob/ee1db3efea58f64bbe8aa51c74527d5cee122889/src/_nebari/stages/infrastructure/init.py#L639 somewhere. Would you like to take this on? If not we can work on scheduling it for our team.
For our deployment, we will workaround by explicitly setting the KMS to use, so I doubt I'll be able to prioritize time to pick this one up, sorry!