Common Prerequisites for Deployment on GCP

This documentation is for Kyvos 2026.8.x. To view documentation for other Kyvos versions, click here.

This documentation is for Kyvos 2026.8.x. To view documentation for other Kyvos versions, click here.

1. Overview

This page lists the GCP prerequisites that apply to both Kyvos deployment methods — Automated (Terraform-based) and Wizard-based (through Kyvos Manager).

Complete these configurations before you provision or connect any GCP resources for Kyvos, regardless of which deployment path you choose.

2.Virtual Private Cloud Requirements

Configure the required VPC components before deploying Kyvos.

Requirement	Description

Requirement

Description

Serverless VPC

To send requests and receive the responses from GCP functions without using the public internet, you must use the Serverless VPC Access connector.
Serverless VPC Access uses the Serverless VPC Access Service Agent service account. This service account's email address has the following form:
mailto:service-PROJECT_NUMBER@gcp-sa-vpcaccess.iam.gserviceaccount.com

Permissions required
By default, the above service account has the Serverless VPC Access Service Agent role (roles/vpcaccess.serviceAgent). Serverless VPC Access operations may fail if you change this account's permissions.
1. If using a Shared Network, grant the above service account the Serverless VPC Access Service Agent predefined role to the project where the network originally resides.
  Note: You can refer to the GCP documentation to create a Serverless VPC Access connector.

Shared VPC

When using a Shared VPC, assign the Serverless VPC Access Service Agent role to the service account in the project that contains the shared VPC network.

Ensure that the VPC is shared with the project where you deploy Kyvos.
When using an existing VPC for Kyvos, the subnet must have a minimum mask range of /22

On this page:

Read prerequisites:

Common prerequisites for Kyvos Enterprise Deployment

Choose your deployment type:

2.1 Inbound Firewall Rules

Configure inbound firewall rules to allow communication between Kyvos instances. Use the following ports:

Ports	Purpose

Ports	Purpose
`2121`, `2181`, `2888`, `3888`, `4000`, `6602`, `6603`, `6605`, `6702`, `6703`, `6803`, `6903`, `7003`, `45421`, `45440`, `45450`, `45460`, `45461`, `45462`, `45463`, `45464`, `45465`, `45564`, `8005`, `8009`, `8444`, `9444`	Kyvos internal communication: Allow communication between Kyvos instances within the cluster.
`22`, `8080`, `8081`, `8443`, `9443`	External Web application access: Allow access from outside the cluster from the locations where the Kyvos Web application needs to be accessed.

2.2 Load Balancer

If the Load Balancer is being created in an existing VPC, create a proxy-only subnet in the VPC.

For more information proxy-only subnets for Envoy-based load balancers, see the Google documentation.

3. RHEL 8

For RHEL 8-based operating systems, use ‘root privileges’ to move or rename the /etc/pki/tls/openssl.cnf file to another location before proceeding with the deployment.

4. Virtual Machine Configuration Requirements

Use the VM configuration requirements mentioned in Supported GCP Configurations when deploying Kyvos.
Ensure gcloud CLI is installed on the VM instances used for all Kyvos operations.

5. BigQuery

For BigQuery permissions, refer to this section Working with a BigQuery Warehouse Connection.

6. Post-Deployment Load Balancer

Below permissions are required if you want to create Load Balancer via automated deployment with existing service account.

Additionally, if you plan to configure or switch the Load Balancer after the Kyvos cluster has been deployed these permissions will be required on the service account

6.1 Required Permissions

Category	Permission

Category	Permission
Instance Groups	`compute.instanceGroups.get` `compute.instanceGroups.list` `compute.instanceGroups.update` `compute.instanceGroupManagers.get` `compute.instances.use`
Backend Services	`compute.backendServices.list` `compute.regionBackendServices.list`
Health Checks	`compute.healthChecks.get` `compute.regionHealthChecks.get`

7. Existing Service Account

Configure the required custom and predefined IAM roles for the Kyvos service account before deployment. The following permissions and roles are required for different Kyvos deployment scenarios.

Note

If you create a Service Account with the Kyvos-provided Terraform scripts, skip the sections below.

7.1 Create a Custom Role

Go to Roles > Create new role.
Provide a name, such as Kyvos-role, for the storage service.
Assign the following permissions to the role.
Attach the custom role to the Kyvos service account.

Permission area	Permissions

Permission area	Permissions
Compute	`compute.disks.setLabels`
	`compute.disks.get`
	`compute.instances.start`
	`compute.instances.stop`
	`compute.instances.list`
	`compute.instances.setLabels`
	`compute.instances.get`
	`compute.instances.setMachineType`
	`compute.instances.setMetadata`
	`compute.regions.list`
	`compute.regions.get`
	`compute.zones.list`
	`compute.instanceGroups.list`
	`compute.instanceGroupManagers.get`
	`compute.instanceGroupManagers.update`
	`compute.subnetworks.get`
	`compute.firewalls.list`
	`compute.machineTypes.get`
	`compute.machineTypes.list`
Storage	`storage.buckets.get`
	`storage.buckets.list`
	`storage.buckets.update`
	`storage.objects.create`
	`storage.objects.delete`
	`storage.objects.get`
	`storage.objects.list`
	`storage.objects.update`
Cloud Functions	`cloudfunctions.functions.get`
Cloud Functions	`cloudfunctions.functions.update`
Secret Manager	`secretmanager.versions.access`
Secret Manager	`secretmanager.secrets.list` `secretmanager.versions.add`
IAM and project	`resourcemanager.projects.getIamPolicy`
IAM and project	`iam.roles.get`

7.2 Additional Predefined Roles

Add the following predefined roles to the service account used by the Kyvos cluster:

Cloud Functions Admin
Cloud Scheduler Admin
Cloud Scheduler Service Agent
Service Account User
Logs Writer

7.3 Service Account Roles and Permissions

Ensure that the Kyvos Service Account has the following roles and permissions based on your deployment requirements:

Requirement	Description

Requirement	Description
Automatic Kyvos secret key retention management	Assign the Secret Manager Secret Version Manager predefined IAM role to existing Kyvos Service Account.
Shared Network	If Kyvos uses a Shared Network, grant the following permission to the existing Kyvos Service Account in the project where the network resides: `compute.subnetworks.use`
Cross-Project Bucket Access	If the storage bucket is located in a different GCP project, grant the following permissions on the bucket: storage.object.list storage.object.get
Cluster Status Function – Offline Scheduling	Grant `roles/run.invoker` to the Cluster Status Function. Use the following command: `gcloud functions add-invoker-policy-binding kyvos-clusterstatusfunction-23081 --project=projectId --region=region --member="allUsers"`
Cloud SQL	To configure and use Cloud SQL for Kyvos deployment, the existing Kyvos Service Account must have the following permissions: `cloudsql.instances.list` `cloudsql.instances.get` `cloudsql.instances.connect`
Using an Existing VPC	If you're using an existing VPC, ensure the following: Configure an inbound firewall rule to allow TCP traffic on port `5432`. Enable Private Service Access for the VPC. For configuration details, refer to the Google Cloud Documentation. Assign the required IAM roles to the user account: Compute Network Admin
Dedicated Compute Cluster	Add these permissions to the existing Kyvos Service Account. `compute.instanceGroups.list` `compute.instanceGroups.get` `compute.instanceGroupManagers.get` `compute.instanceGroupManagers.update` Create the Dedicated Compute Cluster using kyvosparams.tfvars (available in GCP Installation files). For more details, see Working with Dedicated Compute Cluster
Node Scaling Permissions	Add these permissions to the existing Kyvos Service Account. compute.instanceGroups.get compute.instanceGroups.update compute.instances.create compute.instances.delete compute.instances.use compute.instances.setServiceAccount compute.instances.attachDisk compute.instances.detachDisk compute.disks.create compute.disks.use compute.disks.delete compute.subnetworks.use compute.healthChecks.get compute.regionHealthChecks.get compute.regionBackendServices.get compute.regionBackendServices.list compute.healthChecks.update compute.regionHealthChecks.update

7.4 CMK and BYOK deployment prerequisites for Google Cloud

This section outlines the prerequisites for enabling Customer Managed Key (CMK) or Bring Your Own Key (BYOK) encryption for Kyvos deployments on GCP.

Service Account and IAM Requirements

Requirement	Description

Requirement

Description

Existing service account roles

Assign these predefined roles to the Kyvos service account:

Cloud KMS CryptoKey Decrypter
Cloud KMS CryptoKey Encrypter
Cloud KMS CryptoKey Encrypter/Decrypter

Key/keyring destruction

Grant the Cloud KMS Admin role to the logged-in user account to destroy keys and keyrings via ./deploy.sh destroy

7.4.1 Encryption Coverage

Encryption applies to the following components:

Disk
Cloud Storage
Secret Manager

7.4.2 Google Cloud KMS Requirements

The service agent must exist in the project where Cloud Storage and Secret Manager are created (see Google's documentation)
The Cloud Key Management Service (KMS) API must be enabled in the project prior to deployment
The existing CMK must be in the same region as the deployment
The existing CMK location must be regional — global keys aren't supported by GCS buckets (see Google's documentation)

7.4.3 BYOK Requirements

To use Bring Your Own Key (BYOK):

The service agent must exist in the project where Cloud Storage and Secret Manager are created (see Google's documentation)

8. GCP Project Setup Prerequisites

Before deploying, complete the following Google Cloud project configuration steps.

8.1 Enable Project Billing

Google Cloud requires a billing account linked to the project before you can use most paid infrastructure services. Even if the resources you use fall within free-tier limits, billing must often still be enabled to activate them.

8.2 Enable Compute Engine API

Provides access to virtual machines and other Compute Engine infrastructure. Your deployment may create or manage VMs, disks, networking, and related resources.

8.3 Enable Cloud KMS API

Cloud KMS manages encryption keys. The deployment may use customer-managed encryption keys (CMEK) to encrypt data or resources.

8.4 Enable Cloud Resource Manager API

Allows deployment tools to inspect and manage projects, folders, organizations, IAM-related project metadata, and the resource hierarchy.

8.5 Enable Additional Required APIs

Enable the following APIs on your project:

Cloud Functions
Cloud Build
Cloud Scheduler

8.6 Create an App Engine Application

App Engine provides the application runtime environment. The deployment process expects an App Engine application to already exist in a selected region.