IAM & Cloud Security Basics

IAM (Identity and Access Management) is how a cloud provider answers one question, for every single request: who is this, and are they allowed to do that?

Users, roles, and policies

• A user is a person or application with its own long-lived credentials.
• A role is a set of permissions that something can assume temporarily - no permanent credentials required.
• A policy is the actual document spelling out what's allowed: which actions, on which resources.

A policy might read, in plain English: "allow reading objects from the app-uploads bucket, and nothing else." Attach that policy to a role, and anything that assumes the role can read that bucket - and only that bucket.

Least privilege

The principle of least privilege: grant exactly the access something needs to do its job, and not one permission more. A deploy script that only ever reads from one storage bucket should never hold permissions to delete databases - not because it's expected to misuse them, but because a leaked credential or a bug can only do as much damage as the permissions it has.

Roles over long-lived keys

A long-lived access key, sitting in a config file or an environment variable, is a standing risk - if it leaks, it works until someone notices and revokes it. An instance role or service account instead grants temporary, auto-rotating credentials to a specific VM or service - nothing permanent to leak in the first place, because nothing permanent exists.

MFA

Multi-factor authentication adds a second proof of identity beyond a password - a code from a phone, a hardware key. For any account with meaningful permissions, it should be considered mandatory, not optional: a leaked password alone should never be enough to get in.

Try it

Credential files need the same discipline on disk that IAM aims for in the cloud - readable by nobody except their owner:

chmod 600 cloud-credentials.json

When you're ready, hit Mark complete and move to the next lesson.