{"id":"l-aws-2-2","courseId":"aws-cloud-foundations","lang":"en","kind":"lesson","summary":"Read any IAM policy statement by statement, write least-privilege policies with exact ARNs, and add conditions such as MFA and TLS that tighten when an allow applies.","html":"

In the last lesson you learned how IAM decides. Now you write what it decides from. Lantern needs a policy for the function that receives poster uploads, a policy for the developers, and a bucket policy that protects the posters. All three are the same small JSON language.

\n

Anatomy of a statement

\n

Here is the policy for Lantern’s upload function, which saves posters under uploads/ and occasionally lists what is there:

\n
lantern-upload-policy.json
{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"WriteUploads\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"s3:PutObject\",\n      \"Resource\": \"arn:aws:s3:::lantern-posters/uploads/*\"\n    },\n    {\n      \"Sid\": \"ListUploadsOnly\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"s3:ListBucket\",\n      \"Resource\": \"arn:aws:s3:::lantern-posters\",\n      \"Condition\": {\n        \"StringLike\": { \"s3:prefix\": \"uploads/*\" }\n      }\n    }\n  ]\n}
\n

Read it top to bottom:

\n\n

Resource-based policies, such as bucket policies, add a Principal element naming who the statement is about. Identity-based policies don’t have one, because the identity they are attached to is the principal.

\n

Bucket ARN or object ARN?

\n

The policy above has two different resources on purpose. s3:ListBucket is an operation on the bucket, so its resource is arn:aws:s3:::lantern-posters. s3:PutObject is an operation on objects, so its resource is the bucket ARN followed by a path: lantern-posters/uploads/*. Swap them and neither statement ever matches, and you get AccessDenied with a policy that looks right.

\n

The same distinction exists elsewhere. DynamoDB’s dynamodb:Query on a table index needs the index ARN (table/lantern-rsvps/index/by-event), not only the table ARN. When a policy “obviously” allows something and AWS says no, compare the request’s ARN with the policy’s character by character.

\n\n

Least privilege, in practice

\n

Least privilege means granting only the actions and resources a job needs. It sounds slow, but the workflow is quick:

\n
    \n
  1. Write down what the job does in plain words: “write posters to uploads/, list that prefix”.
    2. \n
  2. Translate each verb into an action, and each noun into an exact ARN.
    3. \n
  3. Deploy and test. An AccessDenied message names the missing action and resource; add exactly that.
    4. \n
\n

For existing roles, IAM shows last accessed information per service, and IAM Access Analyzer can generate a policy from the actions a role actually used according to AWS CloudTrail. Both are good ways to shrink a policy that grew too wide.

\n

Conditions: when an allow applies

\n

A condition block maps operators to keys and values:

\n
JSON
\"Condition\": {\n  \"StringEquals\": { \"aws:RequestedRegion\": [\"eu-west-1\", \"eu-south-2\"] },\n  \"Bool\": { \"aws:MultiFactorAuthPresent\": \"true\" }\n}
\n

Two rules make conditions predictable. Separate keys are ANDed: the request must be in one of those Regions and made with MFA. Multiple values for one key are ORed: either Region will do.

\n

Useful keys for Lantern:

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
KeyUse it to
aws:SecureTransportrefuse plain-HTTP requests
aws:MultiFactorAuthPresentrequire MFA for risky actions such as deletes
aws:SourceIplimit a human to the office or VPN range
aws:RequestedRegionkeep work inside Lantern’s Regions
s3:prefixlimit ListBucket to a folder

Conditions also make great deny guardrails. Lantern’s bucket policy refuses any request without TLS, from anyone:

\n
lantern-posters-bucket-policy.json
{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"DenyInsecureTransport\",\n      \"Effect\": \"Deny\",\n      \"Principal\": \"*\",\n      \"Action\": \"s3:*\",\n      \"Resource\": [\n        \"arn:aws:s3:::lantern-posters\",\n        \"arn:aws:s3:::lantern-posters/*\"\n      ],\n      \"Condition\": { \"Bool\": { \"aws:SecureTransport\": \"false\" } }\n    }\n  ]\n}
\n

Because an explicit deny always wins, no allow anywhere can undo it.

\n

Validate before you attach

\n

The IAM console’s policy editor runs IAM Access Analyzer checks as you type: syntax errors, invalid actions, and security warnings such as a pass-role wildcard. From the terminal:

\n
Terminal
aws accessanalyzer validate-policy \\\n  --policy-type IDENTITY_POLICY \\\n  --policy-document file://lantern-upload-policy.json \\\n  --query \"findings[].[findingType,issueCode]\" --output table
\n

An empty result means no findings. Fix every ERROR and SECURITY_WARNING, and read each WARNING and SUGGESTION.

\n\n

You can now write tight permissions. Next: how people get them without IAM users, and how code gets them without access keys.

\n","toc":[{"id":"sec-1","text":"Anatomy of a statement","level":2},{"id":"sec-2","text":"Bucket ARN or object ARN?","level":2},{"id":"sec-3","text":"Least privilege, in practice","level":2},{"id":"sec-4","text":"Conditions: when an allow applies","level":2},{"id":"sec-5","text":"Validate before you attach","level":2}],"takeaways":["A statement is Effect plus Action plus Resource, optionally narrowed by a Condition; resource-based policies also name a Principal.","Bucket-level actions such as s3:ListBucket take the bucket ARN, while object-level actions such as s3:GetObject need the bucket ARN followed by /* or a narrower path.","Least privilege means listing the specific actions and resources a job needs, then widening only when a real AccessDenied tells you to.","Condition keys are ANDed with each other, and multiple values for one key are ORed.","Validate every policy before attaching it with IAM Access Analyzer, in the console editor or with aws accessanalyzer validate-policy."],"further":[{"title":"IAM JSON policy element reference","url":"https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html"},{"title":"AWS global condition context keys","url":"https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html"},{"title":"Security best practices in IAM","url":"https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html"},{"title":"Validate policies with IAM Access Analyzer","url":"https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html"}],"quiz":[{"q":"

A function with this policy calls GetObject on posters/2026/festival.jpg in the lantern-posters bucket and gets AccessDenied. Why?

\n
JSON
{\n  \"Effect\": \"Allow\",\n  \"Action\": \"s3:GetObject\",\n  \"Resource\": \"arn:aws:s3:::lantern-posters\"\n}
\n","options":[{"text":"The Action should be s3:Get* because GetObject is not a real action name.","why":"s3:GetObject is the real action. A wildcard would only broaden the policy without fixing the actual problem."},{"text":"The Resource is the bucket, but GetObject acts on objects, so it needs arn:aws:s3:::lantern-posters/*.","why":"Correct. Object actions match object ARNs. Without /* (or a narrower path) the statement never matches the request."},{"text":"S3 policies must include a Principal element, so the statement is ignored.","why":"Identity-based policies have no Principal; the identity they are attached to is the principal. Only resource-based policies need one."},{"text":"The Version line is missing, so IAM rejects the whole policy.","why":"Without a Version, IAM falls back to the old 2008 language and policy variables stop working, but a simple statement like this still matches."}],"answer":1},{"q":"

Which requests does this condition allow?

\n
JSON
\"Condition\": {\n  \"StringEquals\": { \"aws:RequestedRegion\": [\"eu-west-1\", \"eu-south-2\"] },\n  \"Bool\": { \"aws:SecureTransport\": \"true\" }\n}
\n","options":[{"text":"Requests to either Region, whether or not they use TLS.","why":"The two keys are ANDed, so the TLS check still applies to every request."},{"text":"Requests that use TLS, to any Region.","why":"Different keys are ANDed. The Region key still has to match one of its listed values."},{"text":"Requests to eu-west-1 or eu-south-2 that also use TLS.","why":"Correct. Values inside one key are ORed (either Region) and separate keys are ANDed (and TLS)."}],"answer":2},{"q":"

You need a policy for Lantern’s poster-resize function but you are not sure which S3 actions it calls. What is the best starting point?

","options":[{"text":"Grant s3:* on * and narrow it later when there is time.","why":"“Later” rarely comes, and in the meantime any bug or compromise in the function can touch every bucket in the account."},{"text":"Grant the actions you know it needs on the exact bucket path, then add actions only when a real AccessDenied shows they are missing.","why":"Correct. AccessDenied errors name the missing action, so widening on evidence is fast and keeps the policy tight."},{"text":"Attach the AWS managed AmazonS3FullAccess policy because AWS maintains it.","why":"AWS maintains the policy text, not its fit for your job. Full access to every bucket is far broader than one function needs."}],"answer":1},{"q":"

What does this bucket policy statement do?

\n
JSON
{\n  \"Effect\": \"Deny\",\n  \"Principal\": \"*\",\n  \"Action\": \"s3:*\",\n  \"Resource\": [\"arn:aws:s3:::lantern-posters\", \"arn:aws:s3:::lantern-posters/*\"],\n  \"Condition\": { \"Bool\": { \"aws:SecureTransport\": \"false\" } }\n}
\n","options":[{"text":"Blocks every request to the bucket, including from admins.","why":"The condition limits it to requests where SecureTransport is false, meaning plain HTTP. HTTPS requests are unaffected."},{"text":"Blocks any request made over plain HTTP, from anyone.","why":"Correct. It is a standard guardrail. Combined with the explicit-deny rule, nobody can read or write the bucket without TLS."},{"text":"Allows anonymous users to read the bucket over HTTPS.","why":"A Deny statement never grants anything. Public access would need an Allow and Block Public Access turned off."}],"answer":1}],"exercise":{"kind":"spot-bug","language":"json","code":"{\n \"Version\": \"2012-10-17\",\n \"Statement\": [\n {\n \"Sid\": \"ReadWriteRsvps\",\n \"Effect\": \"Allow\",\n \"Action\": \"dynamodb:*\",\n \"Resource\": \"arn:aws:dynamodb:eu-west-1:111122223333:table/lantern-rsvps\"\n },\n {\n \"Sid\": \"ReadPosters\",\n \"Effect\": \"Allow\",\n \"Action\": \"s3:GetObject\",\n \"Resource\": \"arn:aws:s3:::lantern-posters\"\n },\n {\n \"Sid\": \"DeletePostersOnlyWithMfa\",\n \"Effect\": \"Allow\",\n \"Action\": \"s3:DeleteObject\",\n \"Resource\": \"arn:aws:s3:::lantern-posters/*\",\n \"Condition\": {\n \"Bool\": { \"aws:MultiFactorAuthPresent\": \"false\" }\n }\n }\n ]\n}","bugLines":[7,14,22],"title":"Review the Developers policy","prompt":"

A colleague wrote this identity-based policy for Lantern’s Developers group. The intent, from the ticket: developers can read and write RSVPs (get, put and query items) in the lantern-rsvps table, read any poster in the lantern-posters bucket, and delete posters only when signed in with MFA. Select every line that breaks that intent.

\n","hints":["Compare each Action with the verbs in the ticket. Is anything broader than asked?","Is s3:GetObject a bucket-level or an object-level action? Check its Resource.","Read the MFA condition out loud: the statement applies when MFA present is … what?"],"explanation":"

Line 7 grants dynamodb:*, which includes DeleteTable and UpdateTable; the ticket needs only dynamodb:GetItem, dynamodb:PutItem and dynamodb:Query, so list those. Line 14 uses the bucket ARN for s3:GetObject, an object-level action, so the statement never matches a real download; it needs arn:aws:s3:::lantern-posters/*. Line 22 inverts the condition: it allows deletes only when MFA is absent. It should be "aws:MultiFactorAuthPresent": "true". Fixed lines:

\n
JSON
\"Action\": [\"dynamodb:GetItem\", \"dynamodb:PutItem\", \"dynamodb:Query\"],\n\"Resource\": \"arn:aws:s3:::lantern-posters/*\"\n\"Bool\": { \"aws:MultiFactorAuthPresent\": \"true\" }
\n

Policy validation can flag some of these, but the inverted MFA condition is perfectly valid JSON and a perfectly valid policy. Only reading the policy against the intent catches it.

\n","checkLabels":{}},"words":700,"readMinutes":3}