Cloud permissions

ZopDay works entirely through your cloud account credentials. There is no agent on your BYOC clusters, no proprietary runtime, and no application traffic routed through ZopDay. In return, ZopDay needs the right roles for each job you want it to do, and View Permissions shows you exactly what it has.

Settings → Cloud Accounts → View Permissions: capability by capability, with the individual permissions behind each one a click away.

Before you start

• Permission to create an IAM role, service account, or service principal on the cloud account (AWS), project (GCP), or subscription (Azure) you are connecting.
• A decision on scope: cluster registration only (BYOC deploys onto an existing cluster), or provisioning on top (ZopDay creates infrastructure).
• On AWS, registering an existing EKS cluster needs the account connected with ZopDay provision access. Any of the three AWS connection methods works: WIF-Assume Role, IAM User (Static Keys), or Temporary Credentials.

How it works

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. On AWS, registering a cluster already needs provision access.

Where credentials are stored

Cloud account credentials are encrypted at rest in ZopDay’s credential vault. They are never:

• Returned through any API
• Stored in plaintext

Only the ZopDay services that act on your cloud account (provisioning, deploys, discovery, and execution) fetch them, all through the same internal path. No service reads another service’s database. For builds and installs, they are passed to the GitHub Actions runner, which uses them to mint short-lived access for that run and keeps nothing afterwards.

AWS

Cluster registration

Registering an existing EKS cluster is not a read-only step. Open Settings → Cloud Accounts, choose Manage Clusters on an account with provision access, and click Register on the cluster. ZopDay creates an EKS access entry for its IAM principal with AmazonEKSClusterAdminPolicy, so you do not map it into the aws-auth ConfigMap yourself. For each deploy, ZopDay mints a short-lived kubeconfig through STS.

Provisioning

Add this if you want ZopDay to create EKS clusters, RDS instances, VPCs, ASGs, VMs, and similar resources. The ZopDay CloudFormation stack the wizard links to creates a role with the AWS-managed ReadOnlyAccess policy plus two custom managed policies, each granting full access to its services on all resources (Resource: '*'):

• ZopDayInfraIdentityPolicy: Auto Scaling, EC2, EKS, Elastic Load Balancing, IAM, Route 53, and Systems Manager (autoscaling:*, ec2:*, eks:*, elasticloadbalancing:*, iam:*, route53:*, ssm:*)
• ZopDayDataOperationsPolicy: ACM, ECR, ElastiCache, RDS, and Secrets Manager (acm:*, ecr:*, elasticache:*, rds:*, secretsmanager:*)

The policies use service-wide wildcards to stay under AWS’s managed-policy size limit, so they grant more than the individual actions ZopDay calls, including full IAM. If your policies forbid wildcard or iam:* grants, contact support for a least-privilege template scoped to your subset.

IAM Import (optional)

If you use IAM Import to bring cloud users and groups into teams and roles, it needs read access to IAM so it can preview your IAM users, groups, and managed-policy attachments before you apply them. It is read-only: the import does not modify cloud-side IAM. It requires specific iam:List* and iam:Get* actions, which the wizard lists.

GCP

Cluster registration only

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

ZopDay mints a short-lived OAuth2 token for each deploy, so no key lives on the cluster. roles/container.viewer alone is read-only and cannot apply a deployment: grant roles/container.developer, or bind the service account in Kubernetes RBAC with a ClusterRoleBinding.

Provisioning

Add on top the roles the wizard lists, which are the same ones View Permissions checks:

• roles/container.clusterAdmin: GKE cluster create / delete
• roles/compute.admin: Compute Engine + networking
• roles/compute.osLogin and roles/compute.osAdminLogin: sign in to VMs ZopDay deploys to
• roles/iap.tunnelResourceAccessor: reach those VMs through IAP
• roles/cloudsql.admin: Cloud SQL
• roles/redis.admin: Memorystore
• roles/servicenetworking.networksAdmin: private service access for Cloud SQL and Memorystore
• roles/secretmanager.admin: datastore root passwords in Secret Manager
• roles/dns.admin: Cloud DNS zones and records
• roles/storage.admin: Cloud Storage buckets
• roles/iam.serviceAccountAdmin, roles/iam.serviceAccountUser, and roles/resourcemanager.projectIamAdmin: create service accounts, act as them, and bind their roles
• roles/logging.viewer and roles/monitoring.viewer: read VM logs and metrics

For Shared VPC topologies, also grant roles/compute.networkUser on the host 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.

Azure

Cluster registration only

Role:  Azure Kubernetes Service RBAC Cluster Admin
Scope: /subscriptions/{subscriptionId}

This is the AKS role the setup wizard assigns, alongside Reader. ZopDay fetches each cluster’s kubeconfig through the Azure API, so the principal also needs the Microsoft.ContainerService/managedClusters credential actions, which the ZopDay Infrastructure Access role below includes.

Provisioning

The wizard has you create one custom role, ZopDay Infrastructure Access, from the JSON it shows: its actions cover clusters, networking, Azure Database for PostgreSQL and MySQL flexible servers, Azure Cache for Redis, container registries, and Key Vault, plus the Key Vault secret data actions for datastore passwords. Assign it at subscription scope with the condition Allow user to assign all roles except privileged administrator roles Owner, UAA, RBAC (Recommended), and also assign:

• Reader
• Azure Kubernetes Service RBAC Cluster Admin

ZopDay does not need Contributor, User Access Administrator, Key Vault Secrets Officer, or Redis Cache Contributor.

IAM Import (optional)

• Reader at subscription scope: read AAD principals and role assignments

Checking what you actually granted

To confirm a grant landed, open Settings → Cloud Accounts and click View Permissions on any connected account. ZopDay groups what it checked by capability (provisioning EC2 instances, EKS clusters, ElastiCache, RDS, and so on) and shows how many individual permissions sit behind each one. Expand a capability to see exactly which permission is missing, instead of a single pass or fail.

Validate the grant

After granting the roles, try the smallest possible operation end-to-end:

1. Check View Permissions

   Confirm each capability you need shows as working in Settings → Cloud Accounts → View Permissions.

2. Run the smallest operation

   For cluster registration, register one BYOC cluster and confirm the kubeauth-minted kubeconfig succeeds. For provisioning, provision a 1-node EKS / GKE / AKS cluster in a non-production VPC.

Troubleshooting

Next steps