Information Security

IAM and Access Management

Capital One 2019. One HTTP request to http://169.254.169.254/latest/meta-data/iam/security-credentials/. The WAF EC2 instance's credentials. The IAM role had GetObject on all S3 buckets. The fix was a 5-minute policy change that the team had discussed but never prioritized. 106 million records. $80 million fine. IAM misconfiguration is not a technical failure - it is a process failure. Least privilege must be enforced systematically, not aspirationally.

  • **Capital One 2019**: overly permissive IAM role + SSRF = 106 million records. The IAM policy was corrected in 5 minutes - it just was not done earlier.
  • **Tesla 2018**: K8s dashboard with no password -> pod with AWS credentials in env vars -> crypto mining on EC2 at Tesla's expense.
  • **Uber 2022**: AWS credentials committed to GitHub -> S3 and RDS access -> 57 million records. Rule: IRSA only, no static keys.

IAM Policies: Precise Permission Boundaries

2019. Capital One. The IAM role for the WAF service had s3:GetObject on all S3 buckets instead of one specific bucket. Through an SSRF attack, the attacker obtained the EC2 instance credentials and used the overly permissive IAM role to download 106 million customer records. The fix: 5 minutes to scope the policy to one bucket. The cost of not doing it earlier: $80 million fine.

Wildcard * in Action or Resource is a red flag. s3:* combined with * Resource equals full S3 access to the entire account. AWS Access Analyzer automatically finds overly permissive policies and generates least-privilege recommendations based on CloudTrail access history. Run it quarterly on all IAM roles.

A Lambda function processes orders and writes to a DynamoDB table named 'orders'. What is the minimal IAM policy needed?

0

1

Sign In

Least Privilege in Practice

The Principle of Least Privilege (PoLP): every identity has only the permissions needed for its function. Excess permissions are not used in normal operation but become the blast radius multiplier in a compromise. The challenge is maintaining least privilege over time as systems evolve.

AWS SCP (Service Control Policies) are guardrails at the Organization level. They apply to all accounts and cannot be overridden even by account root users: blocking CloudTrail disabling, enforcing MFA for sensitive actions, restricting resources to specific regions. SCPs define the maximum permission boundary; IAM policies define actual permissions within that boundary.

A developer wants to give a CI/CD pipeline permissions to deploy a Lambda function. Which approach is correct?

Service Identities: Machines Need Identities Too

Services need identities just like humans do. A Service Account (or IAM Role) is an identity for a machine: a Lambda, EC2 instance, Kubernetes Pod, or CI/CD pipeline. Not a human - different lifecycle, different threat model, different credential management.

Shared service accounts are an anti-pattern. If 10 services share one account: the audit trail is indistinguishable, you cannot revoke access for one service without affecting all others, and the blast radius of a compromise covers all 10 services. One service = one dedicated service identity, always.

A Kubernetes Pod needs access to AWS S3. How should credentials be provided?

Identity Federation: One Identity, Many Systems

An organization with 1,000 Active Directory users, AWS, GCP, Salesforce, and GitHub. Without federation: 5,000 accounts to manage. Identity Federation maps the corporate identity (AD) to cloud and SaaS systems: users log in once with their corporate credentials; the IdP issues short-lived tokens for each target system.

JIT Provisioning: the user does not exist in the target system until their first login. At login, the IdP creates the account with the correct permissions derived from group membership. Deprovisioning: disabling the AD/Okta account immediately blocks new logins to all federated systems. Existing sessions expire by TTL (typically 1-8 hours).

An employee is terminated. Their AD account is disabled. Okta is federated with AD. What happens to their AWS access?

Summary

  • **IAM policies**: specific actions on specific resources. No wildcards in Action or Resource for production roles. Use Access Analyzer to find unused permissions.
  • **Least privilege**: start minimal, audit with Access Advisor, use SCPs as organization-level guardrails. Time-bound reviews as systems evolve.
  • **Service accounts**: one dedicated identity per service. IRSA (AWS), Workload Identity (GCP), Managed Identity (Azure) for K8s pods. No shared accounts.
  • **Federation**: corporate IdP -> SAML/OIDC -> temporary cloud credentials. Disabling IdP account immediately revokes all federated access. No local IAM users for human identities.

Related Topics

IAM connects to authentication fundamentals and cloud security:

  • Authentication and Authorization — IAM implements RBAC and ABAC at cloud scale for both human and machine identities.
  • AWS/GCP/Azure Security — IAM policies control access to every cloud resource - the foundation of all cloud security.
  • Container and Kubernetes Security — K8s RBAC combined with IRSA creates a federated identity system between Kubernetes and cloud IAM.

Вопросы для размышления

  • An organization has 500 IAM roles accumulated over 5 years. Many are unused or overly permissive. Design a 3-month remediation project to achieve least privilege across all roles.
  • A CI/CD pipeline needs to deploy to 20 different AWS accounts across 5 environments. Design the IAM architecture to enable this without sharing credentials across accounts.
  • An employee changes teams and their AWS permissions need to change. With federation, how should this be implemented to take effect immediately?

Связанные уроки

  • sec-03
  • sec-27
  • sec-18
  • net-68-auth-network
IAM and Access Management