Scope:
- Intro,
- Implementation Details,
- Conceptual Overview,
- EC2ResourceTag/key for Resource Tag-Based Restrictions,
- Sample Policy for Resource Tag-Based Restrictions,
- Explanation of Resource Tag-Based Restrictions,
- Gotcha (watch-out-for) of Resource Tag-Based Restrictions,
- AwsMultiFactorAuthPresent For MFA Enforcement,
- Sample Policy For MFA Enforcement,
- Explanation of MFA Enforcement Policy,
- Combined Scenario of ResourceTag + MFA Enforcement Policies (Use Cases),
- Architecture Diagram & Flow Entities,
- Best Practices.
Intro:
- ec2:ResourceTag/tag-key: Use this service-specific key to grant or deny access based on existing tags attached to an EC2 resource, such as an instance or volume.
- aws:MultiFactorAuthPresent: This global condition key checks if the user's credentials were authenticated using MFA.
- aws:MultiFactorAuthAge: Use this to ensure the MFA authentication occurred within a specific timeframe, such as the last 3,600 seconds (1 hour).
- Resource-Level Control: The
ec2:ResourceTagkey is typically used with anAlloweffect to permit actions likeec2:StartInstancesonly if a specific tag (e.g.,Project: Finance) is present on the instance. - Enforcing MFA: To require MFA for all EC2 operations, add a condition that checks if
aws:MultiFactorAuthPresentistrue. - Note that this key is not present in requests made with long-term access keys unless they are exchanged for temporary credentials via AWS STS.
- Combining Conditions: twtech can combine both in a single policy statement to mandate that a user can only manage EC2 instances tagged with their username if they have also authenticated with MFA.
- ec2:ResourceTag/twtechkey → Restricting EC2 access based on tags
- aws:MultiFactorAuthPresent (MFA) → Restricting access based on MFA being used.
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 for 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.
#Sample Policy for Resource Tag-Based Restrictions:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "twtechAllowedTeamOnly",
"Effect": "Allow",
"Action": "ec2:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Team":
"${aws:PrincipalTag/twtechWebInstanceTeam }"
}
}
}
]
}
# Explanation of Resource Tag-Based Restrictions:
- 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).
- Only twtechWebInstanceTeam can access that specific Insance
Evaluation Flow:
- User makes an EC2 API call (e.g., StopInstances).
- IAM policy attached to the user or role is evaluated.
- Condition check:
- AWS fetches the target EC2 instance’s tags → checks whether the Team tag matches user’s tag.
- If true: request proceeds to EC2 API.
- If false: Access denied.
Gotcha (watch-out-for) of Resource Tag-Based Restrictions:
- 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 For MFA Enforcement
Context:
Used to ensure that sensitive
actions can only be performed when MFA is active in the user’s
session.
# Sample Policy For MFA Enforcement:
{
"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 of MFA Enforcement Policy:
- If aws:MultiFactorAuthPresent = false → deny sensitive actions (terminate, stop, etc.).
- Descriptive actions (like DescribeInstances) are allowed without MFA.
Evaluation Flow:
- IAM user authenticates via console, CLI, or API.
- If login is MFA-authenticated, the session has aws:MultiFactorAuthPresent=true.
- When user performs an action, IAM policy condition checks this key.
- Deny or allow based on presence/absence of MFA.
Combined Scenario of ResourceTag + MFA Enforcement Policies (Use Cases):
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
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
No comments:
Post a Comment