[BUG][Functional] SCPs not protecting ASEA managed KMS keys

[prabhukiran9999]

Bug reports which fail to provide the required information will be closed without action.

Required Basic Info

• Accelerator Version: v1.5
• Install Type: Upgrade
• Upgrade from version: (v1.3.8)

Describe the bug

• The SEA Deploys a few KMS keys within the environment with the names PBMMAccel-*, With AdministratorAccess managed Policy users, can disable the KMS keys and delete the associated tags(for example the accelerator tags).
• Users can also delete Key aliases in the sandbox accounts

Steps To Reproduce

1. log in to a workload account console and search for "Key Management Service"
2. Select a key created by the SEA and click on "Key actions" and click "Disable"
3. You should see the key being disabled
4. You can also switch to the "Tags" tab and click on "edit" and click on "Delete tag" to delete the tag
5. Login into a sandbox account and search for "Key Management Service"
6. Select a key created by the SEA and switch to the "Aliases" tab and select the alias and click delete

Expected behavior

• The Expected behavior is that the KMS Keys created by the SEA are non-editable by users with admin privileges and users trying to update or edit the KMS keys should get an explicit deny in an SCP

Screenshots

Additional context

• Users can disable keys but cannot delete them which is a good thing, but we believe that any kind of actions on the KMS keys created by the SEA should result in an Explicit deny

[Brian969]

Peculiar - it should actually work the way you want, given we have this SCP in place:

Your actual SCP should look like this: "Resource": "arn:aws:kms:::alias/PBMMAccel*", in Organizations.

I just re-tested and I get the same result.

Can I request you open an AWS support case to dive into why this SCP is not working as expected? (as it will be more timely and effective than any analysis by myself) If you report back a fix, happy to get it incorporated. I'm going to guess that KMS SCP's currently don't support using the ALIAS in the resource field - which may mean I have no easy mechanism to further protect these objects, unless KMS supports using tags within SCPs. My initial thoughts.

[prabhukiran9999]

Hey @Brian969, we have raised an AWS support request regarding the issue, and they came back confirming using Alias in the resource field is not supported and suggested using Keyid in the resource field.

{ "Effect": "Deny", "Action": [ "kms:DeleteAlias", "kms:UpdateAlias", "kms:DisableKey", "kms:ImportKeyMaterial", "kms:PutKeyPolicy", "kms:ScheduleKeyDeletion" ], "Resource": "arn:aws:kms:::key/", "Condition": { "ForAnyValue:StringEquals": { "aws:ResourceTag/Accelerator": "PBMM" }, "ArnNotLike": { "aws:PrincipalARN": [ "arn:aws:iam:::role/PBMMAccel-*" ] } } }

But restricting with tags, we also need to make sure who has access to the tags so they don't get around it by simply tagging("kms:TagResource") or untagging(kms:UntagResource) them

[archikierstead]

SCP in reference-artifacts updated to fix.