Keyless cloud access

Does my cluster my-cluster have workload identity, and which add-ons and apps on it use a cloud identity?

Ask Nova

Rather not read it all? Ask Nova this. It reads the cluster and its add-ons' and apps' settings, and explains what is set up and what is missing.

Your applications and add-ons reach your cloud with no key stored on the cluster. Each pod signs in as a cloud identity bound to its Kubernetes ServiceAccount, through workload identity, and gets short-lived tokens. Workload identity lets a pod sign in but grants nothing: until you grant an identity access, your cloud refuses it.

What do you want to do?

• Connect my app to a cloud service, such as a bucket, queue or vault: Connect to your cloud, then your cloud's steps.
• Give an add-on cloud access, for DNS, certificates, scanning or model weights: the add-on table, below.
• Pull or push my images: Registry access.
• Turn it on for a cluster I registered: Turn it on, below.

How keyless works

Every grant has the same three parts, on any cloud:

1. An identity in your cloud for one workload: an IAM role on AWS, a Google principal on Google Cloud, a managed identity on Azure.
2. A grant on one resource: one bucket, zone, queue or registry, never the whole account.
3. A trust that lets only that workload's namespace and ServiceAccount sign in as the identity.

Removing the grant or the trust cuts access at once. A refused call means one part is missing; your cloud's page lists each error and its fix: AWS, Google Cloud, Azure.

On a cluster AstroPulse creates, two things work with no setup: nodes pull from your cloud's own registry, and Node Autoscaling on EKS has its own role.

How your app gets its identity

Your cloud trusts the app's namespace and the ServiceAccount it runs as. That ServiceAccount comes from the app's source: a Helm chart's values (for a Repository app, a values file in the repository), or a ServiceAccount in your YAML. An app from a container image runs as the namespace's default ServiceAccount, so deploy it from Helm or YAML to give it an identity of its own. A model's access is set on the Model Serving add-on.

Put the identity on the app

Set it in the app's source, so AstroPulse deploys it with the app: for a Helm app, the application's Update › Values step in the console, or source.helm.values.object with astroctl app apply; for a Repository app, a values file in the repository; for YAML, the ServiceAccount in your repository. Commit, and AstroPulse syncs it. Your cloud's steps give the exact values.

Don't annotate the live ServiceAccount with kubectl: the app's next sync puts back what its source says.

Give an add-on cloud access

The recipe creates the add-on's identity and its grant. DNS Automation and Model Serving then take the identity in their Change configuration steps, under Cloud access; the others take it in their manifest, as the recipe shows.

Add-on	AWS	Google Cloud	Azure
DNS Automation changes records	Route 53	Cloud DNS	Azure DNS
Certificates, DNS check	Route 53	Cloud DNS	Azure DNS
Vulnerability Scanning, private images	ECR	Artifact Registry	ACR
Model Serving, private weights	S3	GCS	Blob

Before you start

To check that workload identity is on, and to turn it on for a cluster you registered:

• An EKS, GKE or AKS cluster.
• For a registered cluster: rights in your cloud account to change the cluster's settings.

In the console

Check that workload identity is on:

1. Open the cluster from the cluster list. Its Overview has a Cloud identity section: "Who this cluster is in your cloud."
2. Under Per application (recommended), Workload identity reads Available when it is on, and Missing when it is not. The section also shows what a trust policy on your side names: the OIDC issuer on EKS and AKS, or the Workload identity pool on GKE.
3. Give one app access, e.g. a bucket of model weights opens your cloud's page.

A registered cluster does not report it, so its Overview shows no Workload identity row. Check it with your cloud's commands instead.

You should see

Workload identity reads Available. On a registered cluster, the check on your cloud's page prints the cluster's issuer or pool.

Turn it on for a registered cluster

Each cloud's page has the check, the command that turns it on, and the undo:

• AWS (EKS): the cluster's IAM OIDC provider.
• Google Cloud (GKE): a workload identity pool on the cluster, and GKE_METADATA on each node pool your workloads run on.
• Azure (AKS): the cluster's OIDC issuer and workload identity.

Other ways in

• Nova: ask, for example, "does my-cluster have workload identity, and what can its workloads reach?".
• SDK and API: the cluster's workloadIdentity (Available or Missing) and its cloudIdentity. See the API reference.

With astroctl

Terminal

astroctl infra k8s get my-cluster

Next

• Connect to your cloud: the steps for AWS, Google Cloud and Azure.
• Registry access: pull your images, and push them from a build.