Closed neoakris closed 1 week ago
If anyone else runs into a similar scenario The following is a snippet of a temporary workaround I'm considering/might use.
import { execSync } from 'child_process'; //work around kms UX issue
import console = require('console'); //can help debug feedback loop
const alias_key_to_lookup = "alias/eks/test";
const cmd = `aws kms list-aliases | jq '.Aliases[] | select(.AliasName == "${alias_key_to_lookup}") | .TargetKeyId'`
const cmd_results = execSync(cmd).toString();
console.log(cmd_results)
//TO DO: never pass un-sanitized input / would need tight input sanitization.
cmd_results = "" if not found cmd_results = "ac97959f-c5fb-4de0-a584-2d741c05ea0b" if found ^-- basically a more graceful failure that's a lot easier to handle with if statement checks.
Hi @neoakris , thanks for requesting and sharing the workaround as well. I think this can be achieved using a flag type variable, say, KeyAliasExists(), which would return false
if its not existing. Your usecase makes sense to me.
However if you would like to contribute, please feel free to follow our contribution guide. I would be marking this feature request as P3 for keeping it open for community contribution as well. Thanks.
You're right a flag makes more sense, it'd be just as effective as a string comparison, yet cleaner.
Thanks for the triage and suggestions.
Hi @khushail @neoakris ,
I have submitted the PR, where the fromLookup
method returns a dummy key if the new option returnDummyKeyOnMissing
is set to true for now.
The reasons for this are:
dummyValue
for when the key was not found when getting the key from the context provider, but the value was not used in the destination process (that's context provider) and an error had been occurred.IgnoreErrorOnMissingContext
has been added to the ContextProvider options and is used.Allowing undefined
in the return value of fromLookup
is a breaking change, so I decided not to do that. I also considered allowing a dummy value to be freely specified (like the SSM Parameter case), but decided against that too as I didn't think there would be many use cases for it.
Of course, we can create a new method that is separate from the fromLookup
method, such as Key.keyAliasExists()
.
However, given the design philosophy of the original code, I thought it would be better to fix it to the correct implementation of fromLookup
.
Please let me know if you have any feedback.
@go-to-k my understanding of what you've said is once implemented/in a live release, if I specify the returnDummyKeyOnMissing option. I'll be able to do an if statement check against 1234abcd-12ab-34cd-56ef-1234567890ab when the key isn't pre-existing that works for me.
Thanks for the update!
That's right!
@go-to-k , your implementation with the existing design is very thoughful. Thanks for your efforts in submitting a PR!
@khushail Thank you! The pr/needs-cli-test-run
label has been attached, what should I do? If I just wait, will the maintainer run the test for me?
@go-to-k , I am not really sure why this label is attached. You could ask in the PR from the maintainer.
Comments on closed issues and PRs are hard for our team to see. If you need help, please open a new issue that references this one.
Comments on closed issues and PRs are hard for our team to see. If you need help, please open a new issue that references this one.
Describe the feature
Here's a code snippet for some context:
Current State of CDK 2.133.0:
[Error at /$STACK_NAME] Could not find any key with alias named eks/test
I tried wrapping the above in try catch logic, but the program still does a hard stop with the above error as soon as it discovers the key doesn't exist.
Feature Request/Proposed Solution:
If no key exists, instead of an error, return undefined. This will make it easier to allow if statements to handle that scenario.
Use Case
While using EKS Blueprints, every time I delete and recreate a cluster (semi-frequently for ephemeral sandbox / test environments), due to its defaults it'll create a new KMS key each time, then on delete I get orphaned kms keys. EKS Blueprints allows passing in a pre-existing kms key to avoid this.
However I'd like to add logic for the following use case:
Basically I wanted to be able to create a function named ensure_existence_of_kms_key_with_alias()
This will allow me to implement logic where when I create a cluster it'll create a kms key, but if I delete and recreate the cluster it'll reuse the original kms key. (This avoids orphaned keys, and is also advantageous in the scenario of if disk backups were ever created using a kms key, then restore might be easier if a consistent kms key were used.)
Other Information
The proposed feature/solution shouldn't be a breaking change.
Acknowledgements
CDK version used
2.133.0 (build dcc1e75)
Environment details (OS name and version, etc.)
MacOS Sonoma 14.6.1