Scoping a role on choudoufu

How to scope a role to an estate

Mon, 01 Jan 0001 00:00:00 +0000

How to scope a role to an estate#

The whole estate#

Two statements, because creating and mutating are conditioned by different keys.

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Sid": "MutateOnlyThisEstate",
 "Effect": "Allow",
 "Action": ["ec2:CreateTags", "ec2:DeleteTags", "ec2:TerminateInstances"],
 "Resource": "*",
 "Condition": {
 "StringEquals": {"aws:ResourceTag/tofu-estate": "prod-networking"}
 }
 },
 {
 "Sid": "CreateOnlyIntoThisEstate",
 "Effect": "Allow",
 "Action": ["ec2:RunInstances", "ec2:CreateTags"],
 "Resource": "*",
 "Condition": {
 "StringEquals": {"aws:RequestTag/tofu-estate": "prod-networking"}
 }
 }
 ]
}

aws:ResourceTag reads a tag off a resource that already exists, so it governs everything the estate acts on. It cannot govern a create, because no resource exists yet to carry the tag. What the creating principal supplies is aws:RequestTag, and conditioning on that is what makes the second statement a grant to create into this estate rather than a grant to create anything.

How to stop a staging role reaching production

Mon, 01 Jan 0001 00:00:00 +0000

How to stop a staging role reaching production#

Pointing a staging configuration at a production account is a familiar outage. Nothing structurally prevents it today, because it is the same principal making the same API calls either way. IAM has nothing to tell the two runs apart.

Markers give it something to tell them apart by.

The policy#

Attach this to the role your staging runs use.

{
 "Sid": "NeverMutateAnotherEstate",
 "Effect": "Deny",
 "Action": [
 "ec2:TerminateInstances",
 "ec2:DeleteSubnet",
 "ec2:DeleteVpc",
 "rds:DeleteDBInstance"
 ],
 "Resource": "*",
 "Condition": {
 "StringNotEquals": {"aws:ResourceTag/tofu-estate": "staging"}
 }
}

A mistake now fails at the cloud rather than at review. The guardrail sits below the tool, so it holds whatever the tool was pointed at, whatever directory someone was standing in, and whatever the plan said.

How to cover every team with one policy

Mon, 01 Jan 0001 00:00:00 +0000

How to cover every team with one policy#

This is attribute-based access control, ABAC, applied to the resources your configuration manages.

A policy per team is a policy set that grows with the org chart and drifts between its members. ABAC exists to avoid that, and it needs an attribute on the resource to match against. Markers are one, written on every resource the estate manages rather than applied by a convention someone has to remember.

How to deny creating anything unowned

Mon, 01 Jan 0001 00:00:00 +0000

How to deny creating anything unowned#

Tag compliance is normally retroactive. A scanner finds untagged resources, a ticket asks someone to explain them, and the backlog never empties because new ones arrive faster than old ones are resolved.

Conditioning creation inverts it. Ownership stops being something a resource acquires later and becomes a precondition of existing.

The policy#

As a service control policy, applied to the accounts that hold estates.

Where AWS honours the condition

Mon, 01 Jan 0001 00:00:00 +0000

Where AWS honours the condition#

Where the key is confirmed#

17 of 180 services in AWS’s Service Authorization Reference name aws:ResourceTag on their tagging action. That is a lower bound. The reference is authoritative about what it names and silent about what it omits, and AWS documents tag-based authorization for services it says nothing about, Lambda among them.

Service	IAM prefix	Actions naming it	Of total
EC2	`ec2`	495	793
ResilienceHub	`resiliencehub`	57	128
SES	`ses`	48	228
AutoScaling	`autoscaling`	42	68
ECS	`ecs`	37	81
Kinesis	`kinesis`	31	40
CertificateManager	`acm`	20	41
CleanRooms	`cleanrooms`	12	107
ElastiCache	`elasticache`	11	77
CloudWatch	`cloudwatch`	7	67
SageMaker	`sagemaker`	7	444
WorkSpaces	`workspaces`	7	101
KafkaConnect	`kafkaconnect`	2	18
AuditManager	`auditmanager`	1	62
Batch	`batch`	1	45
CUR	`cur`	1	12
SSMQuickSetup	`ssm-quicksetup`	1	14

Services with no verdict#

The reference states nothing either way for these. Check them against AWS’s own IAM documentation and test the policy. This is not a list of services where scoping fails.