Skip to main content

ADR: Permission Boundaries for Cloud Resource Isolation

  • Status: Draft
  • Date: 2026-01-19
  • Updated: 2026-03-09
  • Decision Makers: Entigo RnD Team

Context​

Entigo Platform manages cloud resources within customer cloud accounts. Users grant the platform access to their cloud resources via IAM roles. Most cloud providers use role-based access control (RBAC) by default, which means a role like "Database Administrator" grants access to all databases in the account — including those not managed through Entigo Platform. This violates the principle of least privilege and may not be acceptable to security-conscious organizations.

The platform needs a mechanism to limit its own access to only the resources it manages, scoped by workspace and zone.

Design Requirements​

  1. Workspace isolation: A workspace in an AWS account can not access resorces in the same account that are not part of the same workspace
  2. Zone scoping: Within a workspace, zone-scoped roles should only access resources in their assigned zone
  3. Delegated administration: The platform should be able to create new roles and policies while ensuring they remain within the workspace boundary

Tag Dependency​

Permission boundaries depend on the cloud resource tagging strategy defined in Cloud Resource Tagging ADR. The tag keys used in IAM policies are:

K8s LabelAWS Tag KeyUsed In
entigo.com/workspaceentigo:workspacePermission boundary, identity policies
entigo.com/zoneentigo:zoneIdentity policies (zone scoping)

Decision​

AWS Permission Boundaries with ABAC​

Use AWS IAM Permission Boundaries combined with Attribute-Based Access Control (ABAC) using resource tags to enforce workspace and zone isolation.

Architecture: Workspace & Zone Boundaries​

A single workspace permission boundary supports both zone-scoped and non-zone-scoped roles:

  • Workspace permission boundary: Attached to each role, defines maximum permissions. Gates access by entigo:workspace tag.
  • Zone scoping: Implemented via identity-based policies that further restrict access based on entigo:zone tag.
  • Effective permissions: The intersection of the permission boundary AND the identity-based policy (both must allow an action).

This approach:

  • Avoids AWS limitation of one boundary per principal
  • Keeps the hierarchy clean and maintainable
  • Allows roles to be either workspace-wide or zone-restricted without structural changes

Policy Examples​

Workspace Permission Boundary (maximum permissions for all roles in workspace):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowWorkspaceResources",
      "Effect": "Allow",
      "Action": [
        "ec2:*",
        "rds:*",
        "s3:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/entigo:workspace": "ws-prod-001"
        }
      }
    },
    {
      "Sid": "AllowIAMActions",
      "Effect": "Allow",
      "Action": [
        "iam:GetRole",
        "iam:ListRolePolicies"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyUntaggedResources",
      "Effect": "Deny",
      "Action": [
        "ec2:RunInstances",
        "rds:CreateDBInstance",
        "s3:CreateBucket"
      ],
      "Resource": "*",
      "Condition": {
        "Null": {
          "aws:RequestTag/entigo:workspace": "true"
        }
      }
    }
  ]
}

Identity-based Policy — Zone-Agnostic Role (workspace-wide access):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ManageWorkspaceResources",
      "Effect": "Allow",
      "Action": [
        "ec2:*",
        "rds:*",
        "s3:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/entigo:workspace": "ws-prod-001"
        }
      }
    }
  ]
}

Identity-based Policy — Zone-Scoped Role (limited to zone-1):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ManageZoneResources",
      "Effect": "Allow",
      "Action": [
        "ec2:*",
        "rds:*",
        "s3:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/entigo:workspace": "ws-prod-001",
          "aws:ResourceTag/entigo:zone": "zone-1"
        }
      }
    }
  ]
}

Delegated Role & Policy Creation​

The platform can create new IAM roles and policies within the workspace scope, enforcing that all created roles inherit the workspace permission boundary:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowRoleCreationWithBoundary",
      "Effect": "Allow",
      "Action": [
        "iam:CreateRole",
        "iam:PutRolePermissionsBoundary"
      ],
      "Resource": "arn:aws:iam::ACCOUNT:role/ws-prod-001/*",
      "Condition": {
        "StringEquals": {
          "iam:PermissionsBoundary": "arn:aws:iam::ACCOUNT:policy/workspace-boundary-ws-prod-001"
        }
      }
    },
    {
      "Sid": "AllowPolicyCreation",
      "Effect": "Allow",
      "Action": [
        "iam:CreatePolicy",
        "iam:CreatePolicyVersion",
        "iam:PutUserPolicy",
        "iam:PutRolePolicy"
      ],
      "Resource": [
        "arn:aws:iam::ACCOUNT:policy/ws-prod-001/*",
        "arn:aws:iam::ACCOUNT:role/ws-prod-001/*"
      ]
    },
    {
      "Sid": "TagNewRoles",
      "Effect": "Allow",
      "Action": [
        "iam:TagRole",
        "iam:UntagRole"
      ],
      "Resource": "arn:aws:iam::ACCOUNT:role/ws-prod-001/*",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalTag/entigo:workspace": "ws-prod-001"
        }
      }
    }
  ]
}

Key enforcement mechanisms:

  • iam:PermissionsBoundary condition: Forces the workspace boundary to be attached to any created role
  • Resource ARN restrictions: All created roles/policies must be under the workspace path (ws-prod-001/*)
  • Any new role created without the boundary will be denied, preventing privilege escalation

Azure and GCP​

Azure and GCP have different access control models:

  • Azure: ABAC is limited to storage data-plane actions. Workspace isolation is better achieved via resource-group-per-workspace or subscription-per-workspace with Azure RBAC scoping. Azure Policy can enforce tag inheritance.
  • GCP: GCP Tags (organization-level, IAM-integrated) can be used with IAM Conditions for tag-based access control. GCP Labels do not support IAM conditions.

Implementation for Azure and GCP is under consideration for future iterations.

Alternatives Considered​

Alternative 1: Separate AWS Accounts per Workspace​

Approach: Enforce one AWS account per workspace, using account-level isolation instead of tag-based ABAC.

Pros:

  • Strongest isolation — no possibility of cross-workspace access
  • No tag dependency for isolation
  • Simpler IAM policies

Cons:

  • Higher infrastructure costs — some customers want multiple workspaces in one account
  • Account proliferation management overhead
  • Does not address zone-level isolation within a workspace

Partially adopted: One workspace per account is the recommended deployment, but not enforced. Tag-based ABAC provides isolation when account is shared with resources outside of workspace scope.

Alternative 2: Resource-Name-Based Isolation​

Approach: Use resource naming conventions (e.g., prefix all resources with workspace ID) and IAM policies with resource ARN patterns.

Pros:

  • Works without tags
  • ARN-based conditions are well-understood

Cons:

  • Not all AWS resources support ARN patterns in conditions
  • Naming conventions are brittle and hard to enforce
  • Does not support zone-level scoping
  • Cannot be applied to existing resources without renaming

Rejected: Tag-based ABAC is more flexible and works with existing resources.

Consequences​

Positive​

  1. Strong workspace isolation — Permission boundaries enforce hard limits that identity policies cannot exceed
  2. Zone-level scoping — Identity policies restrict within the boundary for fine-grained access
  3. Privilege escalation prevention — Delegated role creation is constrained to stay within the workspace boundary

Negative​

  1. Tag dependency — ABAC requires consistent, correct tagging. A mis-tagged resource becomes inaccessible or over-accessible
  2. Service coverage — Not all AWS services support aws:ResourceTag conditions. A service compatibility matrix is needed.
  3. Policy complexity — IAM policies with ABAC conditions are harder to write, read, and debug
  4. Migration path — Existing resources must be tagged before ABAC enforcement is enabled

Neutral​

  1. Azure and GCP require different approaches — Tag-based ABAC is AWS-specific; other providers will need separate isolation strategies
  2. One boundary per principal — AWS limitation is addressed by using a single workspace boundary with identity policies for zone scoping

References​