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:

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:

Terminal Session

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

Similar Posts You Might Enjoy

AWS Setup: Secure Identity Foundation with Terraform

AWS Setup: Secure Identity Foundation with Terraform When it comes to access management in AWS, often I see a basic setup, with Users in IAM, as described here. Clearly, most people focus on building actual running applications, at first. After the first running POCs, the next migrations are on the road map; your architecture evolves, but the initial IAM setup stays. So it’s better to have a super secure set-up right from the beginning. - by Dr Felix Grelak

Three hurdles to skip before using the secure Instance Metadata Service V2

Do not use new Instance Metadata Service V2 (imdsv2) without proper prevention! You may think you can use Instance Metadata Service V2 right away, but there are a few caveats: Many old modules do not work with imdsv2 yet. We look at aws cli, the Systems Manager agent and the Instance Connect service. Currently, these services will not work with imdsv2 on an EC2 instance with the latest Amazon Linux 2 image out of the box. Here you can read how to make them work! - by Gernot Glawe

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