Service accounts
Long-lived access keys for scripts and CI.
Roles
Permissions something else borrows, gated by a trust policy.
Temporary credentials
Assume a role, optionally scoped down further.
Instance identity
A VM that gets credentials with no secret to deploy.
Service accounts
A service account is a non-human identity that holds access keys. Create one, give it permissions, then create a credential on it:access_key_id and secret_access_key.
A service account starts with no permissions. Attach a policy directly, or
put it in a group that carries one — groups hold service accounts as well as
users.
Roles
A role is a set of permissions with no credentials of its own. Something else assumes it and gets temporary credentials that authorize as the role. A role has two halves:Permission policies
What the role can do. Attached exactly like a user’s or service account’s
policies.
Trust policy
Who is allowed to assume it. Without this, nobody can.
Trust policies
The trust policy lists CRN patterns matched against the caller’s own CRN:principals gates who; conditions gates under what circumstances.
Both must hold.
* is the only wildcard and the colon/slash layout is compared literally. A
pattern written in any other shape matches nothing — it does not fail loudly,
it simply never matches, so check the shape when a trust policy seems to be
ignored.Assuming a role
access_key_id, secret_access_key, a session_token
and an expiration. Sign requests as usual, and send the session token as
X-Amz-Security-Token — it must also appear in SignedHeaders. See
authentication.
900–43200, default 3600
15 minutes to 12 hours.
Scoping a session down
policy on the assume-role call attaches a session policy to the
credentials being minted:
INVALID_INPUT rather than being
ignored.
Watching sessions
Giving an instance an identity
This is the reason roles are worth the setup: an instance can hold credentials without any secret being deployed to it.1
Write a trust policy that accepts instances
2
Attach permission policies to the role
Whatever the workload actually needs — and no more, since anything running
on the instance can reach these credentials.
3
Launch the instance with the role
4
Read credentials from inside the VM
The instance metadata service at
169.254.169.254 mints and serves
temporary credentials for the attached role. They rotate before expiry, so
a process that re-reads them keeps working indefinitely.Nothing secret is ever written to the instance. The metadata service
identifies the caller by which instance it is, mints a session against the
attached role, and hands back credentials that expire on their own.
Which identity to use
CI pipeline
CI pipeline
A service account with an access key, stored in the CI secret store.
Scope it to the account and the actions the pipeline needs. If the pipeline
does several unrelated things, prefer several service accounts over one
broad key.
Software running on an instance
Software running on an instance
An instance role. No secret is deployed, credentials rotate on their
own, and revoking access is a change to the role rather than a redeploy.
A person doing operational work
A person doing operational work
Their user, through the console. If they need programmatic access, give
them a service account whose permissions match what they are allowed to do
— not a copy of their own.
Granting temporary elevated access
Granting temporary elevated access
A role with a trust policy naming who may assume it, plus a short
duration_seconds. The assumption is recorded as an STS session, so the
elevation is visible and revocable rather than implicit.Next
Writing policies
What to put in a role’s permission policies.
Permission boundaries
A role’s boundary caps its sessions too.