PATTERN Cited by 1 source

Coarse-grained access container

Problem

Per-asset access control lists (ACLs) at scale create an unsustainable maintenance burden. Organizational changes (reorgs, team merges, departures) require touching hundreds or thousands of individual permission entries. Teams respond by either flooding support with bulk-update requests or opening access far too broadly.

Solution

Introduce a logical container (project, namespace, domain) that groups related assets and manages permissions at the container level rather than per-asset:

1. Define roles at the container level (e.g., Contributor, Viewer).
2. Grant access to identity types (users, groups, apps, CI jobs) on the container.
3. All assets within the container inherit the container's grants.
4. On organizational change, update one grant instead of N asset ACLs.

Consequences

• Positive: Dramatically reduces permission-management overhead; reorgs become O(1) rather than O(N); reduces temptation for overly broad grants.
• Negative: Requires well-defined asset-to-container mapping; may over-grant within a container if asset sensitivity varies; container boundaries become load-bearing architectural decisions.

Canonical implementation

Netflix Data Projects — permissions managed on one project covering hundreds to tens of thousands of assets (Source: sources/2026-06-19-netflix-data-projects-managing-data-assets-at-netflix-scale).

Seen in

• sources/2026-06-19-netflix-data-projects-managing-data-assets-at-netflix-scale