# Cloud accounts

> Connect AWS, GCP, Azure, and Databricks; pick an auth method and permission level; rotate credentials or switch auth methods in place without losing data.

Source: https://zop.dev/docs/zopnight/cloud-setup/cloud-accounts

---

A cloud account is how ZopNight reaches your infrastructure; one per AWS account, GCP project, Azure subscription/tenant, or Databricks account. This page covers the auth methods per provider, the read-only vs read + write choice, and how to rotate credentials or switch auth methods later without losing anything.

![Cloud accounts page with connected AWS, GCP, Azure, and two Databricks accounts, each showing permission level, credential type, health status, and Import IAM / View Permissions actions](https://storage.googleapis.com/zopdev-blog-resources/1/files/originals/20260707/992551c5-01b1-42bc-80c9-9e74997122bd-cloudaccounts.png)

*Settings → Cloud accounts; each connected account with its permission level, credential type, and health, plus Add Cloud Account and per-account IAM import.*

**Note**

Everything associated with an account (discovered resources, groups, recommendations, cost history, schedules) is keyed off the account's stable **cloud identity** (AWS 12-digit account number, Azure subscription/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.

## Supported providers & auth methods

**AWS**

    **WIF-Assume Role** (recommended): a keyless cross-account IAM role, no long-lived secret stored · **IAM User / Static Keys** · **Temporary Credentials** (short-lived STS)

**GCP**

    **One-Click Connect** (recommended): sign in with Google; ZopNight provisions and manages a dedicated service account · **Service Account Key** (customer-provided JSON)

**Azure**

    **Service Principal** (recommended): app registration + client secret · **Workload Identity Federation**: federated OIDC, no client secret to store

**Databricks**

    **OAuth M2M**: an account-level OAuth service principal. On AWS/GCP it's a standalone connection; on Azure it rides the subscription. See [Databricks](https://zop.dev/docs/zopnight/concepts/databricks).

For the mechanics of each (trust policies, encryption, rotation cadence), see [Authentication](https://zop.dev/docs/zopnight/authentication). For the IAM permissions each needs, see [Cloud permissions](https://zop.dev/docs/zopnight/cloud-setup/permissions).

**Note**

**Azure, tenant vs subscription.** A **tenant**-scoped account auto-discovers every accessible subscription and creates a child account per subscription. **Subscription**-scoped accounts are leaf nodes. Credential, auth-method, and delete operations on a tenant parent **cascade** to its children.

## 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, no restart needed.

## Connecting an account

**Open Add Cloud Account**

  Settings → Cloud accounts → **Add Cloud Account**. Pick the provider and auth method.

**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.

**Verify**

  ZopNight verifies the credential **live** against the provider before persisting anything; a successful connect is itself the proof. The `cloud_account_id` is read from the provider's response, not from your input.

**Note**

**If verification fails**, the account is not saved and the wizard shows the reason. Common causes are a missing or misconfigured role/trust policy, a wrong external ID, an unresolvable service account or app registration, or the wrong region/scope. Fix the grant on your side and retry, or contact support.

## 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; rotate the key or re-provision the managed service account via the inline rotation form |
| **Databricks** | Rotate the OAuth M2M credential via the inline rotation form |

**Warning**

**Same-account guarantee.** New credentials are verified against the live provider **before anything changes**, and must resolve to the **same** cloud identity as the existing account (the AWS account number, a reachable Azure subscription, or the same tenant). If they resolve to a *different* identity, or verification fails, the request returns an error and nothing changes; an account can only ever be re-authenticated, never silently repointed to a different account.

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) 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. GCP and Databricks use an inline rotation form.

## Managing an account

| 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, no need to re-mint the SA key |
| **Cluster registration (AWS)** | Register an EKS cluster for kubeconfig access, for ZopDay. AWS Assume-Role / WIF accounts only. See [Cluster registration](https://zop.dev/docs/zopday/cloud-setup/cluster-registration) |
| **Delete** | Soft-deletes the account (marks it inactive), cascades to Azure tenant children, and cleans up anything imported via [IAM Import](https://zop.dev/docs/zopnight/cloud-setup/iam-import) |