mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
445 lines
31 KiB
Plaintext
445 lines
31 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-with-customizations.adoc
|
|
|
|
:_mod-docs-content-type: PROCEDURE
|
|
[id="rosa-sts-creating-cluster-customizations-ocm_{context}"]
|
|
= Creating a cluster with customizations by using {cluster-manager}
|
|
|
|
When you create a {product-title} cluster that uses the AWS Security Token Service (STS), you can customize your installation interactively by using {cluster-manager-first}.
|
|
|
|
[IMPORTANT]
|
|
====
|
|
Only public and AWS PrivateLink clusters are supported with STS. Regular private clusters (non-PrivateLink) are not available for use with STS.
|
|
====
|
|
|
|
.Prerequisites
|
|
|
|
* You have completed the AWS prerequisites for ROSA with STS.
|
|
* You have available AWS service quotas.
|
|
* You have enabled the ROSA service in the AWS Console.
|
|
* You have installed and configured the latest ROSA CLI (`rosa`) on your installation host. Run `rosa version` to see your currently installed version of the ROSA CLI. If a newer version is available, the CLI provides a link to download this upgrade.
|
|
* You have verified that the AWS Elastic Load Balancing (ELB) service role exists in your AWS account.
|
|
* If you are configuring a cluster-wide proxy, you have verified that the proxy is accessible from the VPC that the cluster is being installed into. The proxy must also be accessible from the private subnets of the VPC.
|
|
|
|
.Procedure
|
|
|
|
. Navigate to {cluster-manager-url} and select *Create cluster*.
|
|
|
|
. On the *Create an OpenShift cluster* page, select *Create cluster* in the *{product-title} (ROSA)* row.
|
|
|
|
. If an AWS account is automatically detected, the account ID is listed in the *Associated AWS accounts* drop-down menu. If no AWS accounts are automatically detected, click *Select an account* -> *Associate AWS account* and follow these steps:
|
|
+
|
|
.. On the *Authenticate* page, click the copy button next to the `rosa login` command. The command includes your {cluster-manager} API login token.
|
|
+
|
|
[NOTE]
|
|
====
|
|
You can also load your API token on the link:https://console.redhat.com/openshift/token[OpenShift Cluster Manager API Token] page on {cluster-manager}.
|
|
====
|
|
+
|
|
.. Run the copied command in the CLI to log in to your ROSA account.
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ rosa login --token=<api_login_token> <1>
|
|
----
|
|
<1> Replace `<api_login_token>` with the token that is provided in the copied command.
|
|
+
|
|
.Example output
|
|
[source,terminal]
|
|
----
|
|
I: Logged in as '<username>' on 'https://api.openshift.com'
|
|
----
|
|
.. On the *Authenticate* page in {cluster-manager}, click *Next*.
|
|
.. On the *OCM role* page, click the copy button next to the *Basic OCM role* or the *Admin OCM role* commands.
|
|
+
|
|
The basic role enables {cluster-manager} to detect the AWS IAM roles and policies required by ROSA. The admin role also enables the detection of the roles and policies. In addition, the admin role enables automatic deployment of the cluster-specific Operator roles and the OpenID Connect (OIDC) provider by using {cluster-manager}.
|
|
.. Run the copied command in the CLI and follow the prompts to create the {cluster-manager} IAM role. The following example creates a basic {cluster-manager} IAM role using the default options:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ rosa create ocm-role
|
|
----
|
|
+
|
|
.Example output
|
|
[source,terminal]
|
|
----
|
|
I: Creating ocm role
|
|
? Role prefix: ManagedOpenShift <1>
|
|
? Enable admin capabilities for the OCM role (optional): No <2>
|
|
? Permissions boundary ARN (optional): <3>
|
|
? Role Path (optional): <4>
|
|
? Role creation mode: auto <5>
|
|
I: Creating role using 'arn:aws:iam::<aws_account_id>:user/<aws_username>'
|
|
? Create the 'ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>' role? Yes
|
|
I: Created role 'ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>' with ARN 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>'
|
|
I: Linking OCM role
|
|
? OCM Role ARN: arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>
|
|
? Link the 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>' role with organization '<red_hat_organization_id>'? Yes <6>
|
|
I: Successfully linked role-arn 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>' with organization account '<red_hat_organization_id>'
|
|
----
|
|
<1> Specify the prefix to include in the OCM IAM role name. The default is `ManagedOpenShift`. You can create only one OCM role per AWS account for your Red{nbsp}Hat organization.
|
|
<2> Enable the admin {cluster-manager} IAM role, which is equivalent to specifying the `--admin` argument. The admin role is required if you want to use *Auto* mode to automatically provision the cluster-specific Operator roles and the OIDC provider by using {cluster-manager}.
|
|
<3> Optional: Specify a permissions boundary Amazon Resource Name (ARN) for the role. For more information, see link:https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html[Permissions boundaries for IAM entities] in the AWS documentation.
|
|
<4> Specify a custom ARN path for your OCM role. The path must contain alphanumeric characters only and start and end with `/`, for example `/test/path/dev/`. For more information, see _ARN path customization for IAM roles and policies_.
|
|
<5> Select the role creation mode. You can use `auto` mode to automatically create the {cluster-manager} IAM role and link it to your Red{nbsp}Hat organization account. In `manual` mode, the ROSA CLI generates the `aws` commands needed to create and link the role. In `manual` mode, the corresponding policy JSON files are also saved to the current directory. `manual` mode enables you to review the details before running the `aws` commands manually.
|
|
<6> Link the {cluster-manager} IAM role to your Red{nbsp}Hat organization account.
|
|
.. If you opted not to link the {cluster-manager} IAM role to your Red{nbsp}Hat organization account in the preceding command, copy the `rosa link` command from the {cluster-manager} *OCM role* page and run it:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ rosa link ocm-role <arn> <1>
|
|
----
|
|
<1> Replace `<arn>` with the ARN of the {cluster-manager} IAM role that is included in the output of the preceding command.
|
|
.. Select *Next* on the {cluster-manager} *OCM role* page.
|
|
.. On the *User role* page, click the copy button for the *User role* command and run the command in the CLI. Red{nbsp}Hat uses the user role to verify your AWS identity when you install a cluster and the required resources with {cluster-manager}.
|
|
+
|
|
Follow the prompts to create the user role:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ rosa create user-role
|
|
----
|
|
+
|
|
.Example output
|
|
[source,terminal]
|
|
----
|
|
I: Creating User role
|
|
? Role prefix: ManagedOpenShift <1>
|
|
? Permissions boundary ARN (optional): <2>
|
|
? Role Path (optional): [? for help] <3>
|
|
? Role creation mode: auto <4>
|
|
I: Creating ocm user role using 'arn:aws:iam::<aws_account_id>:user/<aws_username>'
|
|
? Create the 'ManagedOpenShift-User-<red_hat_username>-Role' role? Yes
|
|
I: Created role 'ManagedOpenShift-User-<red_hat_username>-Role' with ARN 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<red_hat_username>-Role'
|
|
I: Linking User role
|
|
? User Role ARN: arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<red_hat_username>-Role
|
|
? Link the 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<red_hat_username>-Role' role with account '<red_hat_user_account_id>'? Yes <5>
|
|
I: Successfully linked role ARN 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<red_hat_username>-Role' with account '<red_hat_user_account_id>'
|
|
----
|
|
<1> Specify the prefix to include in the user role name. The default is `ManagedOpenShift`.
|
|
<2> Optional: Specify a permissions boundary Amazon Resource Name (ARN) for the role. For more information, see link:https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html[Permissions boundaries for IAM entities] in the AWS documentation.
|
|
<3> Specify a custom ARN path for your user role. The path must contain alphanumeric characters only and start and end with `/`, for example `/test/path/dev/`. For more information, see _ARN path customization for IAM roles and policies_.
|
|
<4> Select the role creation mode. You can use `auto` mode to automatically create the user role and link it to your {cluster-manager} user account. In `manual` mode, the ROSA CLI generates the `aws` commands needed to create and link the role. In `manual` mode, the corresponding policy JSON files are also saved to the current directory. `manual` mode enables you to review the details before running the `aws` commands manually.
|
|
<5> Link the user role to your {cluster-manager} user account.
|
|
.. If you opted not to link the user role to your {cluster-manager} user account in the preceding command, copy the `rosa link` command from the {cluster-manager} *User role* page and run it:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ rosa link user-role <arn> <1>
|
|
----
|
|
<1> Replace `<arn>` with the ARN of the user role that is included in the output of the preceding command.
|
|
.. On the {cluster-manager} *User role* page, click *Ok*.
|
|
.. Verify that the AWS account ID is listed in the *Associated AWS accounts* drop-down menu on the *Accounts and roles* page.
|
|
.. If the required account roles do not exist, a notification is provided stating that *Some account roles ARNs were not detected*. You can create the AWS account-wide roles and policies, including the Operator policies, by clicking the copy buffer next to the `rosa create account-roles` command and running the command in the CLI:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ rosa create account-roles
|
|
----
|
|
+
|
|
--
|
|
.Example output
|
|
[source,terminal,subs="attributes+"]
|
|
----
|
|
I: Logged in as '<red_hat_username>' on 'https://api.openshift.com'
|
|
I: Validating AWS credentials...
|
|
I: AWS credentials are valid!
|
|
I: Validating AWS quota...
|
|
I: AWS quota ok. If cluster installation fails, validate actual AWS resource usage against https://docs.openshift.com/rosa/rosa_getting_started/rosa-required-aws-service-quotas.html
|
|
I: Verifying whether OpenShift command-line tool is available...
|
|
I: Current OpenShift Client Version: {product-version}.0
|
|
I: Creating account roles
|
|
? Role prefix: ManagedOpenShift <1>
|
|
? Permissions boundary ARN (optional): <2>
|
|
? Path (optional): [? for help] <3>
|
|
? Role creation mode: auto <4>
|
|
I: Creating roles using 'arn:aws:iam::<aws_account_number>:user/<aws_username>'
|
|
? Create the 'ManagedOpenShift-Installer-Role' role? Yes <5>
|
|
I: Created role 'ManagedOpenShift-Installer-Role' with ARN 'arn:aws:iam::<aws_account_number>:role/ManagedOpenShift-Installer-Role'
|
|
? Create the 'ManagedOpenShift-ControlPlane-Role' role? Yes <5>
|
|
I: Created role 'ManagedOpenShift-ControlPlane-Role' with ARN 'arn:aws:iam::<aws_account_number>:role/ManagedOpenShift-ControlPlane-Role'
|
|
? Create the 'ManagedOpenShift-Worker-Role' role? Yes <5>
|
|
I: Created role 'ManagedOpenShift-Worker-Role' with ARN 'arn:aws:iam::<aws_account_number>:role/ManagedOpenShift-Worker-Role'
|
|
? Create the 'ManagedOpenShift-Support-Role' role? Yes <5>
|
|
I: Created role 'ManagedOpenShift-Support-Role' with ARN 'arn:aws:iam::<aws_account_number>:role/ManagedOpenShift-Support-Role'
|
|
I: To create a cluster with these roles, run the following command:
|
|
rosa create cluster --sts
|
|
----
|
|
<1> Specify the prefix to include in the {cluster-manager} IAM role name. The default is `ManagedOpenShift`.
|
|
+
|
|
[IMPORTANT]
|
|
====
|
|
You must specify an account-wide role prefix that is unique across your AWS account, even if you use a custom ARN path for your account roles.
|
|
====
|
|
+
|
|
<2> Optional: Specify a permissions boundary Amazon Resource Name (ARN) for the role. For more information, see link:https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html[Permissions boundaries for IAM entities] in the AWS documentation.
|
|
<3> Specify a custom ARN path for your account-wide roles. The path must contain alphanumeric characters only and start and end with `/`, for example `/test/path/dev/`. For more information, see _ARN path customization for IAM roles and policies_.
|
|
<4> Select the role creation mode. You can use `auto` mode to automatically create the account wide roles and policies. In `manual` mode, the ROSA CLI generates the `aws` commands needed to create the roles and policies. In `manual` mode, the corresponding policy JSON files are also saved to the current directory. `manual` mode enables you to review the details before running the `aws` commands manually.
|
|
<5> Creates the account-wide installer, control plane, worker and support roles and corresponding IAM policies. For more information, see _Account-wide IAM role and policy reference_.
|
|
+
|
|
[NOTE]
|
|
====
|
|
In this step, the ROSA CLI also automatically creates the account-wide Operator IAM policies that are used by the cluster-specific Operator policies to permit the ROSA cluster Operators to carry out core OpenShift functionality. For more information, see _Account-wide IAM role and policy reference_.
|
|
====
|
|
--
|
|
.. On the *Accounts and roles* page, click *Refresh ARNs* and verify that the installer, support, worker, and control plane account role ARNs are listed.
|
|
+
|
|
If you have more than one set of account roles in your AWS account for your cluster version, a drop-down list of *Installer role* ARNs is provided. Select the ARN for the installer role that you want to use with your cluster. The cluster uses the account-wide roles and policies that relate to the selected installer role.
|
|
|
|
. Click *Next*.
|
|
+
|
|
[NOTE]
|
|
====
|
|
If the *Accounts and roles* page was refreshed, you might need to select the checkbox again to acknowledge that you have read and completed all of the prerequisites.
|
|
====
|
|
|
|
. On the *Cluster details* page, provide a name for your cluster and specify the cluster details:
|
|
.. Add a *Cluster name*.
|
|
.. 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 to a 15 character string.
|
|
+
|
|
To customize the subdomain, 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.
|
|
.. Select a cluster version from the *Version* drop-down menu.
|
|
.. Select a channel group from the *Channel group* 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.
|
|
.. Leave *Enable user workload monitoring* selected to monitor your own projects in isolation from Red{nbsp}Hat Site Reliability Engineer (SRE) platform metrics. This option is enabled by default.
|
|
.. Optional: Expand *Advanced Encryption* to make changes to encryption settings.
|
|
... Accept the default setting *Use default KMS Keys* to use your default AWS KMS key, or select *Use Custom KMS keys* to use a custom KMS key.
|
|
.... With *Use Custom KMS keys* selected, enter the AWS Key Management Service (KMS) custom key Amazon Resource Name (ARN) ARN in the *Key ARN* field.
|
|
The key is used for encrypting all control plane, infrastructure, worker node root volumes, and persistent volumes in your cluster.
|
|
.... Optional: To create a customer managed KMS key, follow the procedure for link:https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk[Creating symmetric encryption KMS keys].
|
|
+
|
|
[IMPORTANT]
|
|
====
|
|
The EBS Operator role is required in addition to the account roles to successfully create your cluster.
|
|
|
|
This role must be attached with the `ManagedOpenShift-openshift-cluster-csi-drivers-ebs-cloud-credentials` policy, an IAM policy required by ROSA to manage back-end storage through the Container Storage Interface (CSI).
|
|
|
|
For more information about the policies and permissions that the cluster Operators require, see _Methods of account-wide role creation_.
|
|
|
|
.Example EBS Operator role
|
|
`"arn:aws:iam::<aws_account_id>:role/<cluster_name>-xxxx-openshift-cluster-csi-drivers-ebs-cloud-credent"`
|
|
|
|
After you create your Operator roles, you must edit the _Key Policy_ in the link:https://console.aws.amazon.com/kms[*Key Management Service (KMS)* page of the AWS Console] to add the roles.
|
|
====
|
|
... 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 the keys are not. 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 will 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 *Default machine pool* page, select a *Compute node instance type*.
|
|
+
|
|
[NOTE]
|
|
====
|
|
After your cluster is created, you can change the number of compute nodes in your cluster, but you cannot change the compute node instance type in the default machine pool. The number and types of nodes available to you depend on whether you use single or multiple availability zones. They also depend on what is enabled and available in your AWS account and the selected region.
|
|
====
|
|
|
|
. Optional: Configure autoscaling for the default machine pool:
|
|
.. Select *Enable autoscaling* to automatically scale the number of machines in your default machine pool to meet the deployment needs.
|
|
.. Set the minimum and maximum node count limits for autoscaling. The cluster autoscaler does not reduce or increase the default machine pool node count beyond the limits that you specify.
|
|
+
|
|
--
|
|
** If you deployed your cluster using a single availability zone, set the *Minimum node count* and *Maximum node count*. This defines the minimum and maximum compute node limits in the availability zone.
|
|
** If you deployed your cluster using multiple availability zones, set the *Minimum nodes per zone* and *Maximum nodes per zone*. This defines the minimum and maximum compute node limits per zone.
|
|
--
|
|
+
|
|
[NOTE]
|
|
====
|
|
Alternatively, you can set your autoscaling preferences for the default machine pool after the machine pool is created.
|
|
====
|
|
|
|
. If you did not enable autoscaling, select a compute node count for your default machine pool:
|
|
** If you deployed your cluster using a single availability zone, select a *Compute node count* from the drop-down menu. This defines the number of compute nodes to provision to the machine pool for the zone.
|
|
** If you deployed your cluster using multiple availability zones, select a *Compute node count (per zone)* from the drop-down menu. This defines the number of compute nodes to provision to the machine pool per zone.
|
|
|
|
. Optional: Select an EC2 Instance Metadata Service (IMDS) configuration - `optional` (default) or `required` - to enforce use of IMDSv2. For more information regarding IMDS, see link:https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html[Instance metadata and user data] in the AWS documentation.
|
|
+
|
|
ifdef::openshift-rosa[]
|
|
[IMPORTANT]
|
|
====
|
|
The Instance Metadata Service settings cannot be changed after your cluster is created.
|
|
====
|
|
endif::openshift-rosa[]
|
|
|
|
. Optional: Expand *Edit node labels* to add labels to your nodes. Click *Add label* to add more node labels and select *Next*.
|
|
|
|
. In the *Cluster privacy* section of the *Network configuration* page, select *Public* or *Private* to use either public or private API endpoints and application routes for your cluster.
|
|
+
|
|
[IMPORTANT]
|
|
====
|
|
The API endpoint cannot be changed between public and private after your cluster is created.
|
|
====
|
|
+
|
|
Public API endpoint:: Select *Public* if you do not want to restrict access to your cluster. You can access the Kubernetes API endpoint and application routes from the internet.
|
|
|
|
Private API endpoint:: Select *Private* if you want to restrict network access to your cluster. The Kubernetes API endpoint and application routes are accessible from direct private connections only.
|
|
+
|
|
[IMPORTANT]
|
|
====
|
|
If you are using private API endpoints, you cannot access your cluster until you update the network settings in your cloud provider account.
|
|
====
|
|
|
|
. Optional: If you opted to use public API endpoints, by default a new VPC is created for your cluster. If you want to install your cluster in an existing VPC instead, select *Install into an existing VPC*.
|
|
+
|
|
[WARNING]
|
|
====
|
|
You cannot install a ROSA cluster into an existing VPC that was created by the OpenShift installer. These VPCs are created during the cluster deployment process and must only be associated with a single cluster to ensure that cluster provisioning and deletion operations work correctly.
|
|
|
|
To verify whether a VPC was created by the OpenShift installer, check for the `owned` value on the `kubernetes.io/cluster/<infra-id>` tag. For example, when viewing the tags for the VPC named `mycluster-12abc-34def`, the `kubernetes.io/cluster/mycluster-12abc-34def` tag has a value of `owned`. Therefore, the VPC was created by the installer and must not be modified by the administrator.
|
|
====
|
|
+
|
|
[NOTE]
|
|
====
|
|
If you opted to use private API endpoints, you must use an existing VPC and PrivateLink and the *Install into an existing VPC* and *Use a PrivateLink* options are automatically selected. With these options, the Red{nbsp}Hat Site Reliability Engineering (SRE) team can connect to the cluster to assist with support by using only AWS PrivateLink endpoints.
|
|
====
|
|
|
|
. Optional: If you are installing your cluster into an existing VPC, select *Configure a cluster-wide proxy* to enable an HTTP or HTTPS proxy to deny direct access to the internet from your cluster.
|
|
|
|
. Click *Next*.
|
|
|
|
. If you opted to install the cluster in an existing AWS VPC, provide your *Virtual Private Cloud (VPC) subnet settings*.
|
|
+
|
|
[NOTE]
|
|
====
|
|
You must ensure that your VPC is configured with a public and a private subnet for each availability zone that you want the cluster installed into. If you opted to use PrivateLink, only private subnets are required.
|
|
====
|
|
.. Optional: Expand *Additional security groups* and select additional custom security groups to apply to nodes in the machine pools created by default. You must have already created the security groups and associated them with the VPC you selected for this cluster. You cannot add or edit security groups to the default machine pools after you create the cluster.
|
|
+
|
|
By default, the security groups you specify will be added for all node types. Uncheck the *Apply the same security groups to all node types (control plane, infrastructure and worker)* checkbox to select different security groups for each node type.
|
|
+
|
|
For more information, see the requirements for _Security groups_ under _Additional resources_.
|
|
|
|
. 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_.
|
|
|
|
. In the *CIDR ranges* dialog, configure custom classless inter-domain routing (CIDR) ranges or use the defaults that are provided and click *Next*.
|
|
+
|
|
[NOTE]
|
|
====
|
|
If you are installing into a VPC, the *Machine CIDR* range must match the VPC subnets.
|
|
====
|
|
+
|
|
[IMPORTANT]
|
|
====
|
|
CIDR configurations cannot be changed later. Confirm your selections with your network administrator before proceeding.
|
|
====
|
|
|
|
. Under the *Cluster roles and policies* page, select your preferred cluster-specific Operator IAM role and OIDC provider creation mode.
|
|
+
|
|
//With *Manual* mode, you can use either AWS CloudFormation, `rosa` CLI commands, or `aws` CLI commands to generate the required Operator roles and OIDC provider for your cluster. *Manual* mode enables you to review the details before using your preferred option to create the IAM resources manually and complete your cluster installation.
|
|
With *Manual* mode, you can use either the `rosa` CLI commands or the `aws` CLI commands to generate the required Operator roles and OIDC provider for your cluster. *Manual* mode enables you to review the details before using your preferred option to create the IAM resources manually and complete your cluster installation.
|
|
+
|
|
Alternatively, you can use *Auto* mode to automatically create the Operator roles and OIDC provider. To enable *Auto* mode, the {cluster-manager} IAM role must have administrator capabilities.
|
|
+
|
|
[NOTE]
|
|
====
|
|
If you specified custom ARN paths when you created the associated account-wide roles, the custom path is automatically detected and applied to the Operator roles. The custom ARN path is applied when the Operator roles are created by using either *Manual* or *Auto* mode.
|
|
====
|
|
|
|
. Optional: Specify a *Custom operator roles prefix* for your cluster-specific Operator IAM roles.
|
|
+
|
|
[NOTE]
|
|
====
|
|
By default, the cluster-specific Operator role names are prefixed with the cluster name and random 4-digit hash. You can optionally specify a custom prefix to replace `<cluster_name>-<hash>` in the role names. The prefix is applied when you create the cluster-specific Operator IAM roles. For information about the prefix, see _About custom Operator IAM role prefixes_.
|
|
====
|
|
|
|
. Select *Next*.
|
|
|
|
. 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.
|
|
+
|
|
[IMPORTANT]
|
|
====
|
|
Even when you opt for recurring updates, you must update the account-wide and cluster-specific IAM resources before you upgrade your cluster between minor releases.
|
|
====
|
|
+
|
|
[NOTE]
|
|
====
|
|
You can review the end-of-life dates in the update life cycle documentation for {product-title}. For more information, see _{product-title} update life cycle_.
|
|
====
|
|
+
|
|
.. 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]
|
|
====
|
|
If there are critical security concerns that significantly impact the security or stability of a cluster, Red{nbsp}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{nbsp}Hat security ratings].
|
|
====
|
|
|
|
. Review the summary of your selections and click *Create cluster* to start the cluster installation.
|
|
|
|
. If you opted to use *Manual* mode, create the cluster-specific Operator roles and OIDC provider manually to continue the installation:
|
|
+
|
|
--
|
|
//.. In the *Action required to continue installation* dialog, select either the *AWS CloudFormation*, *AWS CLI*, or *ROSA CLI* tab and manually create the resources:
|
|
.. In the *Action required to continue installation* dialog, select either the *AWS CLI* or the *ROSA CLI* tab and manually create the resources:
|
|
//** If you opted to use the *AWS CloudFormation* method, click the copy button next to the `aws cloudformation` commands and run them in the CLI.
|
|
** If you opted to use the *AWS CLI* method, click *Download .zip*, save the file, and then extract the AWS CLI command and policy files. Then, run the provided `aws` commands in the CLI.
|
|
+
|
|
[NOTE]
|
|
====
|
|
You must run the `aws` commands in the directory that contains the policy files.
|
|
====
|
|
** If you opted to use the *ROSA CLI* method, click the copy button next to the `rosa create` commands and run them in the CLI.
|
|
+
|
|
[NOTE]
|
|
====
|
|
If you specified custom ARN paths when you created the associated account-wide roles, the custom path is automatically detected and applied to the Operator roles when you create them by using these manual methods.
|
|
====
|
|
.. In the *Action required to continue installation* dialog, click *x* to return to the *Overview* page for your cluster.
|
|
.. Verify that the cluster *Status* in the *Details* section of the *Overview* page for your cluster has changed from *Waiting* to *Installing*. There might be a short delay of approximately two minutes before the status changes.
|
|
--
|
|
+
|
|
[NOTE]
|
|
====
|
|
If you opted to use *Auto* mode, {cluster-manager} creates the Operator roles and the OIDC provider automatically.
|
|
====
|
|
+
|
|
[IMPORTANT]
|
|
====
|
|
The EBS Operator role is required in addition to the account roles to successfully create your cluster.
|
|
|
|
This role must be attached with the `ManagedOpenShift-openshift-cluster-csi-drivers-ebs-cloud-credentials` policy, an IAM policy required by ROSA to manage back-end storage through the Container Storage Interface (CSI).
|
|
|
|
For more information about the policies and permissions that the cluster Operators require, see _Methods of account-wide role creation_.
|
|
|
|
.Example EBS Operator role
|
|
`"arn:aws:iam::<aws_account_id>:role/<cluster_name>-xxxx-openshift-cluster-csi-drivers-ebs-cloud-credent"`
|
|
|
|
After you create your Operator roles, you must edit the _Key Policy_ in the link:https://console.aws.amazon.com/kms[*Key Management Service (KMS)* page of the AWS Console] to add the roles.
|
|
====
|
|
|
|
.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*.
|
|
+
|
|
[NOTE]
|
|
====
|
|
If the installation fails or the cluster *State* does not change to *Ready* after about 40 minutes, check the installation troubleshooting documentation for details. For more information, see _Troubleshooting installations_. For steps to contact Red{nbsp}Hat Support for assistance, see _Getting support for Red{nbsp}Hat OpenShift Service on AWS_.
|
|
====
|