Cloud Scoping

Your application lives in a small, isolated area within the customer's cloud account. This page explains what that area looks like on each provider, and how the boundary is drawn.

The requirements are the same everywhere: lightweight to set up, fine-grained enough that your application can't touch anything outside its boundary, and easy for the customer's security team to review.

For Operate Existing, the same boundaries define read-only inventory scope. Alien observes resources in the agreed account, project, resource group, or Kubernetes selector without taking lifecycle ownership.

Azure — Resource Group

A resource group is a container that holds related resources. It's the clearest model — the boundary is explicit and visible in the Azure portal.

The customer creates a resource group for your deployment. All of your application's resources live inside it. Permissions are scoped to the group — Alien can't see or manage anything in other resource groups.

╔═ Customer's Azure Subscription ════════════════════════════╗
║                                                            ║░
║  ┌─ rg-acme-myapp ───────────────────────────────────┐     ║░
║  │                                                   │     ║░
║  │  Container App · Blob Storage · Service Bus       │     ║░
║  │  Key Vault · Managed Identity                     │     ║░
║  │                                                   │     ║░
║  └───────────────────────────────────────────────────┘     ║░
║                                                            ║░
║  Other resource groups — untouched.                        ║░
╚════════════════════════════════════════════════════════════╝░
 ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

GCP — Project

A GCP project is a natural isolation boundary. Each project has its own resources, permissions, and billing.

The customer creates a project for your deployment. Alien's permissions are scoped to that project with custom IAM roles generated from Alien's permission sets, resource-level bindings, and IAM Conditions where GCP supports them. Other projects in the customer's organization are invisible.

╔═ Customer's GCP Organization ══════════════════════════════╗
║                                                            ║░
║  ┌─ Project: acme-myapp ────────────────────────────┐      ║░
║  │                                                  │      ║░
║  │  Cloud Run · Cloud Storage · Pub/Sub             │      ║░
║  │  Secret Manager · Service Account                │      ║░
║  │                                                  │      ║░
║  └──────────────────────────────────────────────────┘      ║░
║                                                            ║░
║  Other projects — untouched.                               ║░
╚════════════════════════════════════════════════════════════╝░
 ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

AWS — Resource Prefix

AWS doesn't have a built-in container like a resource group or project. Instead, the boundary is defined through a naming prefix — a short, unique string that all of your deployment's resources share.

Alien generates an 8-character prefix for each deployment (e.g. k44e9b72). Every resource is named with this prefix: k44e9b72-worker (Lambda), k44e9b72-data (S3 bucket), k44e9b72-tasks (SQS queue). IAM policies then restrict access to resources matching that prefix — every ARN is scoped to k44e9b72-*.

╔═ Customer's AWS Account ═══════════════════════════════════╗
║                                                            ║░
║  Resources matching prefix "k44e9b72-*":                   ║░
║  ┌─────────────────────────────────────────────────────┐   ║░
║  │                                                     │   ║░
║  │  k44e9b72-worker    (Lambda)                        │   ║░
║  │  k44e9b72-data      (S3 bucket)                     │   ║░
║  │  k44e9b72-tasks     (SQS queue)                     │   ║░
║  │  k44e9b72-secrets   (Secrets Manager)                │   ║░
║  │                                                     │   ║░
║  └─────────────────────────────────────────────────────┘   ║░
║                                                            ║░
║  Other resources — denied by IAM policy.                   ║░
╚════════════════════════════════════════════════════════════╝░
 ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

Why a prefix instead of tags or a dedicated account? A few reasons:

• Works everywhere. S3 bucket names, Lambda function names, SQS queue names, Secrets Manager names — all support prefix-based scoping in IAM policies. Not all AWS services support tag-based access control.
• Lightweight. No need to create a separate AWS account or organization unit per customer. Hundreds of deployments can coexist in the same account, each isolated by prefix.
• Reviewable. The customer can look at the IAM policy and see exactly which resources the role can touch — every ARN ends with the prefix pattern.

The prefix is generated automatically by Alien. You don't choose it or manage it.

For observe-only AWS setups, a dedicated account is the cleanest boundary. AWS resource discovery uses account-level tagging APIs, so discovery cannot be fully constrained by tag or prefix.

What all three share

The mechanism differs, but the result is the same:

• Clear boundary — your application's resources are isolated from everything else in the account.
• Revocable — the customer can remove access at any time by deleting the resource group, project, or IAM role.
• Reviewable — the customer's security team can inspect exactly what permissions exist before approving.

Alien derives the scoping automatically from your stack definition. You define the resources; Alien generates the correct naming, policies, and role bindings for each cloud.

For Operate Existing, the customer chooses the scope directly: AWS account or prefix, GCP project, Azure resource group, or Kubernetes namespace and selector.