On this page
Identity and access management for infrastructure (IAM/RBAC)
The principles of authenticating entities (users and machines) and authorizing their specific permissions across cloud environments and clusters.
Reference Card
- Origin/Prior Art: UNIX file permissions, Active Directory.
- Related Practices: Principle of Least Privilege, Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC).
- Key Concepts: Authentication (AuthN) vs. Authorization (AuthZ), Roles, Bindings, Machine Identities.
- Primary Failure Modes: Over-permissioned service accounts, Long-lived static credentials, “Admin” sprawl.
Introduction
In modern infrastructure, the network perimeter is dead. You cannot assume that a request is safe simply because it originates from inside your private VPC. Security must be enforced at the identity level.
Identity and Access Management (IAM) is the discipline of proving who is making a request (Authentication) and defining exactly what they are allowed to do (Authorization). This applies not just to human engineers logging into a console, but critically to machine identities—the software agents, CI/CD pipelines, and microservices that interact with cloud APIs thousands of times a second.
Mental Model
Think of a secure office building.
Authentication (AuthN) is the security guard at the front door checking your ID badge to confirm you are actually John Doe.
Authorization (AuthZ) is the electronic lock on the server room door on the 4th floor. Your badge proves you are John Doe, but the lock checks if John Doe has the “Server Admin” role. If you only have the “Marketing” role, the door stays locked.
RBAC (Role-Based Access Control) means the lock isn’t programmed with a list of 5,000 employee names; it is programmed to admit the Role: Admin. You are granted the role, and the role is granted the access.
Operational Pattern
Effective IAM relies on three structural components:
- The Identity (Principal): The human or machine making the request. In cloud environments, machines (EC2 instances, Kubernetes Pods) must be assigned identities (e.g., an AWS IAM Role or a Kubernetes ServiceAccount).
- The Role (Permissions): A discrete list of allowed actions. A role is never tied to a specific user. It is a reusable template of permissions (e.g.,
S3-Read-Only,DB-Migrator). - The Binding: The policy that attaches an Identity to a Role.
When a Kubernetes Pod needs to read a file from an S3 bucket, it does not use a hardcoded password. It assumes its assigned ServiceAccount identity, exchanges it for temporary, short-lived AWS credentials via an OIDC provider, and presents those credentials to S3. AWS checks the binding, verifies the role permits s3:GetObject, and allows the request.
Failure Modes
Over-Permissioned Service Accounts
The most devastating IAM failure is granting wildcard permissions out of convenience. When a developer cannot figure out why a script is failing, they often change the policy to Allow: * (Full Admin Access) to “make it work,” intending to lock it down later. They forget. Months later, a vulnerability in that script allows an attacker to hijack the identity, giving them the power to delete the entire production database.
Long-Lived Static Keys
Generating static Access Keys and hardcoding them into configuration files or CI/CD secrets is a critical liability. Static keys do not expire, they can be accidentally committed to GitHub, and they are frequently stolen. Modern IAM requires ephemeral, short-lived credentials generated dynamically on demand, which expire automatically after 15 minutes.
Security
The absolute core of IAM is the Principle of Least Privilege. Every human and every machine must be granted the absolute minimum permissions required to perform their specific job, and nothing more. If a microservice only needs to write to an S3 bucket, it must be explicitly denied the ability to read from that bucket, delete from that bucket, or interact with any other AWS service.
Operational Guidance
Regularly audit and prune unused roles and permissions. Cloud providers offer tools (like AWS IAM Access Analyzer) that track when a permission was last used. If a role has permissions that haven’t been invoked in 90 days, mathematically, the system does not need them. Delete them. Never use the Root user of a cloud account for daily operations. Lock the Root credentials in a physical vault and use federated Single Sign-On (SSO) for human access.