Impersonation
How Alien gets access to manage your application inside the customer's cloud.
Alien needs to manage your application inside the customer's cloud — push updates, read logs, run commands. But no one is going to give Alien their cloud password or an AWS_ACCESS_KEY.
Instead, the customer creates a service identity inside their cloud. This identity exists only to manage your application's isolated area. The customer decides what it can do and configures it to trust Alien. Alien then impersonates this identity whenever it needs to manage your application.
This page explains how that works on each cloud provider.
Azure — Managed Identity
The customer creates a User-Assigned Managed Identity (UAMI) inside the deployment's resource group.
The identity is configured with:
- A custom role scoped to the resource group — defines what Alien can do (update code, read logs, monitor health).
- A federated credential — allows Alien to authenticate via OIDC. Alien proves its own identity to Azure, Azure checks the federation config, and grants access. No secrets are exchanged.
╔═ Alien ═══════════════╗ ╔═ Customer's Azure ════════════════════╗
║ ║ ║ ║░
║ Alien's own identity ║ OIDC token ║ ┌─ Managed Identity ─────────────┐ ║░
║ (workload identity) ╠───────────────▶║ │ │ ║░
║ ║ ║ │ Trusts: Alien (via OIDC) │ ║░
║ Azure verifies the ║ access ║ │ Can: custom role on rg-* │ ║░
║ token, grants access ║◀───────────────║ │ │ ║░
║ ║ ║ └────────────────────────────────┘ ║░
║ ║ ║ ║░
╚═══════════════════════╝ ╚═══════════════════════════════════════╝░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░GCP — Service Account Impersonation
The customer creates a service account in the deployment's project.
The identity is configured with:
- Custom roles per permission set — scoped to the project, defining exactly what Alien can do.
- Impersonation grant — the customer grants Alien's own service account the
roles/iam.serviceAccountTokenCreatorrole on the deployment's service account. This lets Alien request short-lived tokens to act as the deployment's identity.
╔═ Alien ═══════════════╗ ╔═ Customer's GCP ══════════════════════╗
║ ║ ║ ║░
║ Alien's own service ║ generate ║ ┌─ Service Account ──────────────┐ ║░
║ account ╠── token ──────▶║ │ │ ║░
║ ║ (as this SA) ║ │ Trusts: Alien's SA │ ║░
║ GCP checks ║ ║ │ Can: custom roles on project │ ║░
║ impersonation grant ║ short-lived ║ │ │ ║░
║ ║◀── token ──────║ └────────────────────────────────┘ ║░
║ ║ ║ ║░
╚═══════════════════════╝ ╚═══════════════════════════════════════╝░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░AWS — Cross-Account IAM Role
The customer creates an IAM role in their account.
The role has two parts:
- Trust policy — specifies which external account (Alien's AWS account) is allowed to assume this role. This is how the customer says "I trust Alien."
- Permission policy — defines what the role can do, scoped to resources matching the deployment's prefix.
When Alien needs to manage the deployment, it calls sts:AssumeRole — AWS checks the trust policy, and if it matches, returns short-lived credentials (access key + secret key + session token) that expire after one hour. Alien uses these credentials to make API calls as if it were the customer's own role.
╔═ Alien ═══════════════╗ ╔═ Customer's AWS ══════════════════════╗
║ ║ ║ ║░
║ Alien's own IAM role ║ AssumeRole ║ ┌─ Cross-Account IAM Role ───────┐ ║░
║ ╠───────────────▶║ │ │ ║░
║ ║ ║ │ Trusts: Alien's account │ ║░
║ AWS checks trust ║ short-lived ║ │ Can: prefix-scoped actions │ ║░
║ policy, grants creds ║◀── creds ──────║ │ │ ║░
║ ║ (1 hour) ║ └────────────────────────────────┘ ║░
║ ║ ║ ║░
╚═══════════════════════╝ ╚═══════════════════════════════════════╝░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░What they share
All three mechanisms achieve the same thing:
- The customer creates an identity in their cloud with limited permissions.
- The identity trusts Alien — configured explicitly, not by sharing a secret.
- Alien proves who it is to the cloud provider and gets short-lived credentials to act as that identity.
- The customer can revoke access at any time by deleting the identity or removing the trust.
No passwords, API keys, or long-lived secrets cross between the two parties. The cloud provider sits in the middle and brokers the trust.
Alien sets all of this up automatically during initial setup. You define the stack; Alien generates the identity, trust configuration, and permission policies for each cloud.