BiTree
  • Search For Lessons
  • Curriculum
  • Pricing
  • For Educators
  • Become a Tutor
  • About
  • Contact
Log InGet Started

Questions, concerns, bug reports, or suggestions? We read every message, write to us at [email protected].

More ways to reach us →
BiTree

Live coding lessons for aspiring developers and security professionals.

[email protected]

(201) 785-7951

Mon–Fri, 9 AM–5 PM EST

Learn

  • Search For Lessons
  • Curriculum
  • Pricing

Company

  • About
  • For Educators & Schools
  • Become a Tutor
  • Contact Us

Legal

  • Terms of Service
  • Privacy Policy
© 2026 BiTree. All rights reserved.
Curriculum/Cybersecurity/Cloud Security/IAM Misconfigurations and Least Privilege
45 minIntermediate

IAM Misconfigurations and Least Privilege

After this lesson, you will be able to: Find and fix IAM misconfigurations: overly permissive roles, wildcard permissions, and public buckets, applying least privilege in cloud IAM.

IAM (Identity and Access Management) is the control plane of the cloud, and misconfigured IAM is the most common serious cloud weakness. This lesson covers overly permissive roles, wildcard permissions, public storage buckets, and how to apply least privilege.

Prerequisites:Cloud Security and the Shared Responsibility Model (intro)

How cloud IAM works

Cloud IAM grants permissions to identities (users, roles, services) via policies. In AWS, a policy is JSON listing allowed actions on resources. Roles let services and workloads assume temporary credentials rather than holding long-lived keys. The principle of least privilege says: grant only the specific actions on the specific resources an identity actually needs, and nothing more. Most breaches escalate because some identity had far more than it needed.

Wildcard permissions: the classic mistake

The first policy is a foot-gun; the second is scoped.

json
// DANGEROUS: allows every action on every resource
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
// BETTER: least privilege, scoped to one bucket and read-only
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "arn:aws:s3:::my-app-uploads/*"
}

Public buckets and exposed storage

Object storage like S3 is private by default, but a misconfigured bucket policy or ACL can make it world-readable, exposing whatever is inside (a recurring source of major breaches with millions of records). The fixes: block public access at the account level, scope bucket policies tightly, and audit regularly. Never rely on a hard-to-guess bucket name as security; scanners enumerate buckets constantly.

Applying least privilege

Start from zero and add only what is needed. Use roles with temporary credentials instead of long-lived access keys. Avoid wildcards in Action and Resource. Separate duties (the deploy role is not the admin role). Use permission boundaries and service control policies to cap what any identity can do. Review with access analyzers that flag unused or over-broad permissions. Least privilege limits the blast radius when (not if) something is compromised.

Quick Check

Why is an IAM policy with Action: '*' and Resource: '*' so dangerous?

Pick one.

Common mistakes only experienced engineers catch

Wildcards in policies 'to make it work.' Long-lived access keys instead of roles. Leaving account-level public-access blocks off. Granting AdministratorAccess broadly. Not reviewing unused permissions. Trusting bucket-name obscurity. Forgetting that a service's role is an identity an attacker can pivot through (the SSRF-to-metadata attack in the next lesson).

Sign in and purchase access to unlock this lesson.

Sign in to purchase
←Cloud Security and the Shared Responsibility Model
Back to Cloud Security
Cloud Attack Techniques→