Allowing AWS IAM Users to Manage their Passwords, Keys, and MFA

We do these three things for IAM users that belong to humans:

  • Set a console access password and rotate it regularly. We don’t manage resources in the console, but its graphical UI is handy for inspection and diagnostics.
  • Create access keys and rotate them regularly. We use these with aws-vault to run things like terraform.
  • Enable a virtual Multi-Factor Authentication (MFA) device. AWS accounts are valuable resources. It’s worthwhile to protect them with a second factor of authentication.

There’s much more to managing IAM users, like setting password policies and enforcing key rotation. These are just three good practices we follow.

Users with the AdministratorAccess policy can do all three, but that’s a lot of access. Often, we don’t need that much. Maybe we’re just doing investigation and ReadOnlyAccess is enough. Maybe users have limited permissions and instead switch into roles with elevated privileges (more on this in a future article). In cases like those, we need a policy that allows users to manage their own authentication. Here’s what we use.

This article is about enabling human operators to responsibly manage their accounts. Service accounts used by automation and security policy enforcement are both topics for future articles.

Table of Contents

Console Access Policy Statements

This one is easy. The AWS docs have a limited policy that works.

{
    "Sid": "GetAccountPasswordPolicy",
    "Effect": "Allow",
    "Action": "iam:GetAccountPasswordPolicy",
    "Resource": "*"
},
{
    "Sid": "ChangeSelfPassword",
    "Effect": "Allow",
    "Action": "iam:ChangePassword",
    "Resource": "arn:aws:iam::[account id without hyphens]:user/${aws:username}"
}

Access Key Policy Statements

This one is also easy. The AWS docs have a limited policy that works. We made a small tweak.

{
    "Sid": "ManageSelfKeys",
    "Effect": "Allow",
    "Action": [
        "iam:UpdateAccessKey",
        "iam:ListAccessKeys",
        "iam:GetUser",
        "iam:GetAccessKeyLastUsed",
        "iam:DeleteAccessKey",
        "iam:CreateAccessKey"
    ],
    "Resource": "arn:aws:iam::[account id without hyphens]:user/${aws:username}"
}
  • The AWS policy uses * in the account ID component of the ARN. We like to set the account ID so we’re granting the most specific access we can. Security scanning tools also often check for * characters, and removing them reduces the number of flags.
  • Like above, ${aws:username} is an IAM policy variable. See links there for how to handle this in terraform.
  • We changed the sid from “ManageOwn” to “ManageSelf” so it doesn’t sound like it allows taking ownership of keys for other users.

MFA Device Policy Statements

This one was trickier. We based our policy on an example from the AWS docs, but we made several changes.

{
    "Sid": "ManageSelfMFAUserResources",
    "Effect": "Allow",
    "Action": [
        "iam:ResyncMFADevice",
        "iam:ListMFADevices",
        "iam:EnableMFADevice",
        "iam:DeactivateMFADevice"
    ],
    "Resource": "arn:aws:iam::[account id without hyphens]:user/${aws:username}"
},
{
    "Sid": "ManageSelfMFAResources",
    "Effect": "Allow",
    "Action": [
        "iam:DeleteVirtualMFADevice",
        "iam:CreateVirtualMFADevice"
    ],
    "Resource": "arn:aws:iam::[account id without hyphens]:mfa/${aws:username}"
}
  • Like we talked about above, our goal is to enable users to follow good practices. We selected statements that enable but not ones that require.
  • The AWS example included arn:aws:iam::*:mfa/* in the resources for iam:ListMFADevices. According to the the AWS docs for the IAM service’s actions, this permission only supports user in the resources list. We removed the mfa resource.
  • Also according to the the AWS docs for the IAM service’s actions, iam:DeleteVirtualMFADevice and iam:CreateVirtualMFADevice support different resources from iam:ResyncMFADevice and iam:EnableMFADevice. We split them into separate statements that limit each one to their supported resources. This probably doesn’t change access level, but our routine is to limit resource lists as much as possible. That helps make it clear to future readers what the policy enables.
  • Like above, ${aws:username} is an IAM policy variable. See links there for how to handle this in terraform.
  • We continued our convention from above of naming sids for “self” to indicate they’re limited to the user who has the policy.

Complete Policy Document

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "GetAccountPasswordPolicy",
            "Effect": "Allow",
            "Action": "iam:GetAccountPasswordPolicy",
            "Resource": "*"
        },
        {
            "Sid": "ChangeSelfPassword",
            "Effect": "Allow",
            "Action": "iam:ChangePassword",
            "Resource": "arn:aws:iam::[account id without hyphens]:user/${aws:username}"
        },
        {
            "Sid": "ManageSelfKeys",
            "Effect": "Allow",
            "Action": [
                "iam:UpdateAccessKey",
                "iam:ListAccessKeys",
                "iam:GetUser",
                "iam:GetAccessKeyLastUsed",
                "iam:DeleteAccessKey",
                "iam:CreateAccessKey"
            ],
            "Resource": "arn:aws:iam::[account id without hyphens]:user/${aws:username}"
        },
        {
            "Sid": "ManageSelfMFAUserResources",
            "Effect": "Allow",
            "Action": [
                "iam:ResyncMFADevice",
                "iam:ListMFADevices",
                "iam:EnableMFADevice",
                "iam:DeactivateMFADevice"
            ],
            "Resource": "arn:aws:iam::[account id without hyphens]:user/${aws:username}"
        },
        {
            "Sid": "ManageSelfMFAResources",
            "Effect": "Allow",
            "Action": [
                "iam:DeleteVirtualMFADevice",
                "iam:CreateVirtualMFADevice"
            ],
            "Resource": "arn:aws:iam::[account id without hyphens]:mfa/${aws:username}"
        }
    ]
}

User Guide

  1. Replace [account id without hyphens] with the ID for your account in the policy above.
  2. Attach the policy to users (we like to do this through groups).
  3. Tell users to edit their authentication from My Security Credentials in the user dropdown. This policy won’t let them access their user through the IAM console. My Security Credentials may not appear in the dropdown if the user has switched into a role.

Happy automating!

Need more than just this article? We’re available to consult.

You might also want to check out these related articles: