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

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