{"id":"l-aws-2-3","courseId":"aws-cloud-foundations","lang":"en","kind":"lesson","summary":"Give people access through IAM Identity Center and code access through IAM roles, so that Lantern runs with no long-term access keys on laptops, servers or in Git.","html":"

Section one ended with one admin user for one person in one account. Lantern now has six volunteers, a dev account and a production account, a Lambda function and a nightly job on EC2. If every one of those needs an IAM user with access keys, you end up with a dozen long-lived secrets scattered across laptops and servers. This lesson removes nearly all of them.

\n

People: IAM Identity Center

\n

AWS IAM Identity Center is where your workforce signs in. Each person gets one identity, either in Identity Center’s built-in directory or synced from an identity provider such as Microsoft Entra ID, Okta or Google Workspace. They sign in once, with MFA, at an AWS access portal URL, and see every account they are allowed into.

\n

What they can do in each account comes from permission sets: a named bundle of policies, such as DeveloperAccess or ReadOnly. When you assign “volunteer Rita, permission set DeveloperAccess, account lantern-dev”, Identity Center creates a matching IAM role in that account, and Rita’s session assumes it. Nobody has an IAM user; nobody has a long-term key.

\n

Identity Center is designed to run with AWS Organizations, which groups Lantern’s accounts under one management account. Note one practical catch: on the Free account plan, joining an organisation upgrades the account to the Paid plan, so this is a step for when Lantern goes to production.

\n

On the CLI, aws configure sso writes a profile, and aws sso login opens the browser to sign in:

\n
~/.aws/config
[sso-session lantern]\nsso_start_url = https://lantern.awsapps.com/start\nsso_region = eu-west-1\nsso_registration_scopes = sso:account:access\n\n[profile lantern-dev]\nsso_session = lantern\nsso_account_id = 444455556666\nsso_role_name = DeveloperAccess\nregion = eu-west-1
\n
Terminal
aws sso login --sso-session lantern\naws sts get-caller-identity --profile lantern-dev
\n

The Arn that comes back now reads assumed-role/AWSReservedSSO_DeveloperAccess_…/rita: a role session, not a user.

\n

Workloads: roles, not keys

\n

Code needs credentials too, and the answer is always a role that the platform assumes for you:

\n\n

A role always has two policies. The trust policy says who may assume it:

\n
trust-policy.json
{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Effect\": \"Allow\",\n      \"Principal\": { \"Service\": \"lambda.amazonaws.com\" },\n      \"Action\": \"sts:AssumeRole\"\n    }\n  ]\n}
\n

The permissions policy says what the role may do once assumed, written exactly like last lesson’s policies.

\n
\n The Lambda service asks STS to assume the lantern-rsvp role. STS checks the trust policy and returns temporary credentials. The function code uses them to call DynamoDB, where IAM checks the role's permissions policy.\n \n Lambda\n rsvp function\n \n AWS STS\n checks trust policy\n \n DynamoDB\n checks permissions\n \n 1 AssumeRole\n \n 2 temp credentials\n \n 3 PutItem, signed\n
Lambda assumes its execution role, then calls DynamoDB with temporary credentials
\n

Your code then contains no credentials at all. The AWS SDKs use a default credential chain that finds the role’s temporary credentials automatically:

\n
rsvp/index.mjs
import { DynamoDBClient } from \"@aws-sdk/client-dynamodb\";\n\n// No keys here: the SDK finds the execution role's temporary credentials.\nconst client = new DynamoDBClient({});\n// …handler code that calls client.send(…)
\n

The mistake that ends in a large bill

\n\n

Sometimes an access key is genuinely unavoidable, such as a third-party tool that only accepts keys. Then: one IAM user per tool, a least-privilege policy, a aws:SourceIp condition if the tool has fixed addresses, and rotation on a schedule.

\n

Retiring an existing key is a careful sequence, because deleting a key that something still uses breaks production. Check when it was last used:

\n
Terminal
aws iam get-access-key-last-used --access-key-id AKIAIOSFODNN7EXAMPLE
\n

Once nothing has used it since the replacement went live, deactivate it first (reversible), wait, and delete it only when nothing has complained. A key you suspect has leaked is different: deactivate it immediately and investigate afterwards.

\n\n

That completes identity. Section three puts it to work as you pick Lantern’s compute, storage, database and network.

\n","toc":[{"id":"sec-1","text":"People: IAM Identity Center","level":2},{"id":"sec-2","text":"Workloads: roles, not keys","level":2},{"id":"sec-3","text":"The mistake that ends in a large bill","level":2}],"takeaways":["IAM Identity Center gives each person one sign-in, with MFA, to every account they need, and hands out short-term credentials through permission sets.","Workloads get permissions from roles, such as a Lambda execution role or an EC2 instance profile, and the AWS SDKs find those temporary credentials without any code.","A role has two policies; the trust policy says who may assume it, and the permissions policy says what it may then do.","Long-term access keys in code, config files or environment variables are one of the most common ways AWS accounts get compromised.","When retiring an access key, confirm it is unused with its last-used date, deactivate it, and only then delete it."],"further":[{"title":"What is IAM Identity Center?","url":"https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html"},{"title":"Configuring IAM Identity Center authentication with the AWS CLI","url":"https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html"},{"title":"Defining Lambda function permissions with an execution role","url":"https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html"},{"title":"Manage access keys for IAM users","url":"https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html"}],"quiz":[{"q":"

Lantern’s RSVP function must write to DynamoDB. How should it get credentials?

","options":[{"text":"Store an IAM user’s access key in the function’s environment variables.","why":"Anyone who can read the function configuration can read the key, and it never expires. Environment variables are not a secret store."},{"text":"Give the function an execution role with a permissions policy for the table; the SDK picks up its temporary credentials.","why":"Correct. Lambda assumes the role for you and hands each execution environment short-term credentials, so there is nothing to leak or rotate."},{"text":"Use the root user’s credentials, since the function needs reliable access.","why":"Root credentials are unrestricted and should never exist as access keys, let alone inside code."}],"answer":1},{"q":"

A role’s permissions policy allows dynamodb:PutItem on the RSVP table, but EC2 instances fail to assume the role. Which policy is most likely wrong?

","options":[{"text":"The trust policy, which must name ec2.amazonaws.com as a principal allowed to call sts:AssumeRole.","why":"Correct. Who may assume a role is decided by the trust policy alone. The permissions policy only matters after the role has been assumed."},{"text":"The permissions policy, which must also allow sts:AssumeRole.","why":"A role does not need permission to assume itself. That is the trust policy’s job."},{"text":"The DynamoDB table policy, which must list the EC2 instance ID.","why":"The instance is never the principal in DynamoDB calls; the assumed-role session is. And assumption fails before DynamoDB is involved."}],"answer":0},{"q":"

Lantern now has separate dev and production accounts and six volunteers. What is the best way to give the volunteers console and CLI access?

","options":[{"text":"An IAM user per volunteer in each account, each with its own password and MFA.","why":"That is twelve sets of credentials to manage and revoke. It works, but it scales badly and leaves long-term credentials behind."},{"text":"One shared IAM user per account with a strong password kept in a password manager.","why":"Shared users destroy accountability and make removing one person impossible without rotating everyone’s access."},{"text":"IAM Identity Center users, with permission sets assigned per account, signing in through the access portal and aws sso login.","why":"Correct. Each person has one identity and MFA, access is short-term, and removing someone is a single change."}],"answer":2}],"exercise":{"kind":"order","items":["write-policy","create-role","attach-profile","remove-keys","verify-identity","check-last-used","deactivate","delete"],"title":"Retire the nightly job's access key","prompt":"

Lantern’s nightly export job runs on an EC2 instance and reads an access key from /etc/lantern/.env. The key has not leaked; you are replacing it with a role during a quiet week, without breaking the job. Put the steps in a safe order.

\n","hints":["The role must exist, with the right permissions, before anything can use it.","Prove the job is running as the role before you touch the old key.","Removing access is done in two stages: one reversible, one permanent."],"explanation":"

You build the replacement first: a least-privilege policy, a role whose trust policy allows ec2.amazonaws.com, and an instance profile that puts the role on the instance. Then you remove the key from the instance so the SDK falls through to the role’s credentials, and you prove it with aws sts get-caller-identity on the instance, which should show an assumed-role ARN. Only then do you look at the old key: get-access-key-last-used confirms nothing has used it since the switch. Deactivating is reversible if something you forgot breaks; deleting is final, so it comes last. If the key had leaked, you would deactivate it first, immediately, and accept the breakage.

\n","checkLabels":{},"itemText":{"write-policy":"Write a least-privilege permissions policy for exactly what the export job does.","create-role":"Create a role with a trust policy for ec2.amazonaws.com and attach the permissions policy.","attach-profile":"Attach the role to the EC2 instance through an instance profile.","remove-keys":"Remove the access key from /etc/lantern/.env and restart the job.","verify-identity":"On the instance, run aws sts get-caller-identity and confirm the ARN is an assumed-role session.","check-last-used":"Run aws iam get-access-key-last-used after the next nightly run to confirm the old key is idle.","deactivate":"Deactivate the old access key and watch the next few runs.","delete":"Delete the old access key."}},"words":668,"readMinutes":3}