Identity Center for People, Roles for Workloads

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.

People: IAM Identity Center

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.

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.

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.

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

[sso-session lantern]
sso_start_url = https://lantern.awsapps.com/start
sso_region = eu-west-1
sso_registration_scopes = sso:account:access

[profile lantern-dev]
sso_session = lantern
sso_account_id = 444455556666
sso_role_name = DeveloperAccess
region = eu-west-1

aws sso login --sso-session lantern
aws sts get-caller-identity --profile lantern-dev

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

Workloads: roles, not keys

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

• Lambda: every function has an execution role.
• EC2: an instance profile delivers the role’s credentials through the instance metadata service.
• Amazon ECS: a task role per task definition.
• CI/CD outside AWS, such as GitHub Actions: an OpenID Connect identity provider in IAM, so the pipeline exchanges its own token for a role session.

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

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

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

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

import { DynamoDBClient } from "@aws-sdk/client-dynamodb";

// No keys here: the SDK finds the execution role's temporary credentials.
const client = new DynamoDBClient({});
// …handler code that calls client.send(…)

The mistake that ends in a large bill

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.

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

aws iam get-access-key-last-used --access-key-id AKIAIOSFODNN7EXAMPLE

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.

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