Cloud IAM: least privilege, roles and keeping access keys safe

IAM (identity and access management) decides who can do what on which resources in your cloud account. It is the front door of everything, so weak IAM undoes all other security.

The core ideas

• Identity: a person (user) or a program (service account or role).
• Authentication: proving who you are (password plus MFA, or a token).
• Authorization: what you are then allowed to do, defined by policies.
• Policy: a document that allows or denies actions on resources, optionally with conditions.
• Role: a set of permissions that an identity can assume temporarily, without a permanent password or key.

Names differ between providers (AWS IAM, Google Cloud IAM, Azure RBAC) but the ideas are the same.

Least privilege

Give every identity the minimum permissions needed for its job, and nothing more.

Bad: a policy that allows all actions on all resources (* on *) "to make it work".

Better: allow only the needed actions on the specific resources:

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::my-app-uploads/*"
}

(AWS style shown. Other clouds use different syntax with the same idea.)

Tips for getting there:

• Start narrow and add permissions when something is denied, rather than starting wide.
• Use groups or roles instead of attaching policies to individual people.
• Use the provider's access analyser tools to find unused permissions and remove them.
• Prefer conditions, such as limiting access to a network or requiring MFA, for sensitive actions.

Protect human accounts

• Lock down the root or owner account. Turn on MFA, do not create access keys for it, and keep it for rare emergencies.
• Require MFA for everyone, ideally with a hardware key or authenticator app.
• Use single sign-on with your identity provider where possible, so leaving staff lose access in one place.
• Use separate accounts or projects for production and development.

Avoid long-lived access keys

A permanent access key in a file is one of the most common ways cloud accounts get taken over. Keys leak through Git repositories, logs, chat messages, laptops and build systems.

• Prefer roles with temporary credentials: a server or function is given a role and receives short-lived credentials automatically, with nothing stored.
• For CI/CD, use workload identity or OIDC federation so the pipeline gets temporary access with no stored secret.
• If you must use a key: scope it narrowly, rotate it, never commit it, and delete keys that are unused.
• Run a secret scanner on your repositories and enable the provider's key-leak alerts.

If a key leaks, treat it as a breach: disable it immediately, review the audit logs for what it did, rotate related secrets, then investigate how it leaked.

Secrets management

Keep database passwords and API keys in a secrets manager, not in code or environment files in Git. Give applications permission to read only the secrets they need, and rotate them on a schedule.

Audit and monitor

• Turn on audit logging (such as CloudTrail or Cloud Audit Logs) in all regions and send logs to a protected place.
• Alert on risky events: root login, policy changes, new access keys, disabled logging, and unusual regions or times.
• Review who has access regularly and remove stale accounts.

Common mistakes

• Wildcard permissions everywhere.
• Shared accounts and passwords.
• No MFA, especially on admin accounts.
• Access keys in repositories or container images.
• Production and development in the same account.
• Never reviewing permissions after people change roles.

Takeaway: use roles and temporary credentials instead of long-lived keys, grant the least privilege that works, require MFA, store secrets in a manager, and keep audit logs with alerts so you notice misuse.

---

Networking & Cloud series, Part 2 (cloud fundamentals): 3 of 5. Previous: VPC design: subnets, routing and security groups.