// Module included in the following assemblies:
//
// * osd_gcp_clusters/osd-creating-a-cluster-on-gcp-with-workload-identity-federation.adoc


:_mod-docs-content-type: PROCEDURE
[id="create-wif-cluster-ocm_{context}"]
= Creating a Workload Identity Federation cluster using {cluster-manager}

[role="_abstract"]
Follow the steps in this procedure to create an {product-title} cluster on {gcp-full} using Workload Identity Federation (WIF) for authentication through the {cluster-manager} web console

.Prerequisites

* You have created a WIF configuration. For more information, see "Creating a Workload Identity Federation configuration".
* You have access to the {cluster-manager} web console. For more information, see _Accessing {cluster-manager}_ in the _Additional resources_ section.

.Procedure

. Log in to {cluster-manager-url} and click *Create cluster* on the {product-title} card.

. Under *Billing model*, configure the subscription type and infrastructure type.

.. Select a subscription type. For information about {product-title} subscription options, see link:https://access.redhat.com/documentation/en-us/openshift_cluster_manager/1-latest/html-single/managing_clusters/index#assembly-cluster-subscriptions[Cluster subscriptions and registration] in the {cluster-manager} documentation.
+

.. Select the *Customer cloud subscription* infrastructure type.

.. Click *Next*.
. Select *Run on {gcp-full}*.
. Select *Workload Identity Federation* as the Authentication type.
//Add back in default authentication type when feature goes live.
+
[NOTE]
====
Workload Identity Federation (WIF) is {gcp-full}'s recommended method of authentication for {product-title} installation. It greatly improves a cluster's resilience by using short-lived, least-privilege credentials and eliminates the need for static service account keys.
====
+
.. Read and complete all the required prerequisites.

.. Click the checkbox indicating that you have read and completed all the required prerequisites.
. Select a configured WIF configuration from the *WIF configuration* drop-down list.
. Click *Next*.
. On the *Details* page, provide a name for your cluster and specify the cluster details:
.. In the *Cluster name* field, enter a name for your cluster.
.. Optional: Cluster creation generates a domain prefix as a subdomain for your provisioned cluster on `openshiftapps.com`. If the cluster name is less than or equal to 15 characters, that name is used for the domain prefix. If the cluster name is longer than 15 characters, the domain prefix is randomly generated as a 15-character string.
+
To customize the subdomain prefix, select the *Create custom domain prefix* checkbox, and enter your domain prefix name in the *Domain prefix* field. The domain prefix cannot be longer than 15 characters, must be unique within your organization, and cannot be changed after cluster creation. If you plan to install the cluster into a Shared VPC and select a managed DNS zone in a later step, the *DNS Zone* list is filtered to show only zones that begin with this domain prefix; ensure the prefix matches the managed DNS zones you have created or intend to use.
.. Select a cluster version from the *Version* drop-down menu.
+
[NOTE]
====
Workload Identity Federation (WIF) is only supported on {product-title} version 4.17 and later.
====
+
.. Select a channel from the *Channel* drop-down menu.
+
--
include::snippets/rosa-osd-channel-group-options.adoc[]
--
+
.. Select a cloud provider region from the *Region* drop-down menu.
.. Select a *Single zone* or *Multi-zone* configuration.
+
.. Optional: Select *Enable Secure Boot support for Shielded VMs* to use Shielded VMs when installing your cluster. Once you create your cluster, the *Enable Secure Boot support for Shielded VMs* setting cannot be changed. For more information, see link:https://cloud.google.com/security/products/shielded-vm[Shielded VMs].
+
[IMPORTANT]
====
To successfully create a cluster, you must select *Enable Secure Boot support for Shielded VMs* if your organization has the policy constraint `constraints/compute.requireShieldedVm` enabled. For more information regarding {gcp-short} organizational policy constraints, see link:https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints[Organization policy constraints].
====
+
[IMPORTANT]
====
*Enable Secure Boot support for Shielded VMs* is not supported for {product-title} on {GCP} clusters created using bare-metal instance types. For more information, see link:https://cloud.google.com/compute/shielded-vm/docs/shielded-vm#limitations[Limitations] in the {gcp-full} documentation.
====
+
.. Leave *Enable user workload monitoring* selected to monitor your own projects in isolation from Red Hat Site Reliability Engineer (SRE) platform metrics. This option is enabled by default.

. Optional: Expand *Advanced Encryption* to make changes to encryption settings.

.. Select *Use custom KMS keys* to use custom KMS keys. If you prefer not to use custom KMS keys, leave the default setting *Use default KMS Keys*.

.. With *Use Custom KMS keys* selected:

... Select a key ring location from the *Key ring location* drop-down menu.
... Select a key ring from the *Key ring* drop-down menu.
... Select a key name from the *Key name* drop-down menu.
... Provide the *KMS Service Account*.

.. Optional: Select *Enable FIPS cryptography* if you require your cluster to be FIPS validated.
+
[NOTE]
====
If *Enable FIPS cryptography* is selected, *Enable additional etcd encryption* is enabled by default and cannot be disabled. You can select *Enable additional etcd encryption* without selecting *Enable FIPS cryptography*.
====
+
.. Optional: Select *Enable additional etcd encryption* if you require etcd key value encryption.
With this option, the etcd key values are encrypted, but not the keys. This option is in addition to the control plane storage encryption that encrypts the etcd volumes in {product-title} clusters by default.
+
[NOTE]
====
By enabling etcd encryption for the key values in etcd, you incur a performance overhead of approximately 20%. The overhead is a result of introducing this second layer of encryption, in addition to the default control plane storage encryption that encrypts the etcd volumes. Consider enabling etcd encryption only if you specifically require it for your use case.
====
+
. Click *Next*.

. On the *Machine pool* page, select a *Compute node instance type* and a *Compute node count*. The number and types of nodes that are available depend on your {product-title} subscription. If you are using multiple availability zones, the compute node count is per zone.

. Optional: Expand *Add node labels* to add labels to your nodes. Click *Add additional label* to add more node labels.
+
[IMPORTANT]
====
This step refers to labels within Kubernetes, not {gcp-full}. For more information regarding Kubernetes labels, see link:https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/[Labels and Selectors].
====
+
. Click *Next*.

. In the *Cluster privacy* dialog, select *Public* or *Private* to use either public or private API endpoints and application routes for your cluster. If you select *Private*, *Use Private Service Connect* is selected by default, and cannot be disabled. Private Service Connect (PSC) is {gcp-full}’s security-enhanced networking feature.

. Optional: To install the cluster in an existing {gcp-short} Virtual Private Cloud (VPC):
.. Select *Install into an existing VPC*.
+
[IMPORTANT]
====
Private Service Connect is supported only with *Install into an existing VPC*.
====
+
.. If you are installing into an existing VPC and you want to enable an HTTP or HTTPS proxy for your cluster, select *Configure a cluster-wide proxy*.
+
. Accept the default application ingress settings, or to create your own custom settings, select *Custom Settings*. All of the custom settings are optional.
.. In *Route selector*, enter a comma-separated list of `key=value` pairs to limit which routes this ingress exposes.
Leave the field empty if all routes should remain eligible based on your other choices.
.. In *Excluded namespaces*, enter a comma-separated list of namespace names whose routes must not use this ingress.
.. In *Exclude namespace selectors*, specify one or more label selectors. For each selector, provide a label key and a comma-separated list of label values. The default Ingress Controller does not apply to namespaces whose labels satisfy any of the configured selectors.
+
[IMPORTANT]
====
Do not include spaces around commas, for example, use `finance,HR,legal`, and not `finance, HR, legal`.
====
+
.. Set *Namespace ownership policy* for route admission when namespaces share hostnames, for example, select *Strict* for restrictive admission.
.. Set *Wildcard policy* to allow or disallow wildcard patterns in route hostnames, for example, select *Disallowed* to block wildcard host routes.
+
For more information about custom application ingress settings, click on the information icon provided for each setting.

. Click *Next*.

. Optional: To install the cluster into a {gcp-short} Shared VPC, follow these steps.
+
--
include::snippets/snip_install-cluster-in-vpc.adoc[]
--
.. Select *Install into {gcp-short} Shared VPC*.
.. Specify the *Host project ID*. If the specified host project ID is incorrect, cluster creation fails.
+
[NOTE]
====
In a typical Shared VPC deployment, the following {gcp-short} roles are required on the project hosting the VPC:

* `roles/compute.networkAdmin`
* `roles/compute.securityAdmin`
* `roles/dns.admin`

If you use a managed DNS zone (by selecting a zone from the *DNS Zone* list), the `roles/dns.admin` role is not required on the host project.
====
+
.. Optional. To use a pre-created DNS zone and reduce host project permissions, complete the following actions:
... View the provided CLI command instructions to create a zone if you have not already done so. For more information about creating a DNS zone using the ocm CLI, see _Creating a managed DNS zone_ in the _Additional resources_ section.
... Click the **Refresh** button to update the list of available zones.
... Select your preferred zone from the **DNS Zone** list. The list displays the zone ID alongside the {GCP} project and managed zone ID for easy identification.
+
[NOTE]
====
A custom domain prefix must be specified on a previous step  on the *Details* page before zones appear in the *DNS Zone* list. The *DNS Zone* list is filtered to show only zones that begin with the domain prefix you specified. The list may be empty if no matching DNS zones exist, or if the domain prefix was entered incorrectly. If the list is empty, verify your domain prefix and ensure you have created a managed DNS zone with a matching prefix.
====
+
If no zone is selected, the installer will attempt to create one automatically, which requires higher-level permissions in the host project.

+
. If you opted to install the cluster in an existing {GCP} VPC, provide your VPC subnet settings and select *Next*. You must ensure that your VPC is configured to allow outbound internet access to the domains required for the {product-title} service. This outbound access is required for the {product-title} service to communicate with Red{nbsp}Hat's management plane and SRE tooling via secure and encrypted endpoints over the public internet.
+
[NOTE]
====
If you are installing a cluster into a Shared VPC, the VPC name and subnets are shared from the host project.
====
. Click *Next*.
. If you opted to configure a cluster-wide proxy, provide your proxy configuration details on the *Cluster-wide proxy* page:
+
.. Enter a value in at least one of the following fields:
** Specify a valid *HTTP proxy URL*.
** Specify a valid *HTTPS proxy URL*.
** In the *Additional trust bundle* field, provide a PEM encoded X.509 certificate bundle. The bundle is added to the trusted certificate store for the cluster nodes. An additional trust bundle file is required if you use a TLS-inspecting proxy unless the identity certificate for the proxy is signed by an authority from the {op-system-first} trust bundle. This requirement applies regardless of whether the proxy is transparent or requires explicit configuration using the `http-proxy` and `https-proxy` arguments.
+
.. Click *Next*.
+
For more information about configuring a proxy with {product-title}, see _Configuring a cluster-wide proxy_.

. Accept the default application ingress settings, or to create your own custom settings, select *Custom Settings*. All of the custom settings are optional.
.. In *Route selector*, enter a comma-separated list of `key=value` pairs to limit which routes this ingress exposes.
Leave the field empty if all routes should remain eligible based on your other choices.
.. In *Excluded namespaces*, enter a comma-separated list of namespace names whose routes must not use this ingress.
.. In *Exclude namespace selectors*, specify one or more label selectors. For each selector, provide a label key and a comma-separated list of label values. The default Ingress Controller does not apply to namespaces whose labels satisfy any of the configured selectors.
+
[IMPORTANT]
====
Do not include spaces around commas, for example, use `finance,HR,legal`, and not `finance, HR, legal`.
====
+
.. Set *Namespace ownership policy* for route admission when namespaces share hostnames, for example, select *Strict* for restrictive admission.
.. Set *Wildcard policy* to allow or disallow wildcard patterns in route hostnames, for example, select *Disallowed* to block wildcard host routes.
+
For more information about custom application ingress settings, click the information icon provided for each setting.

. In the *CIDR ranges* dialog, configure custom classless inter-domain routing (CIDR) ranges or use the defaults that are provided.
+
[IMPORTANT]
====
CIDR configurations cannot be changed later. Confirm your selections with your network administrator before proceeding.

If the cluster privacy is set to *Private*, you cannot access your cluster until you configure private connections in your cloud provider.
====

. On the *Cluster update strategy* page, configure your update preferences:
.. Choose a cluster update method:
** Select *Individual updates* if you want to schedule each update individually. This is the default option.
** Select *Recurring updates* to update your cluster on your preferred day and start time, when updates are available.
+
[NOTE]
====
You can review the end-of-life dates in the update lifecycle documentation for {product-title}. For more information, see link:https://docs.redhat.com/en/documentation/openshift_dedicated/4/html/introduction_to_openshift_dedicated/policies-and-service-definition#osd-life-cycle[OpenShift Dedicated update life cycle].
====
+
.. Provide administrator approval based on your cluster update method:
** Individual updates: If you select an update version that requires approval, provide an administrator’s acknowledgment and click *Approve and continue*.
** Recurring updates: If you selected recurring updates for your cluster, provide an administrator’s acknowledgment and click *Approve and continue*. {cluster-manager} does not start scheduled y-stream updates for minor versions without receiving an administrator’s acknowledgment.
+
.. If you opted for recurring updates, select a preferred day of the week and upgrade start time in UTC from the drop-down menus.
.. Optional: You can set a grace period for *Node draining* during cluster upgrades. A *1 hour* grace period is set by default.
.. Click *Next*.
+
[NOTE]
====
In the event of critical security concerns that significantly impact the security or stability of a cluster, Red Hat Site Reliability Engineering (SRE) might schedule automatic updates to the latest z-stream version that is not impacted. The updates are applied within 48 hours after customer notifications are provided. For a description of the critical impact security rating, see link:https://access.redhat.com/security/updates/classification[Understanding Red Hat security ratings].
====

. Review the summary of your selections and click *Create cluster* to start the cluster installation. The installation takes approximately 30-40 minutes to complete.
+
. Optional: On the *Overview* tab, you can enable the delete protection feature by selecting *Enable*, which is located directly under *Delete Protection: Disabled*. This will prevent your cluster from being deleted. To disable delete protection, select *Disable*.
By default, clusters are created with the delete protection feature disabled.

.Verification

* You can monitor the progress of the installation in the *Overview* page for your cluster. You can view the installation logs on the same page. Your cluster is ready when the *Status* in the *Details* section of the page is listed as *Ready*.

[IMPORTANT]
====
If your cluster deployment fails during installation, certain resources created during the installation process are not automatically removed from your {GCP} account. To remove these resources from your {gcp-short} account, you must delete the failed cluster.
====
ifeval::["{context}" == "osd-creating-a-cluster-on-aws"]
:!osd-on-aws:
endif::[]
ifeval::["{context}" == "osd-creating-a-cluster-on-gcp"]
:!osd-on-gcp:
endif::[]
