SUMMARY

Brigid Johnson, GM of Access Analyzer and AWS Identity, discusses the least privilege journey in AWS IAM, covering permissions foundations, Access Analyzer tools, lifecycle stages, demos, and pro tips for secure access.

STATEMENTS

• AWS Identity management revolves around determining who—developers, applications, and workloads—can access what resources, connected through permissions as the core mechanism.
• Resources in AWS encompass an expanding array of types, including S3 buckets, Lambda functions, batch jobs, step functions, and secrets, requiring organized access controls.
• Using multiple AWS accounts to separate workloads across environments and regions is essential, with AWS Organizations providing governance as account numbers grow.
• AWS SSO serves as the recommended central identity solution, supporting custom users, groups, attributes, or integration with external identity providers for granting account access.
• Short-term credentials via roles and federation are preferred over long-lived IAM users, aligning with security best practices for both human and workload access.
• Tags and resource groups are key for organizing resources, enabling efficient management and demonstration of tag-based access controls.
• Establishing a data perimeter and guardrails is foundational before pursuing least privilege, with extensive resources like workshops and blogs available for implementation.
• Access controls in AWS involve specifying permissions through policies for principals, actions, resources, and conditions, while AWS enforces them by allowing or denying requests.
• The principle of least privilege requires granting the narrowest permissions necessary for required tasks, which vary by environment like development versus production.
• In development, permissions should allow experimentation and innovation, whereas production focuses on preventing dangerous actions, ensuring security, and controlling costs.
• IAM policy language follows the PARC model: principals, actions, resources, and conditions, with actions offering fine-grained control across thousands of AWS operations.
• The dollar sign account policy variable cannot be used in resource ARNs; instead, specify the full account, limiting variables to the ARN's final segment.
• Access is denied by default; granting occurs via IAM principal policies attached to roles (managed or inline) or resource policies directly on resources like S3 buckets.
• IAM roles uniquely support both principal and resource policies, the latter known as trust policies, ideal for cross-account access scenarios.
• Service control policies in AWS Organizations restrict access at organizational levels, while permission boundaries limit role permissions to prevent privilege escalation.
• VPC endpoint policies ensure traffic remains within VPCs, and S3 block public access prevents unintended public exposure on buckets.
• AWS enforcement evaluates context from requests—such as actions, resources, tags—and policies, resulting in explicit allow or deny outcomes without ambiguity.
• Policy evaluation order starts with denial: SCPs and permission boundaries must allow, followed by identity/resource policies, trust policies, and session policies for final access.
• AWS services acting on behalf of users utilize service-linked roles with fixed permissions, service roles for customization, or requester permissions via temporary credentials.
• The permissions lifecycle is iterative: set broad initial permissions, verify for over-permissiveness, refine based on activity, and adjust as workloads evolve.
• Setting permissions begins with broad AWS managed policies for exploration, progressing to right-sized custom policies generated from CloudTrail activity via Access Analyzer.
• Policy generation in Access Analyzer analyzes CloudTrail events, maps to IAM actions for over 50 services, includes dependencies, and provides editable resource templates.
• Custom policy authoring benefits from Access Analyzer's policy validation, checking over 100 security, error, warning, and suggestion criteria to ensure functionality and security.
• Verifying permissions focuses on identifying public/cross-account access via Access Analyzer findings, PassRole risks through validation, and scoping down unused powerful actions.
• Cross-account access requires verifying trust policies, resource policies, and access point policies to ensure intended access, as illustrated in scenarios like controlled resource sharing.
• Automated reasoning in Access Analyzer uses logic to comprehensively analyze permissions, generating findings for public or cross-account exposures across seven resource types.

IDEAS

• Multiple AWS accounts act as isolated environments, preventing a single breach from compromising everything, while Organizations centralize control amid rapid growth.
• IAM users are becoming obsolete, replaced by role-based short-term credentials that automatically expire, minimizing long-term exposure risks.
• Tags enable dynamic resource organization, turning static policies into flexible, context-aware controls that adapt to evolving workloads.
• Least privilege isn't a one-time setup but a continuous cycle, mirroring innovation's pace and ensuring permissions tighten without stifling development.
• Policy language's PARC model empowers granular control, yet subtle pitfalls like invalid ARN variables can silently break access intentions.
• Resource policies excel at cross-account scenarios, functioning like dual-key locks where both sides must explicitly agree to unlock access.
• Permission boundaries serve as developer safety nets, capping what roles can grant without revoking their creative autonomy.
• AWS context injection—pulling in tags, principals, and invocation details—turns static policies into intelligent, reactive enforcers.
• Service-linked roles embody trust in AWS, with immutable permissions that guarantee services operate only as predefined, reducing custom oversight burdens.
• CloudTrail activity directly fuels policy generation, transforming raw usage logs into tailored permissions, bridging observation and optimization.
• Condition keys like principalOrgID create organizational moats, confining access to trusted boundaries without constant manual adjustments.
• Multi-value condition keys demand careful operator choice, as empty sets can unexpectedly grant access under "for all values," exposing subtle security gaps.
• Deny policies with layered conditions craft impenetrable barriers, combining org restrictions, VPC limits, and service exceptions for robust perimeters.
• Policy validation integrates into CI/CD pipelines, catching errors pre-deployment and evolving with AWS's expanding check library.
• Findings in Access Analyzer use automated reasoning for exhaustive permission audits, uncovering exposures that manual reviews miss.
• PassRole permissions risk privilege escalation chains, where broad allowances let low-privilege entities summon admin powers indirectly.
• Cross-account verification reveals hidden paths, like unintended role assumptions leading to sensitive resource access.
• Automated reasoning applies formal logic to permissions, proving access paths mathematically rather than heuristically, enhancing reliability.

INSIGHTS

• Separating workloads into multiple accounts via Organizations not only scales governance but fosters a resilient architecture against cascading failures.
• Short-term credentials shift security from static keys to ephemeral access, inherently limiting damage windows and simplifying credential rotation.
• The PARC model's condition layer elevates policies from blunt tools to precise instruments, enforcing context-specific rules that evolve with usage.
• Least privilege in development promotes innovation by allowing broad exploration, while production's tight controls safeguard operational integrity.
• Dual policy evaluation for cross-account access ensures mutual consent, preventing unilateral overreach in multi-tenant environments.
• Permission boundaries democratize role creation for developers, imposing invisible ceilings that curb escalation without micromanagement.
• Context-driven enforcement makes AWS policies adaptive, where runtime details like tags dynamically refine access decisions.
• Service roles balance customization with auditability, isolating service trusts to prevent tangled permission webs.
• Policy generation from CloudTrail democratizes fine-grained IAM, letting activity data guide permissions rather than guesswork.
• Condition operators and keys form a logical toolkit, where misapplication—like wildcard avoidance—prevents unintended broad grants.
• Multi-value handling in conditions underscores the need for precise semantics, as set theory pitfalls can invert security intentions.
• Deny-with-conditions policies architect comprehensive defenses, layering exclusions to create fail-safe perimeters around data.
• Automated reasoning in Access Analyzer delivers verifiable security proofs, transforming permission analysis from art to science.
• Verifying PassRole curbs escalation vectors, ensuring that permission passing doesn't chain into full administrative takeover.
• Iterative lifecycle refinement aligns permissions with real-world changes, turning least privilege into a sustainable practice.
• Cross-account findings highlight trust policy intricacies, revealing how assumptions propagate risks across organizational boundaries.
• Integrating validation into workflows preempts policy flaws, embedding security into the development velocity.

QUOTES

• "Please use short term credentials, right? There is a Twitter thread that I absolutely love that said, hey, I don't think we need IAM users anymore."
• "The goal is to adhere to the principle of least privilege... granting users and systems the narrowest set of privileges to complete the required task."
• "In development environment, it might be part of your developers' required tasks to actually experiment and explore."
• "You actually have to specify account. The only place you can use a variable in the ARN is the last part."
• "AWS relies on the same permission model that you do for your workloads."
• "Least privilege, it is a journey. So many customers say, I just want least privilege right now. But guess what? As you innovate, as you build, things change."
• "Become besties with those conditions."
• "If you don't have wild card in the value, don't use string like, just use string equal."
• "An empty set is a subset of all other sets."
• "We have over 100 checks to help you author secure and functional policies."

HABITS

• Maintain multiple AWS accounts to isolate development, production, and other environments for better security and management.
• Rely on AWS SSO for centralized identity management, integrating custom or external providers to streamline access grants.
• Prefer short-term credentials through roles and federation for all human and application access to minimize persistent risks.
• Organize resources using tags and groups to enable attribute-based access control and efficient auditing.
• Start with broad AWS managed policies during exploration, then iteratively right-size them based on actual usage.
• Validate custom policies using Access Analyzer's checks before deployment to catch security and functional issues early.
• Monitor for public and cross-account exposures continuously via Access Analyzer findings to verify intended access.
• Experiment in development environments with permissive settings to foster innovation, tightening for production.
• Review and refine permissions regularly as workloads evolve, treating least privilege as an ongoing process.

FACTS

• AWS offers over 200 services across global data centers, supporting millions of customers from startups to governments.
• IAM policy language includes thousands of fine-grained actions, enabling precise control over resource interactions.
• Only IAM roles combine both principal policies and resource policies, including trust policies for assumption.
• Access Analyzer maps CloudTrail events to IAM actions for over 50 services, including dependent actions automatically.
• Automated reasoning in Access Analyzer monitors seven resource types continuously for public or cross-account access.
• S3 block public access prevents both existing and new public configurations on buckets when enabled.
• Condition keys like aws:PrincipalOrgID restrict access to principals within the same organization.
• Multi-value condition keys typically end in "s" and are documented for specific services.
• Policy validation in Access Analyzer includes over 100 checks, prioritizing security warnings and errors.
• AWS services use predefined service-linked roles with immutable permissions for tasks like analyzing buckets.

REFERENCES

• AWS Organizations for governing multiple accounts and integrations.
• AWS SSO for central identity management and account access.
• CloudTrail for logging activity to generate policies.
• Lambda functions for workload examples and demos.
• S3 buckets, access points, and block public access for resource policies.
• EC2 instances for action and tagging demonstrations.
• Secrets Manager for secure resource access.
• Resource groups for organizing tagged resources.
• VPC endpoint policies for traffic control.
• KMS keys for cross-account resource policies.
• CloudFormation for context injection and requester permissions.
• IAM Access Analyzer for policy generation, validation, and findings.
• Service control policies (SCPs) for organizational restrictions.
• Permission boundaries for role limits.
• Twitter thread on deprecating IAM users.

HOW TO APPLY

• Establish a data perimeter using AWS Organizations and service control policies to set outer bounds for access across accounts.
• Start with broad AWS managed policies for new workloads or exploration, attaching them to roles for initial testing.
• Run workloads to generate CloudTrail activity, then request a policy from Access Analyzer specifying role, time period, trail, and regions.
• Review the generated policy, filling in resource templates like ARNs, tags, or resource groups, and add any necessary conditions or actions.
• Validate custom policies in the IAM console or API, prioritizing security checks and errors, then integrate into pipelines for ongoing use.
• Enable Access Analyzer findings to monitor resources for public or cross-account access, archiving intended ones and remediating others.
• Use condition keys like aws:PrincipalOrgID in resource policies to restrict to organizational boundaries, combining with denies for layered security.
• Apply permission boundaries to developer-created roles to enforce maximum permissions without allowing escalation to admin levels.

ONE-SENTENCE TAKEAWAY

Embrace the iterative least privilege journey in AWS IAM using Access Analyzer to set, verify, and refine secure permissions dynamically.

RECOMMENDATIONS

• Adopt AWS SSO as your central identity source to unify user management and enable seamless account access.
• Transition to short-term credentials via roles, phasing out IAM users to enhance security and reduce credential sprawl.
• Enable block public access on all S3 buckets by default to prevent accidental exposures.
• Generate right-sized policies from CloudTrail using Access Analyzer for workloads, customizing resources and conditions as needed.
• Incorporate policy validation into CI/CD pipelines to catch permissive or erroneous policies before deployment.
• Use principalOrgID conditions in resource policies to confine cross-account access within your organization.
• Set permission boundaries on roles to safely empower developers while preventing privilege escalation.
• Continuously monitor Access Analyzer findings to identify and remediate unintended public or cross-account accesses.
• Favor string equals over string like operators in conditions without wildcards for exact matching.
• Avoid for all values with single-value keys to prevent empty contexts from granting unintended access.
• Verify PassRole permissions narrowly to block escalation paths to administrative roles.

MEMO

In the bustling world of cloud computing, where innovation races ahead of security risks, Brigid Johnson, General Manager of Access Analyzer and AWS Identity, delivered a compelling session at AWS re:Invent 2021. Titled "A Least Privilege Journey: AWS IAM Policies and Access Analyzer," her talk demystified the art of granting just enough access to keep systems humming without opening floodgates to threats. Johnson, with her infectious enthusiasm for permissions—"it's my favorite topic"—framed AWS Identity as a simple question: who can access what? Developers, applications, and workloads form the "who," while an ever-expanding universe of resources like S3 buckets and Lambda functions define the "what." Permissions, she emphasized, bridge this gap, but achieving least privilege demands a structured path.

Johnson began with foundational advice: scatter workloads across multiple AWS accounts, governed by AWS Organizations, to isolate environments like development sandboxes from production fortresses. She championed AWS SSO for centralized identity, urging a shift from outdated IAM users to short-term credentials via roles and federation. "Please use short-term creds whenever you can," she quipped, nodding to a viral Twitter thread declaring IAM users nearly obsolete. Tags and resource groups emerged as organizational heroes, enabling attribute-based controls that adapt to chaos. Yet, before diving into fine-grained policies, Johnson stressed a data perimeter—guardrails like service control policies—to contain risks, drawing from workshops and blogs for deeper dives.

The heart of her presentation pulsed with the permissions lifecycle: set, verify, refine, repeat. Least privilege, Johnson clarified, isn't a snapshot but a journey mirroring AWS's innovative tempo. In development, broad permissions fuel experimentation; in production, they clamp down on dangers. The IAM policy language, built on the PARC model—principals, actions, resources, conditions—offers surgical precision, though pitfalls abound, like misusing variables in ARNs. Access starts denied, granted via principal policies on roles or resource policies on assets like S3 buckets. Cross-account setups require dual approvals, akin to hotel doors needing two keys. Enforcement blends request context—tags, invocations—with policy evaluation, yielding stark allow-or-deny verdicts.

Demos brought theory to life, starring Johnson's whimsical "Pickles the horse," a unicorn auditing his pasture via Lambda. Starting with broad role permissions, she invoked Access Analyzer to scan CloudTrail logs, generating a tailored policy for over 50 services. Filling templates for resources and tags, she detached the old policy, reran the function, and confirmed seamless operation—no denials. Custom policy crafters got validation tools: over 100 checks flagging overly permissive grants or syntax errors. Conditions, Johnson's "besties," layered logic with operators, keys like principalOrgID, and values, warning against multi-value traps where empty sets slyly grant access.

Verification targeted over-permissiveness: public exposures via Access Analyzer's automated reasoning, which mathematically proves access paths across seven resource types. PassRole risks, enabling privilege jumps, demand narrow scoping; powerful actions like IAM management invite pruning if unused. Cross-account vignettes illustrated trusts and bucket policies, recommending org-bound conditions to seal perimeters. Deny policies with VPC, IP, and service exceptions wove intricate defenses, as in a sample barring outsiders from S3 while permitting AWS services.

Johnson wrapped with pro tips: block S3 public access universally, validate policies pipeline-integrated, and treat conditions as conditional guardians. Her session underscored AWS's evolution—services like Access Analyzer not just tools, but partners in secure scaling. As cloud adoption surges, her message resonates: least privilege isn't drudgery but empowerment, ensuring agility thrives within bounds. For those navigating AWS's vast ecosystem, it's a roadmap to resilience, one refined policy at a time.