IAM Conditions that Restrict Access Based on EC2ResourceTag & AwsMultifactorAuthentication (MFA) | Deep Dive.

twtech  deep dive into the IAM conditions:

ec2:ResourceTag/twtechkey → Restricting EC2 access based on tags
aws:MultiFactorAuthPresent (MFA) → Restricting access based on MFA being used

We’ll cover how they work, common policies, evaluation flow, and best-practice patterns — and then I’ll describe how to visualize this in an AWS Architecture-style diagram.

 Conceptual Overview

IAM Conditions are context keys that allow fine-grained access control by evaluating request attributes (e.g., who made the request, where from, which tags, MFA state, etc.).

1. EC2ResourceTag/twtechkey — Resource Tag-Based Restrictions

 Purpose:

Used to control access to EC2 resources (instances, volumes, AMIs, etc.) based on the tags applied to those resources.

 Context:

• Evaluated at resource level (when EC2 resources are targeted).
• twtech can allow/deny actions only if the resource has specific tag key/value pairs.

 Common Use Case:

Allow twtechUsers to start/stop or modify EC2 instances only if the instances are tagged with their team(twtechWebInstanceTeam) or project.

# Example Policy:

{

  "Version": "2012-10-17",

  "Statement": [

    {

      "Sid": "twtechAllowedTeamOnly",

      "Effect": "Allow",

      "Action": "ec2:*",

      "Resource": "*",

      "Condition": {

        "StringEquals": {

          "ec2:ResourceTag/Team": "${aws:PrincipalTag/twtechWebInstanceTeam }"

        }

      }

    }

  ]

}

 Explanation:

• The policy checks the tag key Team on the resource (ec2:ResourceTag/twtechWebInstanceTeam).
• It only allows actions if the EC2 instance’s Team tag matches the IAM user’s tag (aws:PrincipalTag/twtechWebInstanceTeam).

 Evaluation Flow:

1. User makes an EC2 API call (e.g., StopInstances).
2. IAM policy attached to the user or role is evaluated.
3. Condition check:
   AWS fetches the target EC2 instance’s tags → checks whether the Team tag matches user’s tag.
4. If true: request proceeds to EC2 API.
   If false: Access denied.

 Gotcha (watch out for):

• Some EC2 APIs don’t support resource-level permissions (require "Resource": "*") — so always verify with the IAM Actions, Resources, and Condition Keys Reference.
• Tag conditions only work when the resource already exists — not at creation time (unless combined with ec2:CreateAction and aws:RequestTag).

 2. AwsMultiFactorAuthPresent — MFA Enforcement

 Context:

Used to ensure that sensitive actions can only be performed when MFA is active in the user’s session.

# Example Policy:

{

  "Version": "2012-10-17",

  "Statement": [

    {

      "Sid": "twtechAllowedViewActions",

      "Effect": "Allow",

      "Action": ["ec2:Describe*"],

      "Resource": "*"

    },

    {

      "Sid": "twtechAllowedModifyWithMFAOnly",

      "Effect": "Deny",

      "Action": ["ec2:TerminateInstances", "ec2:StopInstances"],

      "Resource": "*",

      "Condition": {

        "BoolIfExists": {

          "aws:MultiFactorAuthPresent": "false"

        }

      }

    }

  ]

}

 Explanation:

• If aws:MultiFactorAuthPresent = false → deny sensitive actions (terminate, stop, etc.).
• Descriptive actions (like DescribeInstances) are allowed without MFA.

 Evaluation Flow:

1. IAM user authenticates via console, CLI, or API.
2. If login is MFA-authenticated, the session has aws:MultiFactorAuthPresent=true.
3. When user performs an action, IAM policy condition checks this key.
4. Deny or allow based on presence/absence of MFA.

 Combined Scenario — Tag + MFA Enforcement

 Use Case:

NB:

A DevOps engineer can only manage EC2 instances tagged with their team name and only after MFA authentication.

# Combined Example Policy:

{

  "Version": "2012-10-17",

  "Statement": [

    {

      "Sid": "twtechAllowedTeamWithMFA",

      "Effect": "Allow",

      "Action": "ec2:*",

      "Resource": "*",

      "Condition": {

        "StringEquals": {

          "ec2:ResourceTag/Team": "${aws:PrincipalTag/twtechWebInstanceTeam}"

        },

        "Bool": {

          "aws:MultiFactorAuthPresent": "true"

        }

      }

    }

  ]

}

 Architecture Diagram (Flow)

Entities:

• IAM User / Role → Authenticated session (with or without MFA)
• IAM Policy → Evaluated in IAM engine
• EC2 Resource → With Team tag
• IAM Condition Keys → ec2:ResourceTag/twtechWebInstanceTeam, aws:MultiFactorAuthPresent

# Flow text daigram:

User (with or without MFA)

   ↓

AWS API Call (e.g., ec2:StopInstances)

   ↓

IAM Policy Evaluation Engine

   ├─ Check ResourceTag condition (Team tag match?)

   └─ Check MFA condition (aws:MultiFactorAuthPresent?)

  ↓

If both true → Allow

Else → Deny

   ↓

EC2 Service (Action executed or rejected)

 # Flow-daigram.jpg

Best Practices

• Enforce MFA for destructive or sensitive actions
• Use PrincipalTags + ResourceTags to map identity to ownership
• Combine with SCP or Permission Boundaries for stronger enforcement
• Monitor via AWS CloudTrail to audit tag and MFA compliance