SupportConsoleDevelopersStart a trialContact

Chapter 2. Configuring a GCP project

Before you can install OpenShift Container Platform, you must configure a Google Cloud Platform (GCP) project to host it.

2.1. Creating a GCP project

To install OpenShift Container Platform, you must create a project in your Google Cloud Platform (GCP) account to host the cluster.

Procedure

  • Create a project to host your OpenShift Container Platform cluster. See Creating and Managing Projects in the GCP documentation.

    Important

    Your GCP project must use the Premium Network Service Tier if you are using installer-provisioned infrastructure. The Standard Network Service Tier is not supported for clusters installed using the installation program. The installation program configures internal load balancing for the api-int.<cluster_name>.<base_domain> URL; the Premium Tier is required for internal load balancing.

2.2. Enabling API services in GCP

Your Google Cloud Platform (GCP) project requires access to several API services to complete OpenShift Container Platform installation.

Prerequisites

  • You created a project to host your cluster.

Procedure

  • Enable the following required API services in the project that hosts your cluster. You may also enable optional API services which are not required for installation. See Enabling services in the GCP documentation.

    Table 2.1. Required API services
    API serviceConsole service name

    Compute Engine API

    compute.googleapis.com

    Cloud Resource Manager API

    cloudresourcemanager.googleapis.com

    Google DNS API

    dns.googleapis.com

    IAM Service Account Credentials API

    iamcredentials.googleapis.com

    Identity and Access Management (IAM) API

    iam.googleapis.com

    Service Usage API

    serviceusage.googleapis.com

    Table 2.2. Optional API services
    API serviceConsole service name

    Google Cloud APIs

    cloudapis.googleapis.com

    Service Management API

    servicemanagement.googleapis.com

    Google Cloud Storage JSON API

    storage-api.googleapis.com

    Cloud Storage

    storage-component.googleapis.com

2.3. Configuring DNS for GCP

To install OpenShift Container Platform, the Google Cloud Platform (GCP) account you use must have a dedicated public hosted zone in the same project that you host the OpenShift Container Platform cluster. This zone must be authoritative for the domain. The DNS service provides cluster DNS resolution and name lookup for external connections to the cluster.

Procedure

  1. Identify your domain, or subdomain, and registrar. You can transfer an existing domain and registrar or obtain a new one through GCP or another source.

    Note

    If you purchase a new domain, it can take time for the relevant DNS changes to propagate. For more information about purchasing domains through Google, see Google Domains.

  2. Create a public hosted zone for your domain or subdomain in your GCP project. See Creating public zones in the GCP documentation.

    Use an appropriate root domain, such as openshiftcorp.com, or subdomain, such as clusters.openshiftcorp.com.

  3. Extract the new authoritative name servers from the hosted zone records. See Look up your Cloud DNS name servers in the GCP documentation.

    You typically have four name servers.

  4. Update the registrar records for the name servers that your domain uses. For example, if you registered your domain to Google Domains, see the following topic in the Google Domains Help: How to switch to custom name servers.
  5. If you migrated your root domain to Google Cloud DNS, migrate your DNS records. See Migrating to Cloud DNS in the GCP documentation.
  6. If you use a subdomain, follow your company’s procedures to add its delegation records to the parent domain. This process might include a request to your company’s IT department or the division that controls the root domain and DNS services for your company.

2.4. GCP account limits

The OpenShift Container Platform cluster uses a number of Google Cloud Platform (GCP) components, but the default Quotas do not affect your ability to install a default OpenShift Container Platform cluster.

A default cluster, which contains three compute and three control plane machines, uses the following resources. Note that some resources are required only during the bootstrap process and are removed after the cluster deploys.

Table 2.3. GCP resources used in a default cluster
ServiceComponentLocationTotal resources requiredResources removed after bootstrap

Service account

IAM

Global

6

1

Firewall rules

Compute

Global

11

1

Forwarding rules

Compute

Global

2

0

In-use global IP addresses

Compute

Global

4

1

Health checks

Compute

Global

3

0

Images

Compute

Global

1

0

Networks

Compute

Global

2

0

Static IP addresses

Compute

Region

4

1

Routers

Compute

Global

1

0

Routes

Compute

Global

2

0

Subnetworks

Compute

Global

2

0

Target pools

Compute

Global

3

0

CPUs

Compute

Region

28

4

Persistent disk SSD (GB)

Compute

Region

896

128

Note

If any of the quotas are insufficient during installation, the installation program displays an error that states both which quota was exceeded and the region.

Be sure to consider your actual cluster size, planned cluster growth, and any usage from other clusters that are associated with your account. The CPU, static IP addresses, and persistent disk SSD (storage) quotas are the ones that are most likely to be insufficient.

If you plan to deploy your cluster in one of the following regions, you will exceed the maximum storage quota and are likely to exceed the CPU quota limit:

  • asia-east2
  • asia-northeast2
  • asia-south1
  • australia-southeast1
  • europe-north1
  • europe-west2
  • europe-west3
  • europe-west6
  • northamerica-northeast1
  • southamerica-east1
  • us-west2

You can increase resource quotas from the GCP console, but you might need to file a support ticket. Be sure to plan your cluster size early so that you can allow time to resolve the support ticket before you install your OpenShift Container Platform cluster.

2.5. Creating a service account in GCP

OpenShift Container Platform requires a Google Cloud Platform (GCP) service account that provides authentication and authorization to access data in the Google APIs. If you do not have an existing IAM service account that contains the required roles in your project, you must create one.

Prerequisites

  • You created a project to host your cluster.

Procedure

  1. Create a service account in the project that you use to host your OpenShift Container Platform cluster. See Creating a service account in the GCP documentation.

  2. Grant the service account the appropriate permissions. You can either grant the individual permissions that follow or assign the Owner role to it. See Granting roles to a service account for specific resources.

    Note

    While making the service account an owner of the project is the easiest way to gain the required permissions, it means that service account has complete control over the project. You must determine if the risk that comes from offering that power is acceptable.

  3. You can create the service account key in JSON format, or attach the service account to a GCP virtual machine. See Creating service account keys and Creating and enabling service accounts for instances in the GCP documentation.

    You must have a service account key or a virtual machine with an attached service account to create the cluster.

    Note

    If you use a virtual machine with an attached service account to create your cluster, you must set credentialsMode: Manual in the install-config.yaml file before installation.

Additional resources

2.5.1. Required GCP roles

When you attach the Owner role to the service account that you create, you grant that service account all permissions, including those that are required to install OpenShift Container Platform. If the security policies for your organization require a more restrictive set of permissions, you can create a service account with the following permissions.

Important

If you configure the Cloud Credential Operator to operate in passthrough mode, you must use roles rather than granular permissions.

If you deploy your cluster into an existing virtual private cloud (VPC), the service account does not require certain networking permissions, which are noted in the following lists:

Required roles for the installation program

  • Compute Admin
  • IAM Security Admin
  • Service Account Admin
  • Service Account Key Admin
  • Service Account User
  • Storage Admin

Required roles for creating network resources during installation

  • DNS Administrator

Required roles for using passthrough credentials mode

  • Compute Load Balancer Admin
  • IAM Role Viewer

The roles are applied to the service accounts that the control plane and compute machines use:

Table 2.4. GCP service account permissions
AccountRoles

Control Plane

roles/compute.instanceAdmin

roles/compute.networkAdmin

roles/compute.securityAdmin

roles/storage.admin

roles/iam.serviceAccountUser

Compute

roles/compute.viewer

roles/storage.admin

2.5.2. Required GCP permissions for installer-provisioned infrastructure

When you attach the Owner role to the service account that you create, you grant that service account all permissions, including those that are required to install OpenShift Container Platform.

If the security policies for your organization require a more restrictive set of permissions, you can create custom roles with the necessary permissions. The following permissions are required for the installer-provisioned infrastructure for creating and deleting the OpenShift Container Platform cluster.

Important

If you configure the Cloud Credential Operator to operate in passthrough mode, you must use roles rather than granular permissions. For more information, see "Required roles for using passthrough credentials mode" in the "Required GCP roles" section.

Example 2.1. Required permissions for creating network resources

  • compute.addresses.create
  • compute.addresses.createInternal
  • compute.addresses.delete
  • compute.addresses.get
  • compute.addresses.list
  • compute.addresses.use
  • compute.addresses.useInternal
  • compute.firewalls.create
  • compute.firewalls.delete
  • compute.firewalls.get
  • compute.firewalls.list
  • compute.forwardingRules.create
  • compute.forwardingRules.get
  • compute.forwardingRules.list
  • compute.forwardingRules.setLabels
  • compute.networks.create
  • compute.networks.get
  • compute.networks.list
  • compute.networks.updatePolicy
  • compute.routers.create
  • compute.routers.get
  • compute.routers.list
  • compute.routers.update
  • compute.routes.list
  • compute.subnetworks.create
  • compute.subnetworks.get
  • compute.subnetworks.list
  • compute.subnetworks.use
  • compute.subnetworks.useExternalIp

Example 2.2. Required permissions for creating load balancer resources

  • compute.regionBackendServices.create
  • compute.regionBackendServices.get
  • compute.regionBackendServices.list
  • compute.regionBackendServices.update
  • compute.regionBackendServices.use
  • compute.targetPools.addInstance
  • compute.targetPools.create
  • compute.targetPools.get
  • compute.targetPools.list
  • compute.targetPools.removeInstance
  • compute.targetPools.use

Example 2.3. Required permissions for creating DNS resources

  • dns.changes.create
  • dns.changes.get
  • dns.managedZones.create
  • dns.managedZones.get
  • dns.managedZones.list
  • dns.networks.bindPrivateDNSZone
  • dns.resourceRecordSets.create
  • dns.resourceRecordSets.list

Example 2.4. Required permissions for creating Service Account resources

  • iam.serviceAccountKeys.create
  • iam.serviceAccountKeys.delete
  • iam.serviceAccountKeys.get
  • iam.serviceAccountKeys.list
  • iam.serviceAccounts.actAs
  • iam.serviceAccounts.create
  • iam.serviceAccounts.delete
  • iam.serviceAccounts.get
  • iam.serviceAccounts.list
  • resourcemanager.projects.get
  • resourcemanager.projects.getIamPolicy
  • resourcemanager.projects.setIamPolicy

Example 2.5. Required permissions for creating compute resources

  • compute.disks.create
  • compute.disks.get
  • compute.disks.list
  • compute.instanceGroups.create
  • compute.instanceGroups.delete
  • compute.instanceGroups.get
  • compute.instanceGroups.list
  • compute.instanceGroups.update
  • compute.instanceGroups.use
  • compute.instances.create
  • compute.instances.delete
  • compute.instances.get
  • compute.instances.list
  • compute.instances.setLabels
  • compute.instances.setMetadata
  • compute.instances.setServiceAccount
  • compute.instances.setTags
  • compute.instances.use
  • compute.machineTypes.get
  • compute.machineTypes.list

Example 2.6. Required for creating storage resources

  • storage.buckets.create
  • storage.buckets.delete
  • storage.buckets.get
  • storage.buckets.list
  • storage.objects.create
  • storage.objects.delete
  • storage.objects.get
  • storage.objects.list

Example 2.7. Required permissions for creating health check resources

  • compute.healthChecks.create
  • compute.healthChecks.get
  • compute.healthChecks.list
  • compute.healthChecks.useReadOnly
  • compute.httpHealthChecks.create
  • compute.httpHealthChecks.get
  • compute.httpHealthChecks.list
  • compute.httpHealthChecks.useReadOnly

Example 2.8. Required permissions to get GCP zone and region related information

  • compute.globalOperations.get
  • compute.regionOperations.get
  • compute.regions.list
  • compute.zoneOperations.get
  • compute.zones.get
  • compute.zones.list

Example 2.9. Required permissions for checking services and quotas

  • monitoring.timeSeries.list
  • serviceusage.quotas.get
  • serviceusage.services.list

Example 2.10. Required IAM permissions for installation

  • iam.roles.get

Example 2.11. Optional Images permissions for installation

  • compute.images.list

Example 2.12. Optional permission for running gather bootstrap

  • compute.instances.getSerialPortOutput

Example 2.13. Required permissions for deleting network resources

  • compute.addresses.delete
  • compute.addresses.deleteInternal
  • compute.addresses.list
  • compute.firewalls.delete
  • compute.firewalls.list
  • compute.forwardingRules.delete
  • compute.forwardingRules.list
  • compute.networks.delete
  • compute.networks.list
  • compute.networks.updatePolicy
  • compute.routers.delete
  • compute.routers.list
  • compute.routes.list
  • compute.subnetworks.delete
  • compute.subnetworks.list

Example 2.14. Required permissions for deleting load balancer resources

  • compute.regionBackendServices.delete
  • compute.regionBackendServices.list
  • compute.targetPools.delete
  • compute.targetPools.list

Example 2.15. Required permissions for deleting DNS resources

  • dns.changes.create
  • dns.managedZones.delete
  • dns.managedZones.get
  • dns.managedZones.list
  • dns.resourceRecordSets.delete
  • dns.resourceRecordSets.list

Example 2.16. Required permissions for deleting Service Account resources

  • iam.serviceAccounts.delete
  • iam.serviceAccounts.get
  • iam.serviceAccounts.list
  • resourcemanager.projects.getIamPolicy
  • resourcemanager.projects.setIamPolicy

Example 2.17. Required permissions for deleting compute resources

  • compute.disks.delete
  • compute.disks.list
  • compute.instanceGroups.delete
  • compute.instanceGroups.list
  • compute.instances.delete
  • compute.instances.list
  • compute.instances.stop
  • compute.machineTypes.list

Example 2.18. Required for deleting storage resources

  • storage.buckets.delete
  • storage.buckets.getIamPolicy
  • storage.buckets.list
  • storage.objects.delete
  • storage.objects.list

Example 2.19. Required permissions for deleting health check resources

  • compute.healthChecks.delete
  • compute.healthChecks.list
  • compute.httpHealthChecks.delete
  • compute.httpHealthChecks.list

Example 2.20. Required Images permissions for deletion

  • compute.images.list

2.5.3. Required GCP permissions for shared VPC installations

When you are installing a cluster to a shared VPC, you must configure the service account for both the host project and the service project. If you are not installing to a shared VPC, you can skip this section.

You must apply the minimum roles required for a standard installation as listed above, to the service project.

Important

You can use granular permissions for a Cloud Credential Operator that operates in either manual or mint credentials mode. You cannot use granular permissions in passthrough credentials mode.

Ensure that the host project applies one of the following configurations to the service account:

Example 2.21. Required permissions for creating firewalls in the host project

  • projects/<host-project>/roles/dns.networks.bindPrivateDNSZone
  • roles/compute.networkAdmin
  • roles/compute.securityAdmin

Example 2.22. Required minimal permissions

  • projects/<host-project>/roles/dns.networks.bindPrivateDNSZone
  • roles/compute.networkUser

2.6. Supported GCP regions

You can deploy an OpenShift Container Platform cluster to the following Google Cloud Platform (GCP) regions:

  • asia-east1 (Changhua County, Taiwan)
  • asia-east2 (Hong Kong)
  • asia-northeast1 (Tokyo, Japan)
  • asia-northeast2 (Osaka, Japan)
  • asia-northeast3 (Seoul, South Korea)
  • asia-south1 (Mumbai, India)
  • asia-south2 (Delhi, India)
  • asia-southeast1 (Jurong West, Singapore)
  • asia-southeast2 (Jakarta, Indonesia)
  • australia-southeast1 (Sydney, Australia)
  • australia-southeast2 (Melbourne, Australia)
  • europe-central2 (Warsaw, Poland)
  • europe-north1 (Hamina, Finland)
  • europe-southwest1 (Madrid, Spain)
  • europe-west1 (St. Ghislain, Belgium)
  • europe-west2 (London, England, UK)
  • europe-west3 (Frankfurt, Germany)
  • europe-west4 (Eemshaven, Netherlands)
  • europe-west6 (Zürich, Switzerland)
  • europe-west8 (Milan, Italy)
  • europe-west9 (Paris, France)
  • europe-west12 (Turin, Italy)
  • me-central1 (Doha, Qatar, Middle East)
  • me-west1 (Tel Aviv, Israel)
  • northamerica-northeast1 (Montréal, Québec, Canada)
  • northamerica-northeast2 (Toronto, Ontario, Canada)
  • southamerica-east1 (São Paulo, Brazil)
  • southamerica-west1 (Santiago, Chile)
  • us-central1 (Council Bluffs, Iowa, USA)
  • us-east1 (Moncks Corner, South Carolina, USA)
  • us-east4 (Ashburn, Northern Virginia, USA)
  • us-east5 (Columbus, Ohio)
  • us-south1 (Dallas, Texas)
  • us-west1 (The Dalles, Oregon, USA)
  • us-west2 (Los Angeles, California, USA)
  • us-west3 (Salt Lake City, Utah, USA)
  • us-west4 (Las Vegas, Nevada, USA)
Note

To determine which machine type instances are available by region and zone, see the Google documentation.

2.7. Next steps

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.