nebari icon indicating copy to clipboard operation
nebari copied to clipboard

fix: handle unauthorized kms keys in the account

Open satra opened this issue 6 months ago • 5 comments

If an account has unauthorized KMS keys, then this section of code fails (describe_key specifically). This merely traps the failure and allows proceeding in those situations.

What does this implement/fix?

Put a x in the boxes that apply

  • [X] Bug fix (non-breaking change which fixes an issue)
  • [ ] New feature (non-breaking change which adds a feature)
  • [ ] Breaking change (fix or feature that would cause existing features not to work as expected)
  • [ ] Documentation Update
  • [ ] Code style update (formatting, renaming)
  • [ ] Refactoring (no functional changes, no API changes)
  • [ ] Build related changes
  • [ ] Other (please describe):

Documentation

  • [ ] For new features or enhancements, a corresponding PR has been opened in the documentation repository (if applicable)
    • Link to docs PR:

Testing

  • [ ] Did you test the pull request locally?
  • [ ] Did you add new tests?

How to test this PR?

Any other comments?

satra avatar Jun 13 '25 12:06 satra

Hey @satra, thanks for opening this PR!

Is this related in any way to #3059? It seems like this might be a workaround for that issue. If so, I’d recommend addressing the root cause directly and ensuring we avoid attempting to access existing KMS keys altogether.

marcelovilla avatar Jun 17 '25 16:06 marcelovilla

Hey @satra, if I understand your use case correctly, this scenario only occurs if you are using pre-existing KMS keys associated with your account, right? The reason for my confusion is that, in theory, all keys used by Nebari should have been created and managed by Terraform during the initial deployment; thus, the ownership should have been maintained correctly.

viniciusdc avatar Jul 23 '25 15:07 viniciusdc

@viniciusdc - we use our main account for all kinds of projects through various iam users and roles. so there are keys already in place from different deployments, not just via nebari. however, this code was iterating over existing keys whether or not the running account had privileges for it. if it found a key it would try to use it, not create one.

in our current deployment we created a key manually and passed it on. i don't know if the code is specific enough to check if a key exists for a specific deployment. (for example we have a production and sandbox deployment).

satra avatar Jul 23 '25 15:07 satra

Thanks for the extra context. I will try to review this whenever I have the chance, though I can't promise it will be ready for this month's release.

viniciusdc avatar Jul 23 '25 16:07 viniciusdc

@satra I rebased , added pointer to this PR into description, and force-pushed

yarikoptic avatar Oct 02 '25 15:10 yarikoptic