Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added kms:GenerateDataKey action to KMSEncryptPolicy policy #3657

Merged
merged 9 commits into from
Nov 4, 2024

Conversation

elmaimbo
Copy link
Contributor

Issue

#1796 KMSEncryptPolicy cannot be used to encrypt

Description of changes

The KMSEncryptPolicy policy lacks the permission required to encrypt data using a data key. This trivial fix adds the missing permission.

Description of how you validated changes

Copied and pasted the change into the policy on AWS (that had been deployed using SAM), and confirmed that this allowed the encrypt function to work.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Copy link
Contributor

@aaythapa aaythapa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for contributing! Will do a review of this internally

@aaythapa
Copy link
Contributor

aaythapa commented Oct 2, 2024

I see in the issue comments that someone requested these Actions

kms:Encrypt
kms:ReEncrypt*
kms:GenerateDataKey*
kms:DescribeKey

Any reason why we shouldn't include kms:ReEncrypt* and kms:DescribeKey here?

@elmaimbo
Copy link
Contributor Author

elmaimbo commented Oct 3, 2024

I see in the issue comments that someone requested these Actions

kms:Encrypt
kms:ReEncrypt*
kms:GenerateDataKey*
kms:DescribeKey

Any reason why we shouldn't include kms:ReEncrypt* and kms:DescribeKey here?

TBH I wasn't sure what these additional permissions were used for, and rather than adding permissions that might not be needed, I was just trying to resolve my own simple use-case of encrypting a value (i.e. principle of least privilege).

I will change my specification of "kms:GenerateDataKey" to "kms:GenerateDataKey*", to allow the use of all of these encryption functions:

  • kms:GenerateDataKey
  • kms:GenerateDataKeyWithoutPlaintext
  • kms:GenerateDataKeyPair
  • kms:GenerateDataKeyPairWithoutPlaintext

But regarding the others: I think the pertinent question is whether it is more appropriate to include kms:ReEncryptFrom, ReEncryptTo and kms:DescribeKey in the KMSEncryptPolicy definition, or create separate policy definitions for those? (I don't believe I'm qualified to answer that question myself, and TBH I have no need of these additional permissions.)

@elmaimbo
Copy link
Contributor Author

elmaimbo commented Oct 3, 2024

I noticed that almost all other policies listed actions explicitly, rather than using "*" (wildcard), so I've done the same in the latest commit.

@aaythapa
Copy link
Contributor

aaythapa commented Oct 4, 2024

I think the pertinent question is whether it is more appropriate to include kms:ReEncryptFrom, ReEncryptTo and kms:DescribeKey in the KMSEncryptPolicy definition, or create separate policy definitions for those? (I don't believe I'm qualified to answer that question myself, and TBH I have no need of these additional permissions.)

I can take a look at this

@aaythapa
Copy link
Contributor

We've reviewed the PR internally and the actions that were added are all GET operations so nothing sensitive.

We're good to merge after the change is made backwards compatible, I explained here why this change would break compatibility.

@elmaimbo

@elmaimbo
Copy link
Contributor Author

We've reviewed the PR internally and the actions that were added are all GET operations so nothing sensitive.

We're good to merge after the change is made backwards compatible, I explained here why this change would break compatibility.

@elmaimbo

This is now complete in the latest commit.

Please let me know if anything is still outstanding?

Thanks,
Nick.

@elmaimbo
Copy link
Contributor Author

@aaythapa can you please fix the status of this pull request. I seem to have inadvertently marked it for review. Sorry about that! :-(

@GavinZZ GavinZZ merged commit 51b6994 into aws:develop Nov 4, 2024
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants