If you actively monitor your security hub score, chances are that you know about how tricky things can get.
Recently a new check for encrypting SNS topics at rest was added to security hub. As a result, I faced some strange issues.
I followed these steps to resolve the broken notifications but this led to me failing another security check.
Chances are that you’ll fail KMS.1 or KMS.2 of AWS foundational best practices if you follow the approach above.
Because you are giving permissions to wildcard (*) for KMS actions!
The first approach that came to my mind was to add an inline policy to the role with the specific KMS key’s ARN mentioned in the resource section of the policy.
But wait! What if I need to add these permissions to some other role?
Well, in that case I’ll need to create another inline policy for it.
So this definitely was not the answer. Then what? How about a customer managed policy having the permissions rather than an inline policy?
In this case too, I might face issues as the policy had more than 1 permission and it can thus violate the rule of least privileges if I reuse it.
Then how can we allow KMS permissions ensuring that those could be reused?
I create a separate managed policy only for decrypt permissions and named it appropriately and similarly I created a policy for all the KMS permissions that I was providing.
I can now reuse the individual policies for individual permissions and keys without violating the principle of least privileges!