DevOps Cloud IAM

IAM stands for Identity and Access Management. IAM answers two questions for every action in the cloud: who is asking, and what may that person or program do? Every major provider includes an IAM service, and every cloud security plan starts with it.

The Office Badge Example

Picture an office building with badge readers. A badge proves who you are. Your role decides which doors open. The finance badge opens the finance floor, and the visitor badge opens the lobby. The reader records each entry. Cloud IAM follows the same pattern for servers, databases, and storage.

Core Terms

Identity

An identity is a user, a group, or a machine account that can act in the cloud. A person has a user identity. An application has a service identity, often called a service account or a role.

Authentication

Authentication proves identity. Passwords, security keys, and one-time codes serve this purpose.

Authorization

Authorization decides what an identity may do after login. Policies hold these permissions.

Policy

A policy is a written rule that allows or denies actions on resources.

How a Request Is Checked

 Request: "Read file report.csv"
        |
        v
 [ Authentication ]  Who are you?       --> Fail: reject
        |
        v
 [ Authorization ]   Does a policy allow
                     read on report.csv? --> No: deny
        |
        v
      Allow
        |
        v
 [ Audit log ]       Record who, what, when

A Sample Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::reports-bucket/*"
    }
  ]
}

The policy lets an identity read files from one storage bucket and nothing else. The statement names an effect, the allowed actions, and the target resources. An explicit deny always beats an allow.

Groups and Roles

Attach permissions to groups instead of single people. A developers group holds the rights that developers need, and a new hire joins the group on day one. A role is a set of permissions that an identity can borrow for a short time. Servers, containers, and pipelines use roles instead of stored passwords.

 [ Web server VM ] --assumes--> [ Role: ReadReports ] --> Storage bucket
 (no password stored on the VM)

Principle of Least Privilege

Give every identity the smallest set of permissions that still lets the work happen. A reporting script that reads one bucket needs no rights to delete servers. Start with no access and add rights as needs appear. Wide permissions such as "allow everything" turn one stolen key into a full account takeover.

Multi-Factor Authentication

Multi-factor authentication (MFA) asks for two proofs, such as a password and a code from a phone app. A stolen password alone no longer opens the account. Require MFA for all human users and for every administrator.

Temporary Credentials

Long-lived access keys leak into code and chat messages. Temporary credentials expire after minutes or hours. Cloud services such as AWS STS create them on request. Single sign-on (SSO) lets staff log in once through the company identity provider and receive temporary access to each cloud account.

Protecting the Root Account

The root account owns the entire cloud account and bypasses every limit. Use it only for a few rare tasks. Lock it with MFA, remove its access keys, and store its login in a sealed place.

Permission Boundaries and Organization Controls

Large companies run many cloud accounts. Organization-level rules, such as service control policies, set limits that no account can exceed. A rule can forbid creating resources outside approved regions. Permission boundaries cap what a role may grant to others.

Auditing and Review

• Turn on audit logs, such as AWS CloudTrail or Azure Activity Log, in every account.
• Review who holds powerful roles every quarter.
• Remove accounts of people who left the team.
• Use access analyzers to find unused permissions and public resources.

Key Points

• Authentication proves who you are, and authorization decides what you may do.
• Groups and roles keep permissions organized.
• Least privilege and MFA shrink the damage from stolen credentials.
• Audit logs show every action for later review.