🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🚧 धडा 08 — Guardrails: प्रत्येक policy वरचे छत

📍 तुम्ही इथे आहात: 12 पैकी धडा 08 · मागील: lesson-07-conditions-abac · पुढील: lesson-09-cross-account

📦 या ब्रँचमध्ये काय आहे

धडे 01–07, आणि दोन छते: एका identity वर permission boundary (boundary-developers.json) आणि संपूर्ण account वर AWS Organizations च्या service control policies (scp-full-access.json, scp-two-regions.json).

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

एका नव्या lab सहाय्यिकेला "lab मध्ये काहीही करू शकते" असे लिहिलेले कार्ड मिळते. विज्ञान समन्वयिका त्यावर एक छत 🚧 घालते: "…पण यापेक्षा जास्त कधीच नाही: उपकरणे वापरणे, नोंदवह्या वाचणे". कार्डवर अजूनही "काहीही" लिहिलेले आहे — पण छताच्या वर जे काही आहे ते हाताला लागतच नाही. हीच permission boundary.

मग संपूर्ण शाळा एका शाळा मंडळाची असते, आणि मंडळ चालवत असलेल्या प्रत्येक शाळेसाठी त्याचे स्वतःचे नियम असतात: "कोणतीही शाळा या दोन शहरांबाहेर शाखा उघडणार नाही". एखाद्या शाळेच्या मुख्याध्यापिकेलाही तो नियम मोडता येत नाही. हीच SCP.

छत कधीच काही देत नाही. शिडी किती उंच जाऊ शकते एवढेच ते ठरवते.

🗺️ आकृती

flowchart LR
    id["📝 identity policy<br/>admin: * on *"]
    b["🚧 boundary<br/>s3:* · logs:* · cloudwatch:* · ec2:Describe*"]
    scp["🏛️ SCP<br/>deny outside ap-south-1 · us-east-1"]
    eff["✅ effective<br/>identity ∩ boundary ∩ SCP"]
    id --> eff
    b -->|"1 ceiling on one identity"| eff
    scp -->|"2 ceiling on the account"| eff
    eff -.->|"iam:CreateUser"| no["🚫 outside the boundary"]

🗺️ काढलेली आकृती + एक lab: https://school-edh.pages.dev/iam/lesson-diagrams.html#l08

❓ काय

Permission boundary — IAM user किंवा role वर लावलेली managed policy (put-user-permissions-boundary / put-role-permissions-boundary). प्रत्यक्ष access = identity policies ∩ boundary. तिचा नेहमीचा उपयोग म्हणजे सुरक्षित delegation: developers फक्त boundary जोडली तरच roles बनवू शकतात (condition iam:PermissionsBoundary), त्यामुळे ते स्वतःपेक्षा ताकदवान काहीही बनवू शकत नाहीत.
SCP — organization root, OU किंवा account ला जोडलेली policy. ती member accounts मधील प्रत्येक principal ला मर्यादा घालते, त्यांच्या root users सकट. ती काहीच देत नाही: default FullAWSAccess SCP मुळेच मुळात काहीतरी allow होते. SCPs management account ला किंवा service-linked roles ना लागू होत नाहीत.
Deny-list विरुद्ध allow-list SCPs — FullAWSAccess ठेवा आणि नेमके denies जोडा (इथे केले आहे तसे), किंवा त्याऐवजी परवानगी असलेल्या services ची यादी ठेवा.
Region guardrail — global services साठी NotAction असलेला Deny आणि aws:RequestedRegion वर StringNotEquals. हा नमुना iam:*, sts:* आणि organizations:* ना सूट देतो; AWS चे स्वतःचे उदाहरण global services च्या जास्त मोठ्या यादीला सूट देते (CloudFront, Route 53, Support, …).
RCPs — resource control policies म्हणजे SCPs ची नवी, resource बाजूची जुळी बहीण: तुमच्या organization मधील resources काय allow करतात त्यावरचे छत.
प्रत्यक्ष permissions = identity ∩ boundary ∩ session policy ∩ SCP (आणि RCP), त्यातून कोणताही explicit deny वजा.

🤔 का

कारण admins चुका करतात, credentials फुटतात, आणि teams ना स्वतःचे roles बनवण्याचे स्वातंत्र्य हवे असते. Guardrails "कृपया करू नका" चे "करताच येत नाही" करतात: कोणीही मंजूर regions च्या बाहेर जाऊ शकत नाही, audit trail बंद करू शकत नाही, किंवा स्वतःला छतापेक्षा जास्त देऊ शकत नाही.

🔧 कसे (या repo मध्ये)

iam/demo.py मधील guardrails() dipika ला admin policy boundary सह आणि boundary शिवाय (boundary=) देते, मग katrina ची admin policy दोन SCPs खाली (scps=) दोन regions मध्ये चालवते. iam/evaluate.py मध्ये decide() च्या पायऱ्या 2 आणि 4 सांगतात "allow करायलाच हवे, कधीच देत नाही".

🧪 करून पाहा

python3 iam/demo.py guardrails
python3 - <<'EOF'
import sys; sys.path.insert(0, "iam"); from evaluate import decide, load
dipika, katrina = "arn:aws:iam::111122223333:user/dipika", "arn:aws:iam::111122223333:user/katrina"
admin, b = [("admin", load("admin"))], [("boundary-developers", load("boundary-developers"))]
print("boundary alone      ", decide(dipika, "s3:PutObject", "arn:aws:s3:::dev-scratch/x", identity=[], boundary=b)[0])
deny_only = [("scp-two-regions", load("scp-two-regions"))]
print("SCP deny-list only  ", decide(katrina, "ec2:RunInstances", "*", {"aws:RequestedRegion": "ap-south-1"}, identity=admin, scps=deny_only))
scps = [("scp-full-access", load("scp-full-access"))] + deny_only
print("IAM from sa-east-1  ", decide(katrina, "iam:CreateUser", "*", {"aws:RequestedRegion": "sa-east-1"}, identity=admin, scps=scps)[0])
EOF

खऱ्या account वर (AWS CLI आणि credentials लागतात; SCP commands organization च्या management account मधून चालतात, आणि IDs उदाहरणादाखल आहेत):

aws iam create-policy --policy-name boundary-developers --policy-document file://iam/policies/boundary-developers.json
aws iam put-user-permissions-boundary --user-name dipika --permissions-boundary arn:aws:iam::111122223333:policy/boundary-developers
aws organizations create-policy --name two-regions --type SERVICE_CONTROL_POLICY --description "Only ap-south-1 and us-east-1" --content file://iam/policies/scp-two-regions.json
aws organizations attach-policy --policy-id p-examplepolicyid111 --target-id ou-ab12-cd34ef56

✅ तपासा — तुम्हाला काय दिसायला हवे

guardrails boundary शिवाय dipika च्या admin साठी ✅ ALLOW छापते, boundary सह 🚫 IMPLICIT DENY — outside the permission boundary — the boundary is a ceiling, not a grant, s3:PutObject साठी ✅ ALLOW (छताच्या आत), ap-south-1 मध्ये ✅ ALLOW आणि sa-east-1 मध्ये ⛔ DENY — explicit Deny in SCP scp-two-regions#OnlyMumbaiAndVirginia. तुमचा snippet आधी IMPLICIT DENY छापतो (boundary काहीच देत नाही), मग ('IMPLICIT DENY', "the organization's SCPs do not allow this action for the account") — FullAWSAccess शिवाय मंजूर region मध्येसुद्धा काहीच allow होत नाही — आणि sa-east-1 मधून iam:CreateUser साठी ALLOW, कारण SCP चा NotAction IAM ला सूट देतो.

🏁 तुम्ही आत्ताच काय सिद्ध केले

Boundaries आणि SCPs फक्त काढूनच घेतात: छताखालची admin policy त्या छताइतकीच ताकदवान असते, आणि ज्या छताखाली कोणतेही Allow नाही ते काहीच allow करत नाही.

⚠️ नेहमीच्या चुका

test करताना FullAWSAccess काढून टाकणे — त्याखालची प्रत्येक account काम करणे थांबवते
global-service सूट नसलेली region SCP — IAM, billing किंवा CloudFront बिघडतात
SCP management account ला मर्यादा घालेल अशी अपेक्षा ठेवणे (ती घालत नाही; workloads त्यापासून दूर ठेवा)
developers वर boundary लावणे पण त्यांना boundary स्वतःच बदलू किंवा काढू देणे

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: multi-account landing zone नेहमी baseline SCPs सोबतच येतो — organization सोडण्यास नकार, CloudTrail आणि GuardDuty बंद करण्यास नकार, मंजूर नसलेल्या regions ना नकार, root-user actions ना नकार — आणि roles बनवण्याची परवानगी असलेल्या प्रत्येक team साठी boundaries.

⏭️ पुढे

एका partner शाळेच्या auditor ला तुमचे reports वाचायचे आहेत. Cross-account access आणि resource policies — दोन दरवाजे, दोन चाव्या.

git checkout lesson-09-cross-account

🚧 Lesson 08 — Guardrails: ceilings above every policy

📍 You are here: Lesson 08 of 12 · Previous: lesson-07-conditions-abac · Next: lesson-09-cross-account

📦 What's in this branch

Lessons 01–07, plus the two ceilings: a permission boundary on one identity (boundary-developers.json) and AWS Organizations service control policies on a whole account (scp-full-access.json, scp-two-regions.json).

🧒 Explain like I'm 5

A new lab assistant gets a card that says "may do anything in the lab". The science coordinator adds a ceiling 🚧 above it: "…but never more than: use the equipment, read the logbooks". The card still says "anything" — but whatever is above the ceiling is simply out of reach. That is a permission boundary.

Then the whole school belongs to a school board, and the board has its own rules for every school it runs: "no school may open a branch outside these two cities". Even the principal of one school cannot break that. That is an SCP.

A ceiling never gives anything. It only decides how high the ladder can go.

🗺️ Diagram

flowchart LR
    id["📝 identity policy<br/>admin: * on *"]
    b["🚧 boundary<br/>s3:* · logs:* · cloudwatch:* · ec2:Describe*"]
    scp["🏛️ SCP<br/>deny outside ap-south-1 · us-east-1"]
    eff["✅ effective<br/>identity ∩ boundary ∩ SCP"]
    id --> eff
    b -->|"1 ceiling on one identity"| eff
    scp -->|"2 ceiling on the account"| eff
    eff -.->|"iam:CreateUser"| no["🚫 outside the boundary"]

🗺️ Drawn version + a lab: https://school-edh.pages.dev/iam/lesson-diagrams.html#l08

❓ What

Permission boundary — a managed policy set on an IAM user or role (put-user-permissions-boundary / put-role-permissions-boundary). Effective = identity policies ∩ boundary. Its classic use is safe delegation: developers may create roles only if they attach the boundary (condition iam:PermissionsBoundary), so they cannot create something stronger than themselves.
SCP — a policy attached to the organization root, an OU or an account. It limits every principal in member accounts, including their root users. It grants nothing: the default FullAWSAccess SCP is what allows anything at all. SCPs do not apply to the management account, or to service-linked roles.
Deny-list vs allow-list SCPs — keep FullAWSAccess and add targeted denies (as here), or replace it with a list of allowed services.
Region guardrail — a Deny with NotAction for global services and a StringNotEquals on aws:RequestedRegion. The sample exempts iam:*, sts:* and organizations:*; AWS's own example exempts a longer list of global services (CloudFront, Route 53, Support, …).
RCPs — resource control policies are the newer resource-side twin of SCPs: a ceiling on what resources in your organization allow.
Effective permissions = identity ∩ boundary ∩ session policy ∩ SCP (and RCP), minus any explicit deny.

🤔 Why

Because admins make mistakes, credentials leak, and teams need freedom to create their own roles. Guardrails turn "please don't" into "can't": no one can leave approved regions, turn off the audit trail, or grant themselves more than their ceiling.

🔧 How (in this repo)

guardrails() in iam/demo.py gives dipika the admin policy with and without the boundary (boundary=), then runs katrina's admin policy under two SCPs (scps=) in two regions. In iam/evaluate.py, steps 2 and 4 of decide() say "must allow, never grants".

🧪 Try it

python3 iam/demo.py guardrails
python3 - <<'EOF'
import sys; sys.path.insert(0, "iam"); from evaluate import decide, load
dipika, katrina = "arn:aws:iam::111122223333:user/dipika", "arn:aws:iam::111122223333:user/katrina"
admin, b = [("admin", load("admin"))], [("boundary-developers", load("boundary-developers"))]
print("boundary alone      ", decide(dipika, "s3:PutObject", "arn:aws:s3:::dev-scratch/x", identity=[], boundary=b)[0])
deny_only = [("scp-two-regions", load("scp-two-regions"))]
print("SCP deny-list only  ", decide(katrina, "ec2:RunInstances", "*", {"aws:RequestedRegion": "ap-south-1"}, identity=admin, scps=deny_only))
scps = [("scp-full-access", load("scp-full-access"))] + deny_only
print("IAM from sa-east-1  ", decide(katrina, "iam:CreateUser", "*", {"aws:RequestedRegion": "sa-east-1"}, identity=admin, scps=scps)[0])
EOF

On a real account (needs the AWS CLI and credentials; the SCP commands run from the organization's management account, and the IDs are examples):

aws iam create-policy --policy-name boundary-developers --policy-document file://iam/policies/boundary-developers.json
aws iam put-user-permissions-boundary --user-name dipika --permissions-boundary arn:aws:iam::111122223333:policy/boundary-developers
aws organizations create-policy --name two-regions --type SERVICE_CONTROL_POLICY --description "Only ap-south-1 and us-east-1" --content file://iam/policies/scp-two-regions.json
aws organizations attach-policy --policy-id p-examplepolicyid111 --target-id ou-ab12-cd34ef56

✅ Verify — what you should see

guardrails prints ✅ ALLOW for dipika's admin without a boundary, 🚫 IMPLICIT DENY — outside the permission boundary — the boundary is a ceiling, not a grant with it, ✅ ALLOW for s3:PutObject (inside the ceiling), ✅ ALLOW in ap-south-1 and ⛔ DENY — explicit Deny in SCP scp-two-regions#OnlyMumbaiAndVirginia in sa-east-1. Your snippet prints IMPLICIT DENY (a boundary grants nothing), then ('IMPLICIT DENY', "the organization's SCPs do not allow this action for the account") — without FullAWSAccess nothing is allowed even in an approved region — and ALLOW for iam:CreateUser from sa-east-1, because the SCP's NotAction exempts IAM.

🏁 What you just proved

Boundaries and SCPs only ever take away: an admin policy under a ceiling is only as strong as the ceiling, and a ceiling with no Allow under it allows nothing.

⚠️ Common mistakes

detaching FullAWSAccess while testing — every account under it stops working
a region SCP without global-service exemptions — IAM, billing or CloudFront break
expecting an SCP to restrict the management account (it does not; keep workloads out of it)
a boundary on developers but letting them edit or remove the boundary itself

🏭 Why this matters in production: a multi-account landing zone always ships baseline SCPs — deny leaving the organization, deny disabling CloudTrail and GuardDuty, deny unapproved regions, deny root-user actions — and boundaries for any team allowed to create roles.

⏭️ Next

A partner school's auditor needs to read your reports. Cross-account access and resource policies — two doors, two keys.

git checkout lesson-09-cross-account

← Previousconditions abac Next →cross account

This page is the lesson's README from the lesson-08-guardrails branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.