If you don’t have enough quota, request an increase through the GCP Console. Quota increases are usually approved within minutes for established accounts.
Qovery needs credentials to manage resources in your GCP project. Choose your preferred method:
Workload Identity Federation (Recommended)
Service Account JSON Key
Most secure method - Uses short-lived access tokens generated through GCP Workload Identity Federation (WIF). No downloadable service account JSON key is created or stored.
This mode is recommended if your organization disables service account key creation with constraints/iam.disableServiceAccountKeyCreation.
What the setup configures:
A GCP service account used by Qovery to manage your GKE resources
The Qovery custom IAM role, created or updated and bound to this service account
A Workload Identity Pool
An AWS Workload Identity Provider that trusts the Qovery AWS deployer identity used by q-core
A service account impersonation binding (roles/iam.workloadIdentityUser)
An organization policy entry allowing this service account to receive 4 hour access tokens
With this setup, Qovery does not receive a JSON private key. Instead, q-core exchanges the configured Qovery AWS deployer identity for a temporary GCP access token, then uses that token to create, update, or delete your GKE cluster.
The account running the setup script must have enough permissions to configure both the GCP project and the GCP organization.At the project level, it must be able to:
enable GCP services;
create or reuse a service account;
create or update the Qovery custom IAM role and bind it to this service account;
create or update a Workload Identity Pool and Provider;
add roles/iam.workloadIdentityUser on the service account.
At the organization level, it must be able to update organization policies. Qovery requires 4 hour temporary tokens for GKE operations, so the script configures:constraints/iam.allowServiceAccountCredentialLifetimeExtensionfor the Qovery service account.For this last step, the account needs the Organization Policy Administrator role (roles/orgpolicy.policyAdmin) on the GCP organization, or an organization administrator must run this step for you.
Select Workload Identity Federation as the credential method.Qovery will generate a setup command for your GCP project. The command contains only your GCP setup values. The Qovery AWS account and principal to trust are embedded in the setup script, but no Qovery secret is embedded.
3
Copy the Command
Copy the generated command to your clipboard.The command will look like:
The setup script creates or reuses the GCP service account named YOUR_SERVICE_ACCOUNT_NAME. Always provide this service account name explicitly.Qovery requires 4 hour temporary tokens for GKE operations. The setup script uses default Qovery resource names, resolves the GCP organization ID from YOUR_PROJECT_ID, and configures constraints/iam.allowServiceAccountCredentialLifetimeExtension for the Qovery service account.If your project is not directly attached to an organization, or if the script cannot resolve it, rerun the command with the organization ID as the last argument.
In Google Cloud Console, click the Cloud Shell icon in the top-right
Wait for Cloud Shell to initialize
Ensure you’re in the correct project: gcloud config get-value project
2
Run the Command
Paste the command from Qovery into Cloud Shell
Press Enter
The script will:
Enable required GCP APIs
Create or reuse the Qovery service account
Create or update the Qovery custom IAM role
Bind the Qovery custom IAM role to the service account
Create or reuse the Workload Identity Pool
Create or update the AWS Workload Identity Provider
Allow the Qovery AWS identity to impersonate the GCP service account
Allow this service account to receive 4 hour access tokens
Example output:
Operations completed.Store these values in Qovery:service_account_email=my-qovery-sa@my-company-production-123456.iam.gserviceaccount.comworkload_identity_provider_resource=projects/123456789012/locations/global/workloadIdentityPools/qovery-wif-pool/providers/qovery-awsNo JSON service account key was created.
3
Save Workload Identity Federation Credentials in Qovery
Return to Qovery Console and paste the values returned by the script:
Service account email
Workload Identity provider resource
Qovery will verify the configuration and save the credentials.
By default, GCP service account impersonation access tokens are limited to 1 hour.Qovery requires a 4 hour token lifetime for GKE operations, similar to the AWS EKS STS flow. To allow this, your GCP organization must allow the Qovery service account through constraints/iam.allowServiceAccountCredentialLifetimeExtension.If this policy is not configured, Workload Identity Federation credentials cannot be used for Qovery-managed GKE.
You can revoke Qovery’s access at any time by removing the roles/iam.workloadIdentityUser binding from the service account or deleting the Workload Identity Provider.
Why is this more secure than JSON keys?
Service account JSON keys are long-lived private keys. If they leak, they remain valid until you rotate or delete them.With Workload Identity Federation, Qovery receives short-lived access tokens only. No customer private key is downloaded, uploaded, or stored in Qovery.
What permissions does Qovery need?
The Qovery service account still needs the same GCP permissions required to manage GKE, Compute, networking, Cloud Storage, Artifact Registry, and Cloud Run resources.The same Workload Identity Federation credentials can also be used for GCP Artifact Registry in Qovery, as long as this service account has the required Artifact Registry permissions.For a detailed breakdown of every permission and why it is needed, see the GCP IAM Permissions Reference.
Can I reuse an existing service account?
Yes. Pass the existing service account name as YOUR_SERVICE_ACCOUNT_NAME. The script will reuse it, bind the Qovery custom role to it, allow the Qovery AWS deployer identity to impersonate it through roles/iam.workloadIdentityUser, and allow 4 hour access tokens for this service account.
Can I keep using JSON keys?
Yes. Service account JSON keys remain supported for existing installations and organizations that allow service account key creation.However, Workload Identity Federation is recommended for new GCP credentials.
Legacy method - Creates a downloadable service account JSON key and uploads it to Qovery.
Workload Identity Federation is recommended for new GCP credentials. Use JSON keys only if your organization allows service account key creation and you cannot use WIF yet.
This script creates a service account with minimal required permissions.
If you enable static egress IPs for GCP NAT Gateway, the role must also include compute.addresses.create, compute.addresses.get, compute.addresses.list, and compute.addresses.delete.
Typical Terraform failure when missing: Required 'compute.addresses.create' permission ... forbidden.
Create a service account named qovery-service-account
Assign necessary IAM roles
Generate and download a JSON key file (key.json)
Example output:
Activating services APIsOperation "operations/acf.p2-..." finished successfully....Creating service account qovery-service-accountCreated service account [qovery-service-account]....created key [abc123...] of type [json] as [key.json]✓ Credentials configured successfully
3
Download the Key File
In Cloud Shell, click the More menu (three dots)
Select Download
Enter the file path: key.json
Save the file securely
Keep this JSON key file secure! It provides access to your GCP project. Never commit it to version control.
4
Upload to Qovery
Return to Qovery Console
Upload the key.json file when prompted
Qovery will verify the credentials
You can reuse these credentials for multiple clusters in the same GCP project.
What permissions does Qovery need?
Qovery requires these GCP permissions to manage your infrastructure:
Compute Engine: Create and manage VMs, networks, and load balancers
Kubernetes Engine: Create and manage GKE clusters
VPC Networking: Configure networks, subnets, and firewall rules
Service Accounts: Manage service identities for workloads
If static egress IPs are enabled on NAT Gateway, your role also needs compute.addresses.* permissions to reserve external IPs.The installation script automatically assigns the minimum required roles to the service account.
Can I use a custom service account?
Yes! You can create a service account manually with custom permissions.
However, ensure it has all the roles required for managing GKE, Compute
Engine, and networking resources. Contact support for the minimal permissions
list.
How do I rotate credentials?
To rotate GCP credentials:
In GCP Console, go to IAM & Admin → Service Accounts
Virtual Private Cloud (VPC) with custom subnet ranges
Cloud NAT for outbound internet connectivity
Cloud Router for dynamic routing
Static external IP addresses
Firewall rules for security
Load balancers for ingress traffic
Advanced Networking Options
Qovery-Managed VPC (Default):
Qovery creates a dedicated VPC for your cluster with optimal configuration.Existing VPC:
Deploy into your own VPC to connect with existing GCP resources.Static IP:
Enable static IP addresses at cluster creation (only available with Qovery-managed VPC).VPC Peering:
Configure VPC peering after deployment to connect to databases, Cloud SQL, or other services.
Sufficient IP address ranges for pods and services
Proper subnet configuration
Cloud NAT configured for internet access
Required firewall rules
You can also enable Private nodes during cluster creation to remove public IPs from GKE nodes and route node traffic through your gateway. This setting cannot be changed after the cluster is created.