Skip to content
Back to CloudAll lessons

Cloud

Access Control (IAM Roles & Permissions)

Checking access is O(r × p) in the worst case, for a user with r roles averaging p permissions each. In practice this is very fast, since real permission sets are small. The value isn't speed. It's safety: one clear, central rule for who can do what.

The idea, in plain English

Think of a big office building where every employee carries a keycard. Not every keycard opens every door. A keycard is programmed to open only the doors that employee actually needs, like their own floor and the break room, but not the server room or the vault. IAM (Identity and Access Management) works the same way in the cloud. Instead of doors, you have actions like 'read a file' or 'delete a database.' Instead of one keycard per door, you define 'roles': reusable bundles of permissions, like a job title. You then give one or more roles to each user, the same way you'd hand someone a keycard programmed for their job.

How it works

  1. 1Define each role once, as a list of permissions it grants. For example, a 'viewer' role might grant only 'read.'
  2. 2Assign one or more roles to each user. A person can carry more than one keycard, and they get the combined permissions of every role they hold.
  3. 3When a user tries to do something, collect every permission from every role they have, and check whether the attempted action is in that combined set.
  4. 4If it's in the set, allow the action. If it isn't — or the user has no roles at all — deny it.

When you'd use it

Use this for any system with more than one type of user — regular users, support staff, admins — where you need to make sure people can only do what their job requires. This is the backbone of 'least privilege': give each person exactly the access they need, and nothing more. This way, a mistake or a stolen account can't do more damage than necessary.

Common beginner mistakes

  • Giving everyone the admin role 'just to be safe.' That defeats the whole point of roles, since one compromised account could then do anything.
  • Forgetting that a user with no roles assigned should be denied everything by default. Don't accidentally allow access just because there's nothing there to deny.
  • Piling up one-off permissions per user instead of using reusable roles. It works at first, but becomes hard to check as the team grows — 'wait, why does this one user have delete access?'

Try it — edit and run

Click the code to edit · press ⌘/Ctrl+↵ to run

Editable code. Tab and Shift+Tab indent. Press Escape, then Tab, to move focus out of the editor.

Expected output — hit Run to try it
Role 'viewer' grants: read
Role 'editor' grants: read, write
Role 'admin' grants: read, write, delete
User 'alice' has role(s): viewer
User 'bob' has role(s): editor
User 'carol' has role(s): admin, viewer
User 'dave' has role(s): none
Access check: alice -> read: allowed
Access check: alice -> delete: denied
Access check: bob -> write: allowed
Access check: carol -> delete: allowed
Access check: dave -> read: denied (no roles assigned)

Not sure this is the right topic? See the learning paths → or where this leads →