Skip to content

Conversation

@satra
Copy link
Contributor

@satra satra commented Jun 13, 2025

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

  • 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 satra requested a review from a team as a code owner June 13, 2025 12:19
@satra satra requested review from dcmcand and viniciusdc and removed request for a team June 13, 2025 12:19
@marcelovilla
Copy link
Member

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.

@viniciusdc
Copy link
Contributor

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.

@satra
Copy link
Contributor Author

satra commented Jul 23, 2025

@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).

@viniciusdc
Copy link
Contributor

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.

Annotation for our "manual patch queue":

  PR: nebari-dev#3071
@yarikoptic yarikoptic force-pushed the fix/unauthorized-kms branch from c04e775 to 6307c4c Compare October 2, 2025 15:32
@yarikoptic
Copy link
Contributor

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

yarikoptic pushed a commit to asmacdo/nebari that referenced this pull request Oct 2, 2025
Annotation for our "manual patch queue":

  PR: nebari-dev#3071
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: New 🚦

Development

Successfully merging this pull request may close these issues.

4 participants