Option to not enforce MFA for API calls

[ainestal]

After trying the enforced policy there are lots of reports of users complaining about being unable to run automated tasks.

The current policies apply to all the AWS interactions needing to contain MFA. That also is true for all the API calls.

Changing all the automated tasks to be able to use MFA is difficult in most of the cases and impossible in some others, specially with 'machine' users.

A fix would be to change the following part of the policy:

condition {
  test     = "Bool"
  variable = "aws:MultiFactorAuthPresent"
  values   = [
    "false",
  ]
}

It would be nice to have a variable that enables/disables MFA for API calls.

[jeromegamez]

(I updated your post only for the code formatting)

I would have thought that this would be solved by applying the rule to a group, and only putting web console users into it, am I missing something?

Is using https://aws.amazon.com/de/premiumsupport/knowledge-center/authenticate-mfa-cli/ a possibility, or is this too complicated? (It looks to me 😅)

While I was looking through the code I noticed that the policies described on https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_aws_my-sec-creds-self-manage.html (which I originally used here) seem to have changed in the meantime, this would be something to look into, perhaps this is already the main cause of the issue.

[ainestal]

Thanks for fixing the format ;)

About this problem I did some research and there are different options. There are specially 2 that I liked:

• Creating 2 different users so people can use one for login into the console and having the MFA enabled. Another user with very limited access that doesn't need the MFA enabled (is not in the enforced group). I would also add some automated task that ensures that the keys aren't older than X time.

• Having a single group that enforces MFA just for the console access. This is probably the one I like the most because it simplifies the management of users, but it's a little more insecure. Rotation of keys should also be enforced.

Using STS is complicated, not for a single use which would be ok, but changing everything that is already running in production so it handles the token would be very painful.

There could be a new variable in the module that enables/disables the enforced MFA for API calls.

For the updated policies, it would be good to udpate them. After some tests I found that's not really the origin of the problem with the API calls, it's specifially:

statement {

    sid = "BlockMostAccessUnlessSignedInWithMFA"

    effect = "Deny"

    not_actions = [
        "iam:ChangePassword",
        "iam:CreateLoginProfile",
        "iam:CreateVirtualMFADevice",
        "iam:DeleteVirtualMFADevice",
        "iam:ListVirtualMFADevices",
        "iam:EnableMFADevice",
        "iam:ResyncMFADevice",
        "iam:ListAccountAliases",
        "iam:ListUsers",
        "iam:ListSSHPublicKeys",
        "iam:ListAccessKeys",
        "iam:ListServiceSpecificCredentials",
        "iam:ListMFADevices",
        "iam:GetAccountSummary",
        "sts:GetSessionToken"
    ]

    resources = [
        "*"
    ]

    condition {
        test = "BoolIfExists"
        variable = "aws:MultiFactorAuthPresent"

        values = [
        "false",
        ]
    }
}

And more specifically: test = "BoolIfExists" when changed to test = "Bool" doesn't validate API calls

One final thought, I give the users the possibility to change their own password, otherwise there is this chicken and egg problem were they can't change the password because they don't have MFA and they can't set the MFA because they didn't change the password. This is currently what happens for all new users added to my account. So a single variable that enables/disables enforcement for the API would be sufficient, thus only 2 data resources would be needed again, not four like in the case the 2 variables exist.