# Cloud permissions

> What ZopDay needs on AWS, GCP, and Azure to register clusters, provision infrastructure, and deploy.

Source: https://zop.dev/docs/zopday/cloud-setup/permissions

---

ZopDay operates entirely through your cloud account credentials; no separate agent, no proprietary runtime, no traffic through ZopDay. The flip side is that ZopDay needs the right roles to do the work you want it to do.

Permissions are layered. Start with the **cluster-registration** set if you just want BYOC deploys onto an existing cluster. Layer **provisioning** on top only if you want ZopDay to create infrastructure for you.

**Note**

The exact IAM policies / role bindings are versioned alongside the product. Rather than pin a specific role JSON here that may drift, this page describes **what ZopDay needs by capability**. The wizard surfaces the current role template at connection time, and support can hand over a least-privilege template tuned to your subset.

## AWS

### Cluster registration only (read-only)

For BYOC deploys onto a cluster you already have. ZopDay only needs:

- **EKS describe**: to discover the cluster and read its endpoint
- **STS**: to mint short-lived kubeconfigs via the kubeauth flow

You also need to map ZopDay's IAM principal into the cluster's `aws-auth` ConfigMap (or use EKS access entries) so it can authenticate as a Kubernetes user with the right RBAC. See [Cluster registration](https://zop.dev/docs/zopday/cloud-setup/cluster-registration) for the binding pattern.

### Provisioning

Add on top of the cluster-registration set if you want ZopDay to create EKS clusters, RDS instances, VPCs, ASGs, VMs, etc. Categories needed:

- **EKS full**: create / delete / scale clusters and node groups
- **IAM**: create / attach roles for clusters, node groups, and workload identity
- **EC2**: VPC, subnets, NAT, IGW, security groups, route tables, launch templates, instances
- **RDS**: managed Postgres / MySQL
- **ElastiCache**: Redis
- **Auto Scaling**: ASG creation and ECS Application Auto Scaling
- **Secrets Manager**: scoped to the `zopday/` prefix for datastore root passwords

The simplest path is the AWS-managed `PowerUserAccess` (which excludes `iam:*`) plus a narrowly-scoped IAM policy for the role-creation it needs. If your policies forbid `PowerUserAccess`, contact support for a least-privilege template scoped to your subset. The wizard validates after attachment and tells you exactly which Action is missing if anything is denied.

### IAM Import (optional)

Lets the IAM Import wizard preview your IAM users / groups / managed-policy attachments before applying them to ZopDay teams and roles. Read-only; the import does not modify cloud-side IAM. Specific `iam:List*` and `iam:Get*` actions are required; the wizard lists them.

## GCP

### Cluster registration only

```
Role:  roles/container.viewer
Scope: the project that owns the cluster(s)
```

This covers GKE cluster discovery + read. Workload identity / OAuth2 access token minting is automatic on GKE; no additional roles required.

### Provisioning

Add on top:

- **`roles/container.admin`**: GKE cluster create / delete / scale
- **`roles/compute.admin`**: Compute Engine + networking
- **`roles/cloudsql.admin`**: Cloud SQL
- **`roles/redis.admin`**: Memorystore
- **`roles/secretmanager.admin`**: datastore root passwords in Secret Manager
- **`roles/iam.serviceAccountUser`**: to act as service accounts during provisioning

For Shared VPC topologies, also grant `roles/compute.networkUser` on the host project.

For cross-VPC Cloud SQL via Private Service Connect, add `roles/servicenetworking.networksAdmin` on the consumer VPC's project.

### IAM Import (optional)

- **`roles/cloudasset.viewer`** for `ListAssets(IAM_POLICY)`
- **`roles/iam.securityReviewer`** to read IAM bindings

Optional, at the **organisation** level: `roles/cloudidentity.groups.reader` to populate Google Group members on imported teams. Without it, imported teams arrive empty and the wizard surfaces a `gcloud` command to grant the role later.

## Azure

### Cluster registration only

```
Role:  AKS Cluster User Role
Scope: /subscriptions/{subscriptionId}
```

This is the read-only role for fetching AKS cluster kubeconfig credentials. The deploy pod authenticates as the bound AAD identity.

Note: ZopDay's Azure / AKS kubeauth path is stubbed today; full AKS deploy support is in preview / not yet GA. Cluster discovery and registration work; the deploy phase returns a clean error at the kubeauth boundary.

### Provisioning

Add on top:

- **Contributor** (broad); for resource group + provisioning
- **AKS Contributor Role**: cluster create / delete / scale (when AKS support lands)
- **User Access Administrator**: for managed-identity role assignments
- **Key Vault Secrets Officer**: on the Key Vault used for datastore passwords

If your subscription policies forbid `Contributor`, contact support for a tighter set scoped to the specific Azure resource providers ZopDay actually touches.

### Datastores

Additional roles for managed datastore creation:

- **SQL DB Contributor**: Azure SQL
- **Redis Cache Contributor**: Azure Cache for Redis

### IAM Import (optional)

- **Reader** at subscription scope; read AAD principals and role assignments

## Where credentials are stored

Cloud account credentials are stored in ZopDay's Config service vault, encrypted with envelope encryption per org. The credentials are never:

- Logged
- Returned through any API
- Stored in plaintext
- Used by services other than the provisioner / deployer / discoverer

The provisioner and deployer fetch credentials via `configclient.GetCredentials` (gRPC); the same path every service that needs cloud access uses. No cross-service DB access.

## Validating after grant

After granting the roles, **try the smallest possible operation end-to-end**: for cluster registration, register one BYOC cluster and watch the kubeauth-minted kubeconfig succeed. For provisioning, provision a 1-node EKS / GKE / AKS cluster in a non-production VPC.

If anything fails, the error message names the specific permission you're missing. ZopDay does not swallow permission errors. Contact support if you need to interpret the error.