Permission Boundaries

info

Feature status: planned

When you grant Entigo Platform access to your cloud account, you want to ensure it can only manage the resources within its designated scope — not other resources in the same account. Permission Boundaries enforce this limit.

The Problem

Cloud providers typically use role-based access control (RBAC). A "Database Administrator" role grants access to all databases in the account. When you delegate database management to Entigo Platform, it could access databases that are not managed through the platform. This violates the principle of least privilege.

How Entigo Platform Solves This

The platform uses resource tags combined with AWS IAM Permission Boundaries to limit its own access:

1. Every cloud resource managed by the platform is tagged with entigo:workspace (and optionally entigo:zone)
2. A Permission Boundary policy is attached to every platform IAM role, restricting it to resources with matching tags
3. The effective permissions are the intersection of the boundary and the role's identity policy — the role can never exceed the boundary

Workspace Isolation

A workspace is isolated from all other resources in the AWS account — including resources not managed by the platform. The platform role for a workspace can only access resources tagged with its entigo:workspace value. Untagged resources and resources belonging to other workspaces are inaccessible, even if the role's identity policy grants broad permissions like ec2:*.

Recommended pattern: one workspace per AWS account. This provides the strongest isolation — the permission boundary acts as a defense-in-depth measure on top of account-level separation, and there are no other resources in the account that could be accidentally accessed.

Multi-region workspaces are planned for disaster recovery and high availability scenarios. A single workspace would span multiple regions — for example, provisioning resources in both eu-west-1 and eu-central-1 to support configurations like pilot-light or active-active DR.

Multiple workspaces in one account are under consideration. Tag-based ABAC provides the foundation for isolating workspaces within a shared account, but this deployment model is not yet supported. Multiple workspaces in the same account and the same region are not supported.

AWS Account (recommended: single workspace)
└── eu-west-1
    └── Workspace A resources  (tagged: entigo:workspace=ws-a)
        ├── Zone 1             (tagged: entigo:zone=zone-1)
        └── Zone 2             (tagged: entigo:zone=zone-2)

AWS Account (planned: single workspace spanning regions for DR)
├── eu-west-1 (primary)
│   └── Workspace A resources  (tagged: entigo:workspace=ws-a)
└── eu-central-1 (DR)
    └── Workspace A resources  (tagged: entigo:workspace=ws-a)

AWS Account (under consideration: multiple workspaces, different regions)
├── eu-west-1
│   └── Workspace A resources  (tagged: entigo:workspace=ws-a)
└── us-east-1
    └── Workspace B resources  (tagged: entigo:workspace=ws-b)

Zone Scoping

Within a workspace, zones provide finer-grained isolation:

• Workspace-wide roles can access all resources in the workspace
• Zone-scoped roles can only access resources in their assigned zone

This is implemented through identity-based policies that add zone conditions on top of the workspace boundary.

What You See in Your AWS Account

When you look at your AWS resources, you'll see platform tags:

Resource: my-production-database (RDS)
Tags:
  entigo:workspace = ws-prod-001
  entigo:zone = zone-1
  Name = my-production-database
  crossplane-kind = instance.rds.aws.upbound.io
  crossplane-name = my-production-database-abc12
  crossplane-providerconfig = default

And the permission boundary policy attached to the platform role:

Policy: workspace-boundary-ws-prod-001
  Allow: ec2:*, rds:*, s3:*, etc WHERE entigo:workspace = ws-prod-001
  Deny: create resources without entigo:workspace tag

Human User Access

If your organization uses Azure Entra ID (or another SAML/OIDC provider) with AWS IAM Identity Center, human users can get zone-scoped access to AWS resources for imperative operations (e.g., restarting an RDS instance, managing secrets). The integration options and their trade-offs are documented in the AWS SSO Integration ADR.

Azure and GCP

Azure and GCP have different access control models:

• Azure: Tag-based ABAC is currently limited to storage data-plane actions. Workspace isolation uses resource-group-per-workspace or subscription-per-workspace with Azure RBAC scoping.
• GCP: GCP Tags (organization-level) can be used with IAM Conditions for access control. Implementation is planned for future iterations.

What You Control

Action	Your Responsibility
Granting platform access	You create the IAM role and attach the permission boundary
Boundary policy	Provided by the platform, deployed to your account
Tag integrity	Platform manages tags; you should not manually modify entigo:* tags
AWS account structure	You decide whether to use one account per workspace (recommended) or share accounts

Related Concepts

• Resource Tagging — How tags enable permission boundaries
• Zone — How zones provide isolation within a workspace