Advanced IAM policy use cases

While AWS provides a plethora of built-in policies and templates, understanding how to tailor policies for specific scenarios can make all the difference. In this subsection, we will explore four advanced IAM policy use cases that address challenges commonly faced by organizations. The following examples will illustrate the depth and breadth of possibilities when it comes to IAM policy conditions.

Enforcing MFA for AWS CLI access

One of the foundational security practices in AWS is to enforce MFA for all human IAM users, especially for the ones with the most permissive access. While MFA is commonly associated with AWS Management Console access, it is equally important for CLI operations. However, this is not enforced by default. Here is a policy that denies all actions if the request is made from the CLI without MFA:

{
  “Version”: “2012-10-17”,
  “Statement”: {
    “Effect”: “Deny”,
            “NotAction”: [
    “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”
  ],
            “Resource”: “*”,
  “Condition”: {
    “Bool”: {
      “aws:MultiFactorAuthPresent”: “false”,
      “aws:ViaAWSService”: “false”
      }
    }
  }
}

Restricting Lambda function invocation based on the VPC endpoint

To ensure that Lambda functions are only invoked from within a specific VPC, you can craft a policy that checks that the function is invoked from a particular VPC endpoint:
{
  “Version”: “2012-10-17”,
  “Statement”: {
    “Effect”: “Allow”,
    “Action”: “lambda:InvokeFunction”,
    “Resource”: “arn:aws:lambda:region:account-id:function:function-name”,
    “Condition”: {
      “StringEquals”: {
        “aws:sourceVpce”: “vpce-0abcd1234efgh5678”
      }
    }
  }
}

Dynamically allowing access based on tags

AWS resources can be tagged with key-value pairs, which can then be used in IAM policies to grant or deny access dynamically. Imagine a scenario where you want to allow developers to start or stop EC2 instances, but only if the instance has an Owner tag that specifies their IAM username:
{
  “Version”: “2012-10-17”,
  “Statement”: {
    “Effect”: “Allow”,
    “Action”: [“ec2:StartInstances”, “ec2:StopInstances”],
    “Resource”: “*”,
    “Condition”: {
      “StringEquals”: {
        “ec2:ResourceTag/Owner”: “${aws:username}”
      }
    }
  }
}