Cloud accounts and registries

An org can give Infrared its own Google Cloud projects and AWS accounts. Infrared reaches each one by acting as a service account of yours or assuming a role of yours, never with a stored key, so there's no long-lived cloud secret to leak or rotate. An org uses its cloud accounts for two things:

• Registries. Its Products build into a container registry in its own cloud, Amazon ECR or Artifact Registry.
• Workload clusters. A cluster built from a cluster template takes short-lived credentials from a cloud account, so you create no credentials Secret.

Both live in Settings, in the Cloud accounts and Registries panels. Everyone 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, which the person who installed it sets in the chart's cloudIdentity values:

Cloud	Infrared's identity	What you grant it
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, on EC2 nodes	The node's role, through instance metadata (cloudIdentity.aws.hostNetwork).	Your role trusts the node's 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, and 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

1. In the Cloud accounts panel, choose Add a cloud account, then pick the Cloud: Google Cloud or AWS.

2. Under What to grant, Infrared shows the exact grant for your account, as a gcloud command or a trust policy to copy. Make the grant first.

3. Fill in the fields:

   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. Give that role the permissions Infrared should have.

4. Choose Add and check. Infrared checks the account by acting as it once, which can take up to a minute.

The check ends one of three ways:

• 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 its 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 the Registries panel, 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.

Choose Add and check. Infrared checks the registry and fetches its first credential, waiting up to a minute, just as it does for an account: Ready, refused with the reason, or Pending while it finishes. From then on it keeps short-lived push and pull credentials for the registry and refreshes them before they expire. 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 built stay where they are. The registry in use says In use as the 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 built from a template names a cloud account in spec.provision.cloudAccount, or you pick it as Cloud account when you build the cluster on Clusters. 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 run ends.

The account must be Verified, of the same cloud as the cluster, and belong to the platform org, or, for an org's own cluster, to that org. The cluster's page names the account its credentials come from. Until the account is verified, the build waits and says so.

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