Actions

When a page shows you what’s wrong, you can often fix it from the same page. Workload, pod and node pages have an Actions menu:

On	Actions
Deployments, StatefulSets, DaemonSets	Restart (a rolling restart), Scale (Deployments and StatefulSets, 0–200 replicas), Roll back (Deployments, to the previous version)
Pods	Delete pod (its controller replaces it)
Nodes	Cordon, Uncordon, Drain (evicts its pods, respecting disruption budgets)

Actions are off by default; your administrator turns them on (see Setting it up), for the cluster the core runs in and for remote sites that run an actuator.

Acting as yourself

Every action runs as you in Kubernetes. It’s sent with your own sign-in, so the cluster’s own permissions decide what you may do, and the cluster’s audit log records you, not a shared service account. Ultraviolet Observability is given no Kubernetes permissions of its own.

So:

• The menu offers what you’re allowed to do. Before showing it, the portal asks the cluster which actions you may run on that object. Anything you can’t do is greyed out with the reason.
• You need the editor role in the portal as well. Viewers see the menu but can’t run anything.
• You sign in with single sign-on. The admin password sign-in can’t act, because it has no identity the cluster knows.

Confirming it’s you

Before any change you confirm what will happen: the dialog says exactly what the action changes (for a rollback, which images go back to which), and warns when the change won’t last:

• Managed by Argo CD or Flux: the next sync puts the old state back. Change it in Git instead, or pause the sync first.
• An autoscaler manages the replicas: a manual scale is overridden.

A change also needs a recent sign-in: within the last 15 minutes by default. If yours is older, Confirm it’s you signs you in again and brings you back to the same dialog. Some setups ask for this before every action (see Google Kubernetes Engine).

Checking it worked

After an action the dialog follows it until the cluster shows the result: the rollout finished with every replica available, the pod gone, the node empty. The outcome is succeeded, failed (with why) or unverified (the check couldn’t finish, for example because your sign-in expired).

Every action, whether it was refused, failed or succeeded, is in the audit trail under Actions, with who asked, what changed, and the verified result. The menu also shows the last action on that object.

Setting it up

Turn actions on in the chart and tell the core which token your cluster accepts. Your cluster must already trust your identity provider’s sign-ins (most teams that map single sign-on to Kubernetes permissions have this).

queryApi:
  auth:
    mode: oidc        # actions need single sign-on
  actions:
    enabled: true
    token: id_token   # see the table below

Your cluster	Settings	What the token can reach
API server configured for your identity provider (k3s, RKE2, OpenShift, EKS with an OIDC identity provider)	token: id_token. The portal’s client ID must be one of the API server’s accepted audiences.	Only clusters that trust that client ID.
GKE configured to accept your identity provider’s tokens	token: id_token	Only that cluster.
GKE with Google sign-in	See below.	Everything in Google Cloud your account can do.

See Actions in the configuration reference for every setting.

Google Kubernetes Engine with Google sign-in

GKE accepts a Google sign-in token only when it carries full Google Cloud access, and Google has no narrower permission that covers just Kubernetes. To keep that token as short-lived as possible:

queryApi:
  actions:
    enabled: true
    token: access_token
    stepUpScopes: https://www.googleapis.com/auth/cloud-platform
    revokeAfterUse: true

• Everyday sign-in still asks Google only for your name and email address. Google Cloud access is requested only when you confirm it’s you before an action, and Google shows a consent screen for it.
• The token is revoked at Google as soon as the action is verified, and when you sign out, so it lives for minutes rather than an hour. Each action therefore asks you to sign in again.
• The token can do anything your Google account can do in Google Cloud while it lives. Have the people who act hold roles such as Kubernetes Engine Developer, not Owner, or configure GKE to accept your identity provider’s tokens instead (the row above), which reaches only the cluster.

Remote sites

At a remote site, actions are run by the site’s actuator, a small component in the site’s chart. Nothing connects in to the site: the actuator asks the core for work over the site’s existing outbound connection, through its connector, the same way the site sends its data.

• Every request is signed by the core and checked by the actuator against the core’s public key, which you set in the site’s chart. The actuator refuses a request that isn’t signed with it, is meant for another site, has expired (after a minute or two), or has already run. The connection in between can’t make up or redirect a request.
• Only the actuator gets them. The connector passes requests only to the actuator, which proves itself with a token the chart shares between the two.
• It still runs as you, in one of two ways, chosen per site:

Mode	How it acts as you	The site’s cluster needs
Passthrough (recommended)	Your own token from your sign-in travels with the request, encrypted so that only that site’s actuator can read it. The cluster checks it with your identity provider.	To trust your identity provider’s tokens, as for the core’s own cluster. The actuator gets no Kubernetes permissions.
Impersonate	The actuator’s service account impersonates you, by your verified email (or subject) and your groups.	Nothing special, but the actuator may impersonate the people you list, and the site trusts the core to say who you are.

Use passthrough where the site’s cluster can trust your identity provider, and impersonate where it can’t (an air-gapped cluster with its own sign-in, for example). Kubernetes can only limit impersonation to names you list, so in that mode list each person who should be able to act at that site, by the email they sign in to the portal with. Someone who isn’t listed sees each action refused with “This cluster’s actuator may not act as” their email.

The menu appears on a site’s pages while its actuator is connected. Sites shows each site’s actuator, whether it’s connected, how it acts, and which automatic fixes the site allows. Runbooks act on their own only at sites whose chart allows it, as a dedicated service account, never as a person.

Adding the actuator to a site

1. On the core, turn on remote sites:

   queryApi:
     actions:
       enabled: true
       remoteSites: true

2. Open Sites. The Actions card shows the settings to copy, with the core’s public key filled in.

3. Add them to the site’s chart values. siteId must be the name the site was enrolled as:

   siteId: factory-berlin
   actuator:
     enabled: true
     commandPublicKey: <from the Sites page>
     mode: passthrough
     tokenKind: id_token     # access_token for GKE with Google sign-in

   or, to impersonate:

   actuator:
     enabled: true
     commandPublicKey: <from the Sites page>
     mode: impersonate
     impersonate:
       userPrefix: "oidc:"   # as the cluster's own sign-in names people
       users: [alice@example.com, bob@example.com]
       groups: [sre]

4. Upgrade the site’s chart. The site shows as connected on Sites within a minute.

The core’s own cluster can use impersonation too, through an actuator in the core’s chart: set queryApi.actions.core: actuator and the same actuator settings under queryApi.actions.

Keep the portal private

Your sign-in passes through the query API on its way to the cluster, so keep the portal and the query API on a private network, behind your VPN or firewall. Nothing outside needs to reach them: remote sites send data only to the ingest gateway, and connect to enrollment once when they join (see Connecting remote sites securely).