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

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

🤝 धडा 09 — Cross-account आणि resource policies: दोन दरवाजे, दोन चाव्या

📍 तुम्ही इथे आहात: 12 पैकी धडा 09 · मागील: lesson-08-guardrails · पुढील: lesson-10-people-at-scale

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

धडे 01–08, आणि resource-based policies — वस्तूवरच असलेली policy (S3 bucket policy, bucket-policy-reports.json) जी Principal ने कोण ते सांगते — आणि cross-account access, जिथे partner account चा role (partner-auditor-identity.json) शाळेचे reports वाचतो.

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

Partner शाळेच्या auditor ला तुमची प्रगतिपुस्तके वाचायची आहेत. दोन कार्यालयांनी मान्य करायला हवे:

तिच्या स्वतःच्या शाळेच्या कार्यालयाने म्हणायला हवे "हो, आमची auditor इतर शाळांचे reports वाचू शकते" (तिची identity policy).
तुमच्या शाळेच्या कार्यालयाने म्हणायला हवे "हो, ती auditor आमचे reports वाचू शकते" — reports च्या कपाटावरच लावलेली चिठ्ठी (bucket policy).

दोन दरवाजे 🚪🚪, दोन चाव्या 🔑🔑. एकाच कार्यालयाने हो म्हटले तर ती बाहेरच राहते. एकाच शाळेत हे सोपे असते: कपाटावरची, एखाद्या शिक्षिकेचे नाव असलेली चिठ्ठी एकटीच पुरेशी असते.

🗺️ आकृती

flowchart LR
    aud["🕵️ role/partner-auditor<br/>account 444455556666"]
    idp["📝 her identity policy<br/>s3:GetObject school-reports/*"]
    bp["📌 bucket policy on school-reports<br/>Principal: role/partner-auditor"]
    obj["📄 school-reports/term1.pdf<br/>account 111122223333"]
    aud -->|"1 her account says yes"| idp
    idp -->|"2 the bucket says yes"| bp
    bp -->|"both"| obj
    obj --> ok["✅ ALLOW"]

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

❓ काय

Resource-based policy — resource ला जोडलेली: S3 bucket policies, KMS key policies, SQS queue आणि SNS topic policies, Lambda function policies, ECR repository policies, आणि प्रत्येक role ची trust policy. तिच्यात Principal असतो.
त्याच account मध्ये — identity policy किंवा resource policy, यांपैकी एकाने allow केले तरी पुरेसे (जोपर्यंत काहीतरी deny करत नाही).
Cross-account — दोघांनी allow करायला हवे: caller चे account (identity policy, आणि त्याच्या boundaries व SCPs) आणि दुसऱ्या account मधील resource policy.
Principal चे प्रकार — role किंवा user ARN (नेमका तोच), किंवा arn:aws:iam::444455556666:root, ज्याचा अर्थ ते account — "त्या account च्या स्वतःच्या policies ज्याला allow करतात तो कोणीही" — त्याचा root user नव्हे.
पलीकडे जाण्याचे दोन मार्ग — दुसऱ्या account चे नाव घेणारी resource policy (हा धडा), किंवा तुमच्या account मधील एक role जो partner assume करतो (trust policy + त्यांची sts:AssumeRole permission). Roles प्रत्येक service साठी चालतात; resource policies फक्त त्या असलेल्या services साठी.
Confused deputy — जेव्हा एखादा third party तुमचा role assume करतो, तेव्हा sts:ExternalId आवश्यक करा; AWS service principals साठी aws:SourceArn / aws:SourceAccount तपासा.
Encryption हा तिसरा दरवाजा आहे — customer managed KMS key खालील objects साठी key policy नेही partner ला allow करायला हवे (kms:Decrypt).

🤔 का

खऱ्या organizations कडे अनेक accounts असतात (प्रत्येक team साठी, प्रत्येक environment साठी), शिवाय partners आणि vendors. Cross-account access मुळे ते credentials न देता share करू शकतात — आणि चुकीची वाचलेली bucket policy ("Principal": "*") ही public-data गळतीचे क्लासिक उदाहरण आहे.

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

iam/demo.py मधील crossaccount() partner auditor साठी decide() ला resource_policy= आणि resource_account= (शाळेचे account) देऊन बोलावते: दोन्ही बाजू, फक्त bucket, फक्त identity, आणि एक delete. iam/evaluate.py मधील _principal_ok() resource policy चा Principal तपासते, account प्रकार …:root सकट.

🧪 करून पाहा

python3 iam/demo.py crossaccount
python3 - <<'EOF'
import sys; sys.path.insert(0, "iam"); from evaluate import decide, load
R, SCHOOL = "arn:aws:s3:::school-reports/term1.pdf", "111122223333"
ident = [("partner-auditor-identity", load("partner-auditor-identity"))]
named = ("bucket-policy-reports", load("bucket-policy-reports"))
whole = ("bucket-policy-account", {"Version": "2012-10-17", "Statement": [{"Sid": "TrustPartnerAccount", "Effect": "Allow",
         "Principal": {"AWS": "arn:aws:iam::444455556666:root"}, "Action": "s3:GetObject", "Resource": "arn:aws:s3:::school-reports/*"}]})
intern = "arn:aws:iam::444455556666:role/partner-intern"
print("intern, bucket names auditor ", decide(intern, "s3:GetObject", R, identity=ident, resource_policy=named, resource_account=SCHOOL)[0])
print("intern, bucket trusts account", decide(intern, "s3:GetObject", R, identity=ident, resource_policy=whole, resource_account=SCHOOL)[0])
print("intern, account, no own grant", decide(intern, "s3:GetObject", R, identity=[], resource_policy=whole, resource_account=SCHOOL)[0])
EOF

खऱ्या account वर (AWS CLI आणि credentials लागतात; S3 policy स्वीकारण्याआधी role arn:aws:iam::444455556666:role/partner-auditor अस्तित्वात असायला हवा):

aws s3api put-bucket-policy --bucket school-reports --policy file://iam/policies/bucket-policy-reports.json
aws s3api get-bucket-policy --bucket school-reports --query Policy --output text
aws s3 cp s3://school-reports/term1.pdf . --profile partner-auditor      # run as the partner's role

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

crossaccount छापते ✅ ALLOW — cross-account: identity policy partner-auditor-identity#ReadSchoolReports AND resource policy bucket-policy-reports#PartnerAuditorReads both allow, मग तीन 🚫 IMPLICIT DENY ओळी: फक्त bucket (the caller's identity policy does not), फक्त identity (the resource policy in the other account does not), आणि DeleteObject. तुमचा snippet छापतो IMPLICIT DENY (bucket auditor चे नाव घेते, intern चे नाही), ALLOW (bucket संपूर्ण partner account वर विश्वास ठेवते, आणि partner ची स्वतःची policy intern ला परवानगी देते) आणि IMPLICIT DENY (account वर विश्वास ठेवणे पुरेसे नाही — partner नेही ती परवानगी द्यायला हवी).

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

Accounts ओलांडताना दोन्ही बाजूंनी हो म्हणायला हवे; …:root चे नाव घेतल्याने कोण हे निवडण्याचे काम दुसऱ्या account च्या स्वतःच्या policies कडे सोपवले जाते.

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

मजबूत condition शिवाय (जसे aws:PrincipalOrgID) "Principal": "*" — ते public आहे
arn:aws:iam::ACCOUNT:root चा अर्थ "फक्त त्यांचा root user" असा घेणे — ते संपूर्ण account आहे
bucket policy मध्ये परवानगी देणे आणि caller ची बाजू (किंवा KMS key policy) विसरणे
ExternalId शिवाय third-party roles

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: IAM Access Analyzer चे external access findings तुमच्या account किंवा organization बाहेर share केलेला प्रत्येक resource दाखवतात — ते तपासणे हे कायमचे काम आहे, आणि bucket public असायलाच हवे असे नसेल तर S3 Block Public Access चालूच राहते.

⏭️ पुढे

डझनभर accounts मधील शेकडो कर्मचाऱ्यांसाठी IAM users वाढत्या प्रमाणात चालत नाहीत. लोक मोठ्या प्रमाणावर — IAM Identity Center.

git checkout lesson-10-people-at-scale

🤝 Lesson 09 — Cross-account & resource policies: two doors, two keys

📍 You are here: Lesson 09 of 12 · Previous: lesson-08-guardrails · Next: lesson-10-people-at-scale

📦 What's in this branch

Lessons 01–08, plus resource-based policies — a policy on the thing (an S3 bucket policy, bucket-policy-reports.json) that names who with Principal — and cross-account access, where a partner account's role (partner-auditor-identity.json) reads the school's reports.

🧒 Explain like I'm 5

The partner school's auditor wants to read your report cards. Two offices must agree:

Her own school's office must say "yes, our auditor may read other schools' reports" (her identity policy).
Your school's office must say "yes, that auditor may read our reports" — a note pinned on the report cupboard itself (the bucket policy).

Two doors 🚪🚪, two keys 🔑🔑. If only one office says yes, she stays outside. Inside one school it is easier: a note on the cupboard that names a teacher is enough on its own.

🗺️ Diagram

flowchart LR
    aud["🕵️ role/partner-auditor<br/>account 444455556666"]
    idp["📝 her identity policy<br/>s3:GetObject school-reports/*"]
    bp["📌 bucket policy on school-reports<br/>Principal: role/partner-auditor"]
    obj["📄 school-reports/term1.pdf<br/>account 111122223333"]
    aud -->|"1 her account says yes"| idp
    idp -->|"2 the bucket says yes"| bp
    bp -->|"both"| obj
    obj --> ok["✅ ALLOW"]

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

❓ What

Resource-based policy — attached to a resource: S3 bucket policies, KMS key policies, SQS queue and SNS topic policies, Lambda function policies, ECR repository policies, and every role's trust policy. It has a Principal.
Same account — an identity policy or a resource policy that allows is enough (unless something denies).
Cross-account — both must allow: the caller's account (identity policy, and its boundaries and SCPs) and the resource policy in the other account.
Principal forms — a role or user ARN (exactly that one), or arn:aws:iam::444455556666:root, which means the account — "anyone that account's own policies allow" — not its root user.
Two ways across — a resource policy that names the other account (this lesson), or a role in your account that the partner assumes (trust policy + their sts:AssumeRole permission). Roles work for every service; resource policies only for services that have them.
Confused deputy — when a third party assumes your role, require an sts:ExternalId; for AWS service principals, check aws:SourceArn / aws:SourceAccount.
Encryption is a third door — objects under a customer managed KMS key also need the key policy to allow the partner (kms:Decrypt).

🤔 Why

Real organizations have many accounts (per team, per environment) plus partners and vendors. Cross-account access is how they share without sharing credentials — and a misread bucket policy ("Principal": "*") is the classic public-data leak.

🔧 How (in this repo)

crossaccount() in iam/demo.py calls decide() with resource_policy= and resource_account= (the school's account) for the partner auditor: both sides, bucket only, identity only, and a delete. _principal_ok() in iam/evaluate.py checks the Principal of a resource policy, including the account form …:root.

🧪 Try it

python3 iam/demo.py crossaccount
python3 - <<'EOF'
import sys; sys.path.insert(0, "iam"); from evaluate import decide, load
R, SCHOOL = "arn:aws:s3:::school-reports/term1.pdf", "111122223333"
ident = [("partner-auditor-identity", load("partner-auditor-identity"))]
named = ("bucket-policy-reports", load("bucket-policy-reports"))
whole = ("bucket-policy-account", {"Version": "2012-10-17", "Statement": [{"Sid": "TrustPartnerAccount", "Effect": "Allow",
         "Principal": {"AWS": "arn:aws:iam::444455556666:root"}, "Action": "s3:GetObject", "Resource": "arn:aws:s3:::school-reports/*"}]})
intern = "arn:aws:iam::444455556666:role/partner-intern"
print("intern, bucket names auditor ", decide(intern, "s3:GetObject", R, identity=ident, resource_policy=named, resource_account=SCHOOL)[0])
print("intern, bucket trusts account", decide(intern, "s3:GetObject", R, identity=ident, resource_policy=whole, resource_account=SCHOOL)[0])
print("intern, account, no own grant", decide(intern, "s3:GetObject", R, identity=[], resource_policy=whole, resource_account=SCHOOL)[0])
EOF

On a real account (needs the AWS CLI and credentials; the role arn:aws:iam::444455556666:role/partner-auditor must exist before S3 accepts the policy):

aws s3api put-bucket-policy --bucket school-reports --policy file://iam/policies/bucket-policy-reports.json
aws s3api get-bucket-policy --bucket school-reports --query Policy --output text
aws s3 cp s3://school-reports/term1.pdf . --profile partner-auditor      # run as the partner's role

✅ Verify — what you should see

crossaccount prints ✅ ALLOW — cross-account: identity policy partner-auditor-identity#ReadSchoolReports AND resource policy bucket-policy-reports#PartnerAuditorReads both allow, then three 🚫 IMPLICIT DENY lines: bucket only (the caller's identity policy does not), identity only (the resource policy in the other account does not), and DeleteObject. Your snippet prints IMPLICIT DENY (the bucket names the auditor, not the intern), ALLOW (the bucket trusts the whole partner account, and the partner's own policy lets the intern) and IMPLICIT DENY (trusting the account is not enough — the partner must also grant it).

🏁 What you just proved

Across accounts, both sides must say yes; naming …:root delegates the choice of who to the other account's own policies.

⚠️ Common mistakes

"Principal": "*" without a strong condition (such as aws:PrincipalOrgID) — that is public
reading arn:aws:iam::ACCOUNT:root as "only their root user" — it is the whole account
granting in the bucket policy and forgetting the caller's side (or the KMS key policy)
third-party roles without an ExternalId

🏭 Why this matters in production: IAM Access Analyzer's external access findings list every resource shared outside your account or organization — reviewing them is a standing task, and S3 Block Public Access stays on unless a bucket is meant to be public.

⏭️ Next

IAM users for hundreds of staff across dozens of accounts do not scale. People at scale — IAM Identity Center.

git checkout lesson-10-people-at-scale

← Previousguardrails Next →people at scale

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