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:

"arn:aws:iam::*:mfa/${aws:username}"

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": [
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:ListMFADevices",
        "iam:ListUsers",
        "iam:ListVirtualMFADevices",
        "iam:ResyncMFADevice"
    ],
    "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:

" src="https://www.tecracer.com/blog/img/2020/03/rotate-explorer.png">

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. task.dev and cdk must be installed
3. aws iam get-group --group-name "SelfEdit" - No IAM group present
4. git clone git@github.com:tecracer/cdk-templates.git - 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:

Conclusion

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