Rotate your credentials and don’t forget MFA

According to the Well-Architected Framework and the least privileges principle, you should change your access keys and login password regularly. Therefore the user should have the right to edit their credentials. But only their own. Also using MFA - multi-factor authentication enhances the security even more. Therefore the user should be able to change MFA. But only their own. But how to do that? You have to combine two parts of AWS documentation. We will show you how you provide a “self-editing” group for your users with the CDK.

Least privileges

With IAM policies, you have two key factors which determine what your rights are:

The Actions define which API calls you are allowed to use. The Resources define on which resources you may apply these actions.

To keep your system safe, you should narrow both down to the minimum. So an ‘*’ which stands for “everything” is not allowed.

The Well Architected Framework as a guideline

The Well Architected Framework from AWS gives you guidelines for the design and configuration of secure architecture. It consists of five pillars: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization

The first question in the security pillar section is:

SEC 1: How do you manage credentials and authentication?

One of the Best Practices is:

“Rotate credentials regularly: Rotate credentials regularly to help reduce the risk of old credentials being used by unauthorized systems or users.”

So it would be ideal if that could be automated. But the user has to change its credentials her or himself. In doing so, the credentials are not known to other people.

Another practice says:

“Enforce use of multi-factor authentication: Enforce multi-factor authentication (MFA) with software or hardware mechanisms to provide additional access control.” So we should combine the policy for the user with MFA.

Changing credentials with least privilege

Combining these you want the user to change their credentials but only their own.

A excellent way to do this is to provide a group for all users.

To let the user only edit the own user resource, IAM provides the following solution:

"Resource": "arn:aws:iam::*:user/${aws:username}"

The first part of all policies are documented here. This covers the login passwords, the access keys and the ssh keys.

What’s missing is the MFA part. For the user to edit only its own mfa, IAM gives us:


Enforcing MFA

The MFA part is documented here.

The last part is to enforce MFA for all users. This policy:

    "Sid": "BlockMostAccessUnlessSignedInWithMFA",
    "Effect": "Deny",
    "NotAction": [
    "Resource": "*",
    "Condition": {
        "BoolIfExists": {
            "aws:MultiFactorAuthPresent": "false"

performs a nice logical stunt: It denies everything unless you are authenticated with MFA. The “NotAction” part is there to make sure that also a non-MFA user can activate MFA.

Easy deployment with CDK

See the code on github/tecracer.

The AWS CDK Explorer shows the resources of the stack:

The stack creates a group and 7 policy statements with the different mandatory permissions. With the properties of the construct you may turn the different credentials types (password, accesskey and ssh keys) on or of.

If you want to enforce MFA, you just set blockNonMFAAccess to true.

The settings in the example (bin/self_editing.ts) are:

new SelfEditingStack(app, 'SelfEditingStack',  {
    MFAManagementAllowed: true,
    accessKeyManagementAllowed: true,
    passwordEditingAllowed: true,
    sshKeyManagementAllowed: true,

Whole setup

  1. AWS profile must be stored in AWSUME_PROFILE
  2. and cdk must be installed
  3. aws iam get-group --group-name "SelfEdit" - No IAM group present
  4. git clone - get code
  5. cd cdk-templates/selfEditing - go into directory
  6. npm i - install dependencies
  7. task deploy - Deploy stack
  8. aws iam get-group --group-name "SelfEdit" - check for group
  9. aws iam get-group-policy --group-name "SelfEdit" --policy-name "selfEditDefaultPolicyB4B338D3" check for policy of group
  10. task destroy - destroy stack again
  11. aws iam get-group --group-name "SelfEdit" check that IAM group is deleted

If you perform up to step 7, you just have to add users to this group to enable them to edit thier own credentials.

Or as a little show:

Terminal Session


In this blog post I’ve given you an example of how to automate IAM policies with CDK. If there are any questions or feedback, feel free to reach out to me on Twitter.

Thanks to

Photo by Jeff Fielitz on Unsplash

Animated gif generated by faressoft/terminalizer

Similar Posts You Might Enjoy

AWS Access Management uncovered: Where do all those 403s come from?

In this blog post, I would like to show you the various types of AWS permission management capabilities to generate a better understanding, where access denied API errors (403) may arise from and what ample options there are to grant permissions. One should be familiar with IAM policies to get the most out of the blog. - by Dr Felix Grelak

Advanced Credential Rotation for IAM Users with a Grace Period

Rotating credentials with grace can be challenging when the underlying service doesn’t support scheduled deletion. Today I will show you how to implement access key rotation for an IAM user while supporting a grace period where both the new and old credentials are valid. - by Maurice Borgmeier

Find all Lambda-Runtimes in all Accounts: Multi Account Query with steampipe and TASFKAS (the AWS service formerly known as SSO *)

You have got some mails from AWS: [Action Required] AWS Lambda end of support for Node.js 12 [Action Required] AWS Lambda end of support for Python 3.6 [Solution Required] Search all Lambdas in multiple accounts. [Solution Found] Steampipe with AWS multi-account support. Multi-account management is like managing all the arms of a Kraken. I will show you a fast and straightforward solution for this. (* the new offical name is IAM Identity Center, but I think TASFKAS would also fit 😉) - by Gernot Glawe