IAM
Intermediate 14 min read IAM

Service Accounts and Machine Identity

Identities for code, not just people

Machines need identities too: service accounts, managed identities and instance profiles. The trick is giving each workload its own least-privilege machine identity, rotated and short-lived.

service accountmachine identitymanaged identityinstance profileworkload
Prerequisites: Identities and Principals
Before we start

What you will learn

  • Give each workload its own machine identity
  • Use managed identities where possible
  • Rotate and scope machine credentials
In 60 seconds

Service accounts (GCP), managed identities (Azure), and instance profiles (AWS) are machine identities. Each workload gets its own scoped identity; credentials are ephemeral (OIDC, metadata) or rotated regularly — never a shared key.

Introduction

What is this?

Machine identity: AWS instance profiles attach to EC2/ECS/ECS/Fargate and lambdas; Azure managed identities (system- or user-assigned) back VM/App Service/Function; GCP service accounts are used by compute, GKE, and CI. Credential retrieval: EC2 metadata/IDMSv2 (rotate), Azure IMDS (rotate), GCP service account keys (long-lived — restrict), or OIDC federation. Best practice is ephemeral token flows where possible.

Motivation

Why do you need it?

  • Storing a shared key in code is the top IAM leak vector by far.
  • Per-workload identities give precise audit and minimal blast radius.
  • Clouds rotate machine tokens automatically — less to manage than your own key service.
  • The same least-privilege design applies: your CI isn't 'someone', it's a scoped identity.
Think about it

Mental model

Imagine

A vending machine with its own key card vs the janitor's master key

Think of

Machine identity

The vending machine operator has a card that only refills sodas. Nobody left a master key inside the machine 'just in case'. Machine identities are scoped cards for the machines themselves.

Mechanics

How it works

  • AWS: instance profile attaches an IAM role; EC2 metadata service gives the role credentials (short-lived, rotated).
  • Azure: managed identity registers a principal; IMDS mints a token scoped by the identity's role assignments.
  • GCP: service account with scoped roles; workload identity federation avoids long-lived SA keys.
  • OIDC/CI: workload identity federation everywhere there isn't a native identity chain.
  • GitOps/secret hygiene: secrets go to Secret Manager/Key Vault, never the image.

Machine identity paths.

VM/Container/Function
Metadata/implicit
OIDC (CI)
Service account
Cloud APIs
Real world

In production

  • Every ECS task carries its own IAM role; no shared keys in the image.
  • A web app uses an Azure managed identity to read Key Vault secrets — no connection strings in config.
  • GCP Workload Identity for GKE: pods assume a scoped KSG account without JSON keys.
Guidelines

Best practices

  • One identity per workload; scoped policies per identity.
  • Prefer ephemeral tokens (IMDS/metadata/OIDC) over long-lived keys.
  • Rotate service account keys (GCP) aggressively; prefer workload identity to avoid keys entirely.
  • Never bake secrets into images or repos — inject via vault/temp secrets.
Watch out

Common mistakes

  • A single service account used by all app tiers (no isolation).
  • Long-lived GCP SA keys exported to configuration repos.
  • Giving the instance's role more than the app needs because 'it's easier'.
  • Forgetting machine identities when offboarding/rotating.
Root cause analysis

Common issues

Error
App fails to read a secret from Key Vault
Root cause

Managed identity lacks a Key Vault access policy / role

Fix

Grant the identity Key Vault Secrets User and re-authenticate the app session.

Error
GKE pod can't access GCS
Root cause

Workload identity binding missing or wrong SA annotation

Fix

Check the pod's serviceAccountName + the IAM binding between pod SA and GCS SA.

Error
Lambda can't call DynamoDB
Root cause

Execution role lacks the DynamoDB action

Fix

Attach a scoped policy to the role and re-test.

When things break

Debugging tips

  • 'Not authorized' in an app → check which identity the runtime actually assumed (metadata, session).
  • Keys, roles and usage audit: who can create SA keys, and which are still active?
  • For Azure: verify the identity has a role assignment at the exact scope.
  • For GKE: workload identity requires both the IAM binding and the annotation.
Interviews

Interview checkpoint

Practice

Hands-on lab

Lock Down a Machine Identity
25 min · intermediate
In progress
Objectives
  • Assign a scoped role to a service account
  • Prove it fails outside the scope
  • Recommend key vs ephemeral strategy

Lock Down a Machine Identity

25 min · intermediate

0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/1
1

Which is an identity a workload assumes without storing credentials?

Go deeper

Official documentation

AWS — Roles for EC2
docs
Azure — Managed identities
docs
GCP — Service accounts
docs