Cloud accounts

A cloud account is how ZopNight reaches your infrastructure: you connect one per AWS account, GCP project, Azure subscription or tenant, Databricks account, Snowflake account, OpenShift Cluster Manager organisation, or Microsoft 365 tenant. Connect read-only to discover resources and price the waste; grant Read + Write only where you want ZopNight to act. You can rotate credentials or switch auth methods later without losing anything.

Settings → Cloud Accounts: every connected account with its health badge, credential type, and permission level, plus Add Cloud Account, IAM import, and Manage clusters for OpenShift.

Before you start

For every provider you need:

• A ZopNight role that can add cloud accounts (the cloud-account:create permission; Admin has it by default). Removing an account later needs cloud-account:delete, which a role can hold separately.
• Admin access on the provider side, enough to create the role, service account, app registration, or credential the wizard asks for.
• A decision on the permission level. Read-only needs only the read grants; Read + Write also needs the start/stop grants for the services you want ZopNight to act on. See Read-only vs read + write and Cloud permissions.

What else to have ready depends on the provider:

How it works

Everything associated with an account (discovered resources, groups, recommendations, cost history, schedules) is keyed off the account’s stable cloud identity: the AWS 12-digit account number, Azure subscription or tenant GUID, GCP project id, or Databricks account id. That identity is always resolved live from the provider, never taken from what you type in, which is why rotation and auth-method switches keep all your data.

Supported providers & auth methods

For the mechanics of each (trust policies, encryption, rotation cadence), see Authentication. For the IAM permissions each needs, see Cloud permissions.

Read-only vs read + write

Every account carries a permission level that governs what ZopNight may do with it.

Level	ZopNight can	ZopNight cannot
Read-only	Discover resources, read metadata and billing, generate recommendations, and allow schedules to be attached	Start, stop, or remediate anything
Read + Write	All of the above, plus manual start/stop, bulk start/stop, scheduled execution, and auto-remediation	None

Read-only is enforced server-side: the executor checks the account’s live permission level and returns a read-only error before any cloud call is made. The scheduler re-reads each account’s level whenever it reconnects to the config stream, so upgrading or downgrading takes effect on already-running schedules in real time, with no restart needed.

Connect an account

1. Open Add Cloud Account

   Settings → Cloud Accounts → Add Cloud Account. The wizard runs in five steps: Select Provider, Auth Method, Permission Level, Setup Guide, and Enter Credentials.

2. Grant access on your side

   Follow the in-wizard setup guide (trust policy, service account, or app registration). For GCP One-Click, a guided 3-step Google consent flow provisions the managed service account for you. The Google user who signs in must be able to administer the project’s IAM (a custom role, a group grant, or an inherited folder or organisation binding all qualify, not only roles/owner).

3. Verify

   ZopNight verifies the credential live against the provider before it saves anything, so a successful connect is itself the proof. The cloud_account_id is read from the provider’s response, not from your input. If verification fails, see Troubleshooting.

Rotate credentials or switch auth method

You can rotate an account’s credentials, or switch its auth method entirely, without deleting and recreating the account. All resources, groups, recommendations, cost history, and schedules are preserved.

Provider	Supported transitions
AWS	Any-to-any across Static Keys, Temporary Credentials, and Assume Role (WIF)
Azure	Service Principal ↔ Workload Identity Federation; on a tenant parent the change cascades to every child subscription
GCP	One-Click Connect ↔ Service Account Key. Switching to One-Click runs the Google sign-in and finishes on the existing project in place. Switching away leaves the ZopNight-managed service account in your project, unused but not deleted
Databricks	Rotate the OAuth M2M credential via the inline rotation form

This applies to rotations too, not just method switches: a same-method credential update runs the same live same-account check before storing, so a wrong or foreign credential can’t overwrite the vault and break discovery.

In the UI, the Edit Cloud Account drawer (AWS, Azure, and GCP) has an Update credentials button that opens a 3-step wizard (Auth Method → Setup Guide → Enter Credentials), the same steps as the Connect wizard. Step 1 preselects your current method (marked Current): keep it to rotate, pick another to switch. For GCP, picking One-Click runs the Google sign-in instead of a Save step. Databricks uses an inline rotation form.

Connect an OpenShift cluster

A ROSA cluster connects differently from EKS, GKE, or AKS. On those three, the cloud account’s own credentials can already talk to the cluster API, so there is nothing extra to do. An OpenShift Cluster Manager credential is not a Kubernetes credential. It authenticates to a different service, so a discovered ROSA cluster is listed but unreadable until you connect it explicitly.

Clusters are connected one at a time, from Manage clusters on the account card or from the cluster’s own page. There is no bulk action, because the three methods collect three different kinds of credential:

Method	What happens	Needs
Automatic	ZopNight creates an htpasswd identity through OCM and grants it cluster-admins. The only method that writes to your cluster, and the only one where the identity it creates holds cluster-admin privileges. Pick one of the two below if that is more than you want to grant.	OCM Organization Administrator
Cluster login	You create the identity and bind a read role; ZopNight exchanges your username and password for a short-lived token and provisions nothing.	A cluster login you create
Service account	You create a Kubernetes ServiceAccount and hand over its token. Never touches OpenShift’s OAuth server, so this is the only method that works on a cluster running external authentication.	A ServiceAccount token

Pod consolidation

On the cluster’s Settings tab, below the autoscaler, you can switch on pod consolidation. ZopNight configures the OpenShift descheduler to move pods off barely used nodes, so the cluster autoscaler can remove the emptied nodes. You set simulate or evict mode, how often it runs, caps on pods moved per node and in total, namespaces to leave alone, and how empty a node must be (10%, 20%, or 30% of requested capacity).

• It never removes a node itself. The autoscaler’s scale-down does that, so a save that could not free a node (scale-down off, no pool set to autoscale, or a threshold above the autoscaler’s own) is refused.
• Pods with their own storage are always skipped.
• The platform installs the descheduler operator the first time you switch consolidation on. Switching it off removes the configuration and leaves the operator in place.
• If the cluster’s scheduler spreads pods across nodes (the OpenShift default), evicted pods can land straight back on the same node. The tab warns you when evict mode is selected on such a cluster; only a cluster admin can change the scheduler profile.
• A descheduler configuration the platform did not create is shown read-only and never replaced.
• Only the Automatic connect method can write this configuration today. The Cluster login and Service account methods bind a read-only role, so a save on a cluster connected that way fails with a permission error. Connect the cluster with Automatic, or grant the identity write access to the descheduler configuration, before switching consolidation on.

Account actions

Action	What it does
Update	Change display name, permission level, ZopDay access level (whether ZopDay may use this account for provisioning and deploys), credentials (verified rotation), or auth method (verified in-place change)
Permission upgrade (GCP One-Click)	Re-binds the managed service account’s roles using the stored OAuth token, so there is no need to re-mint the SA key
Cluster registration (ZopDay)	Register an EKS, GKE, or AKS cluster so ZopDay can deploy to it. See Cluster registration for what each cloud supports
Delete	Soft-deletes the account (marks it inactive), cascades to Azure tenant children, and cleans up anything imported via IAM Import

Troubleshooting

Next steps