Cloud accounts and registries

An org can give Infrared its own Google Cloud projects and AWS accounts. Infrared reaches each one through a role it assumes or a service account it impersonates, never a stored key. An org uses its cloud accounts for two things today:

• Registries: its Products build into a container registry in its own cloud (Amazon ECR or Artifact Registry).
• Workload clusters: in the platform org, a cluster built from a cluster template can take its credentials from a cloud account instead of a Secret you create.

Both live in Settings. Anyone who can open Settings sees them; org admins add and delete them.

Infrared's own identity

Infrared reaches your cloud as one identity of its own, set by the person who installed it, in the chart's cloudIdentity values:

Cloud	Infrared's identity	What you grant
Google Cloud	The install's Google service account (cloudIdentity.gcpServiceAccount)	roles/iam.serviceAccountTokenCreator on a service account of yours, so Infrared can act as it
AWS, on EKS	An IAM role for service accounts (cloudIdentity.aws.roleARN)	Your role trusts that role for sts:AssumeRole
AWS, from outside AWS	The cluster's own service account token (cloudIdentity.aws.webIdentity)	Your account adds the cluster's OIDC issuer as an IAM OIDC provider, and your role trusts it for sts:AssumeRoleWithWebIdentity

With no Google identity set, Infrared reaches no Google Cloud projects; with no AWS identity, no AWS accounts. Add a cloud account says so, and offers only the clouds the install can reach.

Add a cloud account

In Settings → Cloud accounts, choose Add a cloud account, then Google Cloud or AWS. Under What to grant, Infrared shows the exact grant for your account, with a command or a trust policy to copy. Make the grant first, then fill in:

Cloud	Fields
Google Cloud	Name (a lowercase label such as prod-gcp), Display name, Project ID, and the Service account Infrared acts as, such as [email protected]. Give that service account the roles Infrared should have in the project
AWS	Name, Display name, Account ID, the Role ARN Infrared assumes, and an optional External ID (not for the web identity mode). Give that role the permissions Infrared should have

Choose Add and check. Infrared checks the account by acting as it, which can take up to a minute; the form is locked meanwhile.

• Verified: the account is kept, and the list shows which identity Infrared acted as.
• The check failed: nothing is kept, and the form says why.
• Still checking after a minute: Saved, still checking. The account is kept as Pending, and its state updates when the check ends.

Infrared checks every account again every 24 hours. The list shows each account's cloud, its project and service account or account and role, and its state: Verified, Pending or Failed, with when it was last checked and, for one that isn't verified, why.

Delete stops Infrared reaching the account. Nothing changes in the cloud itself.

Registries

A registry lives in one of the org's verified cloud accounts. In Settings → Registries, choose Add a registry, pick the Cloud account, and give it a Name and Display name:

Registry	Cloud account	Fields
Amazon ECR	AWS	Region and an optional Prefix. Infrared creates each Product's repository through the account's role
Artifact Registry	Google Cloud	Location and Repository: a Docker repository you made

Infrared checks the registry and fetches its first credential, waiting up to a minute, the same way as an account: Ready, refused with the reason, or Pending while it finishes. From then on it keeps short-lived push and pull credentials for each registry and refreshes them before they expire, so no registry password is ever stored.

The build registry

Build registry chooses where the org's Products build into: Install default, or one of its Ready registries. Choose one and Save. Products build into <registry>/<product> from their next build; images already released stay where they are. The registry in use is marked Build registry, and can't be deleted until you choose another one or the install default.

Workload clusters on a cloud account

A workload cluster in the platform org can name a cloud account in spec.provision.cloudAccount. Before each OpenTofu run, Infrared mints the account's short-lived credentials as the Secret cluster-<name>-credentials (AWS session keys, or a Google access token) and deletes them when the Job ends, so you create no Secret. The account must be a Verified account of the platform org, and of the same cloud as the cluster's provider. The cluster's page names the account its credentials come from; until it's verified, provisioning waits and says so. See Workload clusters.

API

Call	What it does
GET /v1/cloud-identity	What to grant: the install's Google service account and where its AWS credentials come from
GET /v1/orgs/{org}/cloud-accounts	The org's cloud accounts
POST /v1/orgs/{org}/cloud-accounts	Add one, checked first (org admins)
GET, DELETE /v1/orgs/{org}/cloud-accounts/{name}	Read or delete one
GET /v1/orgs/{org}/registries	The org's registries
POST /v1/orgs/{org}/registries	Add one, checked first (org admins)
GET, DELETE /v1/orgs/{org}/registries/{name}	Read or delete one
GET, PUT /v1/orgs/{org}/build-registry	The org's build registry: {"registry": "<name>"}, or "" for the install default