Authorization, Scope, and Least Privilege

Goal

Turn identity into explicit permission decisions over actions, resources, conditions, and boundaries.

The Short Version

Least privilege is a narrow, observable permission set placed at the smallest practical scope and refined with evidence.

Authorization connects principals to allowed actions on defined resources, often with conditions and explicit boundaries. The important architecture move is to make the boundary explicit before selecting a cloud feature. A feature can automate a decision, but it cannot decide the organization's risk tolerance, ownership model, or acceptable failure behavior.

Use this section as a decision tool. Name the actor or producer, the protected or affected resource, the contract between them, the conditions under which the action is allowed, and the evidence that will show whether the design worked.

Mental Model

Show principal, role or policy, action, resource scope, conditions, guardrail, and resulting allow or deny decision.

flowchart LR
    N1["Actor"] --> N2["Credential or assertion"] --> N3["Identity provider"] --> N4["Policy decision"] --> N5["Resource"] --> N6["Evidence"]

Read the diagram from left to right, then review it from right to left. The forward pass explains how work succeeds. The reverse pass asks whether an operator can trace an outcome back to its initiating identity, input, policy, route, or contract.

Architecture Decisions

The answers should be recorded with the workload design. If the answer is merely "the platform default," the team has discovered an assumption, not completed an architecture decision.

Core Ideas

Authorization connects principals to allowed actions on defined resources, often with conditions and explicit boundaries

Authorization connects principals to allowed actions on defined resources, often with conditions and explicit boundaries. Make the owner, boundary, failure behavior, and evidence explicit. That turns the concept from a configuration choice into a design decision that another team can review and operate.

Scope, inheritance, separation of duties, and deny or guardrail behavior shape the effective permission set

Scope, inheritance, separation of duties, and deny or guardrail behavior shape the effective permission set. Make the owner, boundary, failure behavior, and evidence explicit. That turns the concept from a configuration choice into a design decision that another team can review and operate.

Least privilege should begin with job intent, use bounded roles, and improve through access evidence and review

Least privilege should begin with job intent, use bounded roles, and improve through access evidence and review. Make the owner, boundary, failure behavior, and evidence explicit. That turns the concept from a configuration choice into a design decision that another team can review and operate.

Provider Lenses

AWS commonly expresses these responsibilities through IAM identities, roles, policies, IAM Identity Center, and permission boundaries. Azure commonly uses Microsoft Entra ID for identity, Azure RBAC for resource authorization, managed identities for workloads, and PIM for time-bound privileged access. The useful comparison is the responsibility each feature carries, not a claim that the names are exact equivalents.

Provider lenses are useful for implementation planning, but they should come after the provider-neutral decision. This keeps the reasoning portable and makes differences in defaults, scope, and operational responsibility easier to detect.

Example: Applying the Decision

Define separate permissions for application deployment, secret administration, runtime access, and security review across two environments.

Use separate identities for people, pipelines, and running workloads; separate production from non-production authorization; require stronger approval for production elevation; and record both control-plane changes and data access where the risk requires it.

A review should finish with named owners, a testable success path, expected failure modes, and observable evidence. That is more useful than a diagram that only proves the components can connect.

Common Mistakes

• Granting broad roles at a high scope because they are convenient. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.

• Copying permissions between human and workload identities. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.

• Treating a successful deployment as proof that permissions are appropriately narrow. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.

If Someone Asks You

How do you design least privilege without guessing every permission?

A clear answer is:

Least privilege is a narrow, observable permission set placed at the smallest practical scope and refined with evidence.

I would then show the decision path, the responsibility boundary, and the evidence used to review it. That explanation connects the technical mechanism to its architecture purpose.

What You Should Remember

Least privilege is a narrow, observable permission set placed at the smallest practical scope and refined with evidence.

Questions to Check Your Understanding

1. Which elements make up an authorization decision?

2. How can inheritance expand blast radius?

3. Why is least privilege an iterative practice?