To deploy nodes

Prepare your cloud for deploying YugabyteDB universe nodes

For YugabyteDB Anywhere (YBA) to be able to deploy and manage YugabyteDB clusters, you need to provide YBA with privileges on your cloud infrastructure to create, delete, and modify VMs, mount and unmount disk volumes, and so on. The more permissions that you can provide, the more YBA can automate.

If you can't provide YBA with the necessary permissions, you can still deploy to GCP using an on-premises provider.

GCP

The Compute Admin role permission is required on the GCP service account where you will deploy:

roles/compute.admin

To grant the required access, you must do the following:

Create a service account in GCP.
Grant the required roles to the account.

Then use one of the following methods:

Obtain a file containing a JSON that describes the service account credentials. You will need to provide this file later when creating the GCP provider configuration.
Attach the service account to the GCP VM that will run YBA.

Save for later	To configure
Service account JSON	GCP provider configuration

Managing SSH keys for VMs

When creating VMs on the public cloud, YugabyteDB requires SSH keys to access the VM. You can manage the SSH keys for VMs in two ways:

YBA managed keys. When YBA creates VMs, it will generate and manage the SSH key pair.
Provide a custom key pair. Create your own custom SSH keys and upload the SSH keys when you create the provider.

If you will be using your own custom SSH keys, then ensure that you have them when installing YBA and creating your public cloud provider.

Save for later	To configure
Custom SSH keys	GCP provider configuration

GKE service account-based IAM (GCP IAM)

Google Kubernetes Engine (GKE) uses a concept known as "Workload Identity" to provide a secure way to allow a Kubernetes service account (KSA) in your GKE cluster to act as an IAM service account so that your Kubernetes universes can access GCS for backups.

In GKE, each pod can be associated with a KSA. The KSA is used to authenticate and authorize the pod to interact with other Google Cloud services. An IAM service account is a Google Cloud resource that allows applications to make authorized calls to Google Cloud APIs.

Workload Identity links a KSA to an IAM account using annotations in the KSA. Pods that use the configured KSA automatically authenticate as the IAM service account when accessing Google Cloud APIs.

By using Workload Identity, you avoid the need for manually managing service account keys or tokens in your applications running on GKE. This approach enhances security and simplifies the management of credentials.

To enable GCP IAM when installing YugabyteDB Anywhere on Kubernetes, refer to Enable GKE service account-based IAM.
To enable GCP IAM during universe creation on Kubernetes, refer to Configure Helm overrides.
To enable GCP IAM for Google Cloud Storage backup configuration with Kubernetes, refer to Configure backup storage.
To upgrade an existing universe with GCP IAM, refer to Upgrade universes for GKE service account-based IAM support.

Prerequisites

The GKE cluster hosting the pods should have Workload Identity enabled. The worker nodes of this GKE cluster should have the GKE metadata server enabled.
The IAM service account, which is used to annotate the KSA, should have sufficient permissions to read, write, list, and delete objects in GCS.
The KSA, which is annotated with the IAM service account, should be present in the same namespace where the pod resources for YugabyteDB Anywhere and YugabyteDB universes are expected. If you have multiple namespaces, each namespace should include the annotated KSA.

For instructions on setting up Workload Identity, see Use Workload Identity in the GKE documentation.