Menu Close

ROSA クラスターへのアクセスおよび削除のインストール

Red Hat OpenShift Service on AWS 4

Red Hat OpenShift Service on AWS (ROSA) クラスターのインストール、アクセス、および削除

概要

このドキュメントでは、Red Hat OpenShift Service on AWS (ROSA) クラスターをインストールする方法を説明します。このドキュメントでは、クラスターへのアクセス方法、ID プロバイダーの設定方法、クラスターアクセスの取り消し方法、およびクラスターの削除方法についても詳しく説明します。

第1章 デフォルトオプションを使用した STS での ROSA クラスターの作成

デフォルトのオプションと AWS Identity and Access Management (IAM) リソースの自動作成を使用して、Red Hat OpenShift Service on AWS (ROSA) クラスターを迅速に作成します。Red Hat OpenShift Cluster Manager または ROSA CLI (rosa) を使用して、クラスターをデプロイすることができます。

このドキュメントの手順では、auto モードを使用して、アカウント全体の IAM ロールとポリシー、オペレーターポリシー、クラスター固有のオペレーターロール、OpenID Connect (OIDC) ID プロバイダーなど、現在の AWS アカウントを使用して必要な IAM リソースをすぐに作成します。

または、IAM リソースを自動的にデプロイする代わりに、IAM リソースの作成に必要な aws コマンドを出力する manual モードを使用することもできます。auto デプロイメントモードと manual デプロイメントモードについては、自動デプロイメントモードと手動デプロイメントモードを理解するを参照してください。manual モードを使用して ROSA クラスターをデプロイする手順は、カスタマイズを使用したクラスターの作成を参照してください。

1.1. デフォルトのオプションでクラスターを作成する

デフォルトのオプションと auto モードを使用して、Red Hat OpenShift Service on AWS (ROSA) クラスターをすばやく作成します。Red Hat OpenShift Cluster Manager または ROSA CLI (rosa) を使用して、クラスターをデプロイすることができます。

1.1.1. OpenShift Cluster Manager を使用してデフォルトオプションでクラスターを作成する

Red Hat OpenShift Cluster Manager を使用して AWS Security Token Service (STS) を使用する Red Hat OpenShift Service on AWS (ROSA) クラスターを作成する場合、デフォルトのオプションを選択してクラスターをすばやく作成できます。

前提条件

  • STS で ROSA の AWS の前提条件を完了している。
  • 利用可能な AWS サービスクォータがある。
  • AWS コンソールで ROSA サービスを有効にしている。
  • インストールホストに、最新の ROSA CLI (rosa) をインストールして設定している。

    注記

    ROSA 4.10 クラスターを正常にインストールするには、最新バージョンの ROSA CLI を使用します。

  • rosa CLI を使用して Red Hat アカウントにログインしている。
  • AWS Elastic Load Balancing (ELB) サービスロールが AWS アカウントに存在することを確認している。

手順

  1. OpenShift Cluster Manager に移動し、Create clusterを選択します。
  2. Create an OpenShift cluster ページの Red Hat OpenShift Service on AWS (ROSA) 行で Create cluster を選択します。
  3. Accounts and roles ページにリストされている Prerequisites を確認して完了します。チェックボックスを選択して、すべての前提条件を読み、完了したことを確認します。
  4. Associated AWS account ドロップダウンメニューから AWS アカウントを選択します。関連付けられた AWS アカウントが見つからない場合は、Associate AWS account をクリックして、次の手順に従います。

    1. Authenticate ページで、rosa login コマンドの横にあるコピーボタンをクリックします。提供されているコマンドには、ROSA API ログイントークンが含まれています。

      注記

      OpenShift Cluster Manager の OpenShift Cluster Manager API Token ページで API トークンをロードすることもできます。

    2. CLI でコピーしたコマンドを実行して、ROSA アカウントにログインします。

      $ rosa login --token=<api_login_token> 1
      1
      <api_login_token> を、コピーされたコマンドで提供されるトークンに置き換えます。

      出力例

      I: Logged in as '<username>' on 'https://api.openshift.com'

    3. OpenShift Cluster Manager の Authenticate page で、Next をクリックします。
    4. OCM role ページで、Admin OCM role コマンドの横にあるコピーボタンをクリックします。admin ロールは、OpenShift Cluster Manager を使用して、クラスター固有の Operator ロールと OpenID Connect (OIDC) プロバイダーの自動デプロイメントを有効にします。
    5. コピーしたコマンドを CLI で実行し、プロンプトに従って OpenShift Cluster Manager IAM ロールを作成します。

      次の例では、デフォルトのオプションと auto モードを使用して管理者 OpenShift Cluster Manager IAM ロールを作成し、STS リソースを即座に作成します。この例では、OpenShift Cluster Manager IAM ロールを Red Hat 組織にリンクしています。

      $ rosa create ocm-role --admin

      出力例

      I: Creating ocm role
      ? Role prefix: ManagedOpenShift 1
      ? Permissions boundary ARN (optional):  2
      ? Role creation mode: auto 3
      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 4
      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
      OpenShift Cluster Manager IAM ロール名に含める接頭辞を指定します。デフォルトは ManagedOpenShift です。
      2
      オプション: ロールのパーミッション境界 Amazon Resource Name (ARN) を指定します。詳細は、AWS ドキュメントの IAM エンティティーのアクセス許可の境界を参照してください。
      3
      ロール作成モードを選択します。auto モードを使用して、OpenShift Cluster Manager IAM ロールを自動的に作成し、それを Red Hat 組織アカウントにリンクすることができます。
      4
      OpenShift Cluster Manager IAM ロールを Red Hat 組織アカウントにリンクします。
    6. OpenShift Cluster Manager OCM role ページで Next を選択します。
    7. User role ページで、User role コマンドのコピーボタンをクリックし、CLI でコマンドを実行します。プロンプトに従って、ユーザーロールを作成します。

      $ rosa create user-role

      出力例

      I: Creating User role
      ? Role prefix: ManagedOpenShift 1
      ? Permissions boundary ARN (optional): 2
      ? Role creation mode: auto 3
      I: Creating ocm user role using 'arn:aws:iam::<aws_account_id>:user/<aws_username>'
      ? Create the 'ManagedOpenShift-User-<ocm_username>-Role' role? Yes
      I: Created role 'ManagedOpenShift-User-<ocm_username>-Role' with ARN 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_username>-Role'
      I: Linking User role
      ? User Role ARN: arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_username>-Role
      ? Link the 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_username>-Role' role with account '<ocm_user_account_id>'? Yes 4
      I: Successfully linked role ARN 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_username>-Role' with account '<ocm_user_account_id>'

      1
      ユーザーロール名に含める接頭辞を指定します。デフォルトは ManagedOpenShift です。
      2
      オプション: ロールのパーミッション境界 Amazon Resource Name (ARN) を指定します。詳細は、AWS ドキュメントの IAM エンティティーのアクセス許可の境界を参照してください。
      3
      ロール作成モードを選択します。auto モードを使用して、ユーザーロールを自動的に作成し、OpenShift Cluster Manager ユーザーアカウントにリンクすることができます。
      4
      ユーザーロールを OpenShift Cluster Manager ユーザーアカウントにリンクします。
    8. OpenShift Cluster Manager の User role ページで、Ok を選択します。
    9. Accounts and roles ページで、AWS アカウントが関連付けられた AWS アカウントとしてリストされていることを確認します。
  5. 必要な AWS IAM アカウントのロール が自動的に検出されず、Accounts and roles ページに一覧表示されない場合は、ロールとポリシーを作成します。

    1. rosa create account-roles コマンドの横にあるコピーバッファーをクリックします。CLI でコマンドを実行して、Operator ポリシーを含む必要な AWS アカウント全体のロールとポリシーを作成します。

      $ rosa create account-roles

      出力例

      I: Logged in as '<ocm_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: 4.9.12
      I: Creating account roles
      ? Role prefix: ManagedOpenShift 1
      ? Permissions boundary ARN (optional): 2
      ? Role creation mode: auto 3
      I: Creating roles using 'arn:aws:iam::<aws_account_number>:user/<aws_username>'
      ? Create the 'ManagedOpenShift-Installer-Role' role? Yes 4
      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 6
      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 7
      I: Created role 'ManagedOpenShift-Support-Role' with ARN 'arn:aws:iam::<aws_account_number>:role/ManagedOpenShift-Support-Role'
      ? Create the operator policies? Yes 8
      I: Created policy with ARN 'arn:aws:iam::<aws_account_number>:policy/ManagedOpenShift-openshift-cloud-credential-operator-cloud-crede'
      I: Created policy with ARN 'arn:aws:iam::<aws_account_number>:policy/ManagedOpenShift-openshift-image-registry-installer-cloud-creden'
      I: Created policy with ARN 'arn:aws:iam::<aws_account_number>:policy/ManagedOpenShift-openshift-ingress-operator-cloud-credentials'
      I: Created policy with ARN 'arn:aws:iam::<aws_account_number>:policy/ManagedOpenShift-openshift-cluster-csi-drivers-ebs-cloud-credent'
      I: Created policy with ARN 'arn:aws:iam::<aws_account_number>:policy/ManagedOpenShift-openshift-cloud-network-config-controller-cloud'
      I: Created policy with ARN 'arn:aws:iam::<aws_account_number>:policy/ManagedOpenShift-openshift-machine-api-aws-cloud-credentials'
      I: To create a cluster with these roles, run the following command:
      rosa create cluster --sts

      1
      アカウント全体のロール名とポリシー名に含める接頭辞を指定します。デフォルトは ManagedOpenShift です。
      2
      オプション: ロールのパーミッション境界 Amazon Resource Name (ARN) を指定します。詳細は、AWS ドキュメントの IAM エンティティーのアクセス許可の境界を参照してください。
      3
      ロール作成モードを選択します。auto モードを使用して、アカウント全体のロールとポリシーを自動的に作成できます。
      4 5 6 7
      アカウント全体のインストーラー、コントロールプレーン、ワーカー、サポートロールおよび対応する IAM ポリシーを作成します。詳細については、アカウント全体の IAM ロールとポリシーリファレンスを参照してください。
      8
      ROSA クラスター Operator がコア OpenShift 機能を実行できるようにするクラスター固有の Operator IAM ロールを作成します。詳細については、アカウント全体の IAM ロールとポリシーリファレンスを参照してください。
    2. Accounts and roles ページで、Refresh ARNs をクリックし、インストーラー、サポート、ワーカー、およびコントロールプレーンのアカウントのロールが検出されていることを確認します。
  6. Next を選択します。
  7. Cluster details ページで、クラスターの名前を指定し、クラスターの詳細を指定します。

    1. クラスター名 を追加します。
    2. Version ドロップダウンメニューからクラスターバージョンを選択します。
    3. Region ドロップダウンメニューからクラウドプロバイダーのリージョンを選択します。
    4. Single zone または Multi-zone 設定を選択し ます。
    5. Enable user workloads monitoring を選択したままにして、Red Hat サイト信頼性エンジニアリング (SRE) プラットフォームメトリクスから切り離して独自のプロジェクトをモニターします。このオプションはデフォルトで有効になっています。
    6. オプション:etcd キー値の暗号化が必要な場合には、Enable additional etcd encryption を選択します。このオプションを使用すると、etcd キーの値は暗号化されますが、キーは暗号化されません。このオプションは、デフォルトで Red Hat OpenShift Service on AWS クラスター内の etcd ボリュームを暗号化するコントロールプレーンストレージ暗号化に追加されます。

      注記

      etcd のキー値の etcd 暗号化を有効にすると、約 20% のパフォーマンスのオーバーヘッドが発生します。このオーバーヘッドは、etcd ボリュームを暗号化するデフォルトのコントロールプレーンのストレージ暗号化に加えて、この 2 つ目の暗号化レイヤーの導入により生じます。お客様のユースケースで特にetcd 暗号化が必要な場合にのみ、暗号化を有効にすることを検討してください。

    7. オプション:独自の AWS Key Management Service (KMS)キーの Amazon Resource Name (ARN)を提供する場合は、Encrypt persistent volumes with customer keys を選択します。このキーは、クラスター内の永続ボリュームの暗号化に使用されます。
    8. 次へ をクリックします。
  8. Default machine pool ページで、Compute node instance type を選択します。

    注記

    クラスターの作成後に、クラスター内のコンピュートノード数を変更できますが、デフォルトのマシンプールのコンピュートノードインスタンスのタイプを変更することはできません。使用可能なノードの数とタイプは、単一または複数のアベイラビリティーゾーンを使用するかどうかによって異なります。また、AWS アカウントと選択したリージョンで何が有効で利用可能かによっても異なります。

  9. オプション: デフォルトのマシンプールの自動スケーリングを設定します。

    1. Enable autoscaling を選択し、デプロイメントのニーズを満たすためにデフォルトのマシンプール内のマシン数を自動的にスケーリングします。
    2. 自動スケーリングの最小および最大のノード数制限を設定します。Cluster Autoscaler は、指定する制限を超えてデフォルトのマシンプールノード数を減らしたり、増やしたりできません。

      • 単一アベイラビリティーゾーンを使用してクラスターをデプロイした場合は、最小および最大のノード数 を設定します。これは、アベイラビリティーゾーンのコンピュートノードの最小および最大の制限を定義します。
      • 複数のアベイラビリティーゾーンを使用してクラスターをデプロイした場合は、Minimum nodes per zone および Maximum nodes per zone を設定します。これは、ゾーンごとの最小および最大のコンピュート制限を定義します。
      注記

      または、デフォルトのマシンプールの作成後にマシンプールの自動スケーリングを設定できます。

  10. 自動スケーリングを有効にしなかった場合は、デフォルトのマシンプールのコンピュートノード数を選択します。

    • 単一アベイラビリティーゾーンを使用してクラスターをデプロイした場合は、ドロップダウンメニューから コンピュートノード数 を選択します。これは、ゾーンのマシンプールにプロビジョニングするコンピュートノードの数を定義します。
    • 複数のアベイラビリティーゾーンを使用してクラスターをデプロイした場合は、ドロップダウンメニューから コンピュートノードの数 (ゾーンごと) を選択します。これは、ゾーンごとにマシンプールにプロビジョニングするコンピュートノードの数を定義します。
  11. 任意手順: Edit node labels を展開してラベルをノードに追加します。Add label をクリックしてさらにノードラベルを追加し、Next を選択します。
  12. Network configuration ページの Cluster privacy セクションで、Public または Privateを選択して、クラスターのパブリックまたはプライベート API エンドポイントとアプリケーションルートを使用します。

    重要

    プライベート API エンドポイントを使用している場合、クラウドプロバイダーアカウントのネットワーク設定を更新するまでクラスターにはアクセスできません。

  13. オプション: パブリック API エンドポイントを使用することを選択した場合は、既存の VPC にインストールを選択して、クラスターを 既存の VPC にインストールできます。

    注記

    プライベート API エンドポイントを使用することを選択した場合は、既存の VPC と PrivateLink を使用する必要があり、既存の VPC にインストールしてUse a PrivateLink オプションが自動的に選択されます。これらのオプションを使用すると、Red Hat サイト信頼性エンジニアリング (SRE) チームはクラスターに接続して、AWS PrivateLink エンドポイントのみを使用してサポートを行うことができます。

  14. オプション: クラスターを既存の VPC にインストールする場合は、Configure a cluster-wide proxy を選択して、HTTP または HTTPS プロキシーがクラスターからインターネットへの直接アクセスを拒否できるようにします。
  15. 次へ をクリックします。
  16. クラスターを既存の AWS VPC にインストールする場合、Virtual Private Cloud (VPC)サブネット設定 を指定します。

    注記

    クラスターをインストールするアベイラビリティーゾーンごとに、VPC がパブリックおよびプライベートサブネットで設定されるようにする必要があります。PrivateLink を使用する場合には、プライベートサブネットのみが必要になります。

  17. CIDR ranges ダイアログで、カスタムのClassless Inter-Domain Routing (CIDR)範囲を設定するか、または提供されるデフォルトを使用して、Next を、クリックします。

    注記

    VPC にインストールする場合、Machine CIDR 範囲は VPC サブネットに一致する必要があります。

    重要

    CIDR 設定は後で変更することはできません。続行する前に、ネットワーク管理者と選択内容を確認してください。

  18. Cluster roles and policies ページで、Auto モードを選択します。このモードでは、クラスター固有のオペレーター IAM ロールと OIDC プロバイダーを自動的に作成できます。

    注記

    Auto モードを有効にするには、OpenShift Cluster Manager IAM ロールに管理者機能が必要です。

    または、Manual モードを使用してクラスター固有の IAM ロールと OIDC プロバイダーを作成する場合は、カスタマイズを使用したクラスターの作成を参照してください。

  19. オプション: クラスター固有のオペレーターロールの カスタムオペレーターロール接頭辞を指定します。

    注記

    デフォルトでは、クラスター固有のオペレーターのロール名には、クラスター名とランダムな 4 桁のハッシュが接頭辞として付けられます。オプションで、ロール名の <cluster_name>-<hash> を置き換えるカスタム接頭辞を指定できます。接頭辞は、クラスター固有の Operator IAM ロールを作成するときに適用されます。接頭辞の詳細は、カスタム Operator IAM ロール接頭辞についてを参照してください。

  20. Next を選択します。
  21. Cluster update strategy ページで、更新設定を行います。

    1. クラスターの更新方法を選択します。

      • 各更新を個別にスケジュールする場合は、Individual updatesを選択します。以下はデフォルトのオプションになります。
      • Recurring updatesを選択して、更新が利用可能な場合に、希望の曜日と開始時刻にクラスターを更新します。

        重要

        定期的な更新を選択した場合でも、マイナーリリース間でクラスターをアップグレードする前に、アカウント全体およびクラスター固有の IAM リソースを更新する必要があります。

        注記

        保守終了日は、Red Hat OpenShift Service on AWS の更新ライフサイクルドキュメントで確認できます。詳細については、Red Hat OpenShift Service on AWS 更新ライフサイクル を参照してください。

    2. 繰り返し更新を選択した場合は、ドロップダウンメニューから希望の曜日およびアップグレード開始時刻(UTC)を選択します。
    3. オプション: クラスターアップグレード時の ノードのドレイン (解放) の猶予期間を設定できます。デフォルトで 1 時間 の猶予期間が設定されます。
    4. 次へ をクリックします。

      注記

      クラスターのセキュリティーまたは安定性に大きく影響する重大なセキュリティー問題がある場合、Red Hat サイト信頼性エンジニアリング(SRE)は、影響を受けない最新の zストリームバージョンへの自動更新をスケジュールする場合があります。更新は、お客様に通知された後、48 時間以内に適用されます。重大な影響を及ぼすセキュリティー評価の説明は、「Understanding Red Hat security ratings」を参照してください。

  22. 選択の概要を確認し、Create cluster をクリックしてクラスターのインストールを開始します。

検証

  • クラスターの Overview ページで、インストールの進捗をモニターできます。同じページでインストールのログを表示できます。そのページの Details セクションの StatusReady として表示されると、クラスターは準備が完了した状態になります。

    注記

    インストールが失敗するか、約 40 分経ってもクラスターの 状態Ready に変わらない場合は、インストールのトラブルシューティングのドキュメントで詳細を確認してください。詳細は、インストールのトラブルシューティングを参照してください。Red Hat サポートにサポートを依頼する手順は、Red Hat OpenShift Service on AWS のサポートを受けるを参照してください。

1.1.2. CLI を使用してデフォルトオプションでクラスターを作成する

Red Hat OpenShift Service on AWS (ROSA) CL I(rosa) を使用して AWS Security Token Service (STS) を使用するクラスターを作成する場合、デフォルトのオプションを選択してクラスターをすばやく作成できます。

前提条件

  • STS で ROSA の AWS の前提条件を完了している。
  • 利用可能な AWS サービスクォータがある。
  • AWS コンソールで ROSA サービスを有効にしている。
  • インストールホストに、最新の ROSA CLI (rosa) をインストールして設定している。

    注記

    ROSA 4.10 クラスターを正常にインストールするには、最新バージョンの ROSA CLI を使用します。

  • rosa CLI を使用して Red Hat アカウントにログインしている。
  • AWS Elastic Load Balancing (ELB) サービスロールが AWS アカウントに存在することを確認している。

手順

  1. Operator ポリシーを含む、必要なアカウント全体のロールおよびポリシーを作成します。

    $ rosa create account-roles --mode auto
    注記

    auto モードを使用する場合は、任意で -y 引数を指定して対話式プロンプトを回避し、操作を自動的にチェックできます。

  2. デフォルトを使用して STS でクラスターを作成します。デフォルトを使用する場合は、最新の安定した OpenShift バージョンがインストールされます。

    $ rosa create cluster --cluster-name <cluster_name> --sts --mode auto 1
    1
    <cluster_name> をクラスターの名前に置き換えます。
    注記

    --mode auto を指定すると、rosa create cluster コマンドは、クラスター固有の Operator IAM ロールおよび OIDC プロバイダーを自動的に作成します。Operator は、OIDC プロバイダーを利用して認証を行います。

  3. クラスターのステータスを確認します。

    $ rosa describe cluster --cluster <cluster_name|cluster_id>

    以下の State フィールドの変更は、クラスターインストールの進捗として出力に表示されます。

    • waiting (Waiting for OIDC configuration)
    • pending (Preparing account)
    • installing (DNS setup in progress)
    • installing
    • ready

      注記

      インストールが失敗した場合や、約 40 分後に State フィールドが ready に変わらない場合は、インストールのトラブルシューティングに関するドキュメントで詳細を確認してください。詳細は、インストールのトラブルシューティングを参照してください。Red Hat サポートにサポートを依頼する手順は、Red Hat OpenShift Service on AWS のサポートを受けるを参照してください。

  4. OpenShift インストーラーログを監視して、クラスター作成の進捗を追跡します。

    $ rosa logs install --cluster <cluster_name|cluster_id> --watch 1
    1
    --watch フラグを指定して、新規ログメッセージをインストールの進捗として監視します。この引数は任意です。

1.2. 次のステップ

1.3. その他のリソース

第2章 カスタマイズを使用して STS を使用する ROSA クラスターの作成

カスタマイズを使用して、AWS Security Token Service (STS) で Red Hat OpenShift Service on AWS (ROSA) クラスターを作成します。Red Hat OpenShift Cluster Manager または ROSA CLI (rosa) を使用して、クラスターをデプロイすることができます。

このドキュメントの手順では、必要な AWS Identity and Access Management (IAM) リソースを作成するときに、auto モードと manual モードのどちらかを選択することもできます。

2.1. 自動デプロイメントモードと手動デプロイメントモードを理解する

AWS Security Token Service (STS) を使用する Red Hat OpenShift Service on AWS (ROSA) クラスターをインストールする場合、auto または manual の ROSA CLI (rosa) モードを選択して、必要な AWS Identity and Access Management (IAM) リソースを作成できます。

auto モード
このモードでは、rosa は必要な IAM ロールとポリシー、および AWS アカウントに OpenID Connect (OIDC) プロバイダーをすぐに作成します。
手動モード
このモードでは、rosa は IAM リソースの作成に必要な aws コマンドを出力します。対応するポリシーの JSON ファイルも現在のディレクトリーに保存されます。manual モードを使用すると、生成された aws コマンドを手動で実行する前に確認できます。manual モードでは、コマンドを組織内の別の管理者またはグループに渡して、リソースを作成することもできます。
重要

manual モードを使用することを選択した場合、クラスターのインストールは、クラスター固有のオペレーターのロールと OIDC プロバイダーを手動で作成するまで待機します。リソースを作成した後、インストールが続行されます。詳細は、OpenShift Cluster Manager を使用した Operator ロールと OIDC プロバイダーの作成を参照してください。

STS で ROSA をインストールするために必要な AWS IAM リソースの詳細は、STS を使用するクラスターの IAM リソースについてを参照してください。

2.1.1. OpenShift Cluster Manager を使用した Operator ロールと OIDC プロバイダーの作成

Red Hat OpenShift Cluster Manager を使用してクラスターをインストールし、manual モードを使用して必要な AWS IAM Operator ロールと OIDC プロバイダーを作成することを選択した場合、リソースをインストールするために以下のいずれかの方法を選択するように求められます。組織のニーズに合ったリソース作成方法を選択できるようにするためのオプションが用意されています。

AWS CLI (aws)
この方法では、IAM リソースの作成に必要な aws コマンドとポリシーファイルを含むアーカイブファイルをダウンロードして展開できます。ポリシーファイルを含むディレクトリーから提供された CLI コマンドを実行して、Operator ロールと OIDC プロバイダーを作成します。
ROSA CLI (rosa)
このメソッドによって提供されるコマンドを実行して、rosa を使用してクラスターのオペレーターロールと OIDC プロバイダーを作成できます。

auto モードを使用する場合、OpenShift Cluster Manager は、OpenShift Cluster Manager IAM ロールを通じて提供されるパーミッションを使用して、Operator ロールと OIDC プロバイダーを自動的に作成します。この機能を使用するには、ロールに管理者権限を適用する必要があります。

2.2. STS を使用した ROSA クラスターのサポートについての考慮事項

AWS Security Token Service (STS)を使用する Red Hat OpenShift Service on AWS クラスターを作成する方法でサポート対象なのは、この製品ドキュメントで説明されている手順を使用する方法です。

重要

Red Hat OpenShift Service on AWS CLI (rosa) で manual モードを使用し、STS リソースのインストールに必要な AWS Identity and Access Management (IAM) ポリシーファイルおよび aws コマンドを生成できます。

ファイルおよび aws コマンドは、レビュー目的でのみ生成され、いずれの方法でも変更しないでください。Red Hat は、変更したバージョンのポリシーファイルまたは aws コマンドを使用してデプロイした ROSA クラスターのサポートを提供しません。

2.3. カスタマイズを使用したクラスターの作成

ご使用の環境のニーズに適した設定で、AWS Security Token Service (STS) クラスターを備えた Red Hat OpenShift Service on AWS (ROSA) をデプロイします。Red Hat OpenShift Cluster Manager または ROSA CLI (rosa) を使用して、カスタマイズを使用してクラスターをデプロイできます。

2.3.1. OpenShift Cluster Manager を使用してカスタマイズしたクラスターを作成する

AWS Security Token Service (STS) を使用する Red Hat OpenShift Service on AWS (ROSA) クラスターを作成する場合、Red Hat OpenShift Cluster Manager を使用して、インストールをインタラクティブにカスタマイズできます。

重要

STS では、パブリックおよび AWS PrivateLink クラスターのみがサポートされます。通常の プライベートクラスター (PrivateLink 以外) は STS では使用できません。

注記

現時点で、AWS 共有 VPC は ROSA インストールではサポートされていません。

前提条件

  • STS で ROSA の AWS の前提条件を完了している。
  • 利用可能な AWS サービスクォータがある。
  • AWS コンソールで ROSA サービスを有効にしている。
  • インストールホストに、最新の ROSA CLI (rosa) をインストールして設定している。

    注記

    ROSA 4.10 クラスターを正常にインストールするには、最新バージョンの ROSA CLI を使用します。

  • rosa CLI を使用して Red Hat アカウントにログインしている。
  • AWS Elastic Load Balancing (ELB) サービスロールが AWS アカウントに存在することを確認している。

手順

  1. OpenShift Cluster Manager に移動し、Create clusterを選択します。
  2. Create an OpenShift cluster ページの Red Hat OpenShift Service on AWS (ROSA) 行で Create cluster を選択します。
  3. Accounts and roles ページにリストされている Prerequisites を確認して完了します。チェックボックスを選択して、すべての前提条件を読み、完了したことを確認します。
  4. Associated AWS account ドロップダウンメニューから AWS アカウントを選択します。関連付けられた AWS アカウントが見つからない場合は、Associate AWS account をクリックして、次の手順に従います。

    1. Authenticate ページで、rosa login コマンドの横にあるコピーボタンをクリックします。提供されているコマンドには、ROSA API ログイントークンが含まれています。

      注記

      OpenShift Cluster Manager の OpenShift Cluster Manager API Token ページで API トークンをロードすることもできます。

    2. CLI でコピーしたコマンドを実行して、ROSA アカウントにログインします。

      $ rosa login --token=<api_login_token> 1
      1
      <api_login_token> を、コピーされたコマンドで提供されるトークンに置き換えます。

      出力例

      I: Logged in as '<username>' on 'https://api.openshift.com'

    3. OpenShift Cluster Manager の Authenticate page で、Next をクリックします。
    4. OCM role ページで、Basic OCM role または Admin OCM role コマンドの横にあるコピーボタンをクリックします。

      基本ロールにより、OpenShift Cluster Manager は ROSA に必要な AWS IAM ロールとポリシーを検出できます。管理者ロールは、ロールとポリシーの検出も可能にします。さらに、管理者ロールを使用すると、OpenShift Cluster Manager を使用して、クラスター固有の Operator ロールと OpenID Connect (OIDC) プロバイダーを自動的にデプロイできます。

    5. コピーしたコマンドを CLI で実行し、プロンプトに従って OpenShift Cluster Manager IAM ロールを作成します。次の例では、デフォルトのオプションを使用して基本的な OpenShift Cluster Manager IAM ロールを作成します。

      $ rosa create ocm-role

      出力例

      I: Creating ocm role
      ? Role prefix: ManagedOpenShift 1
      ? Enable admin capabilities for the OCM role (optional): No 2
      ? Permissions boundary ARN (optional):  3
      ? Role creation mode: auto 4
      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 5
      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
      OpenShift Cluster Manager IAM ロール名に含める接頭辞を指定します。デフォルトは ManagedOpenShift です。
      2
      管理者 OpenShift Cluster Manager IAM ロールを有効にします。これは、--admin 引数を指定するのと同じです。自動 モードを使用して、OpenShift Cluster Manager を使用してクラスター固有の Operator ロールと OIDC プロバイダーを自動的にプロビジョニングする場合は、管理者ロールが必要です。
      3
      オプション: ロールのパーミッション境界 Amazon Resource Name (ARN) を指定します。詳細は、AWS ドキュメントの IAM エンティティーのアクセス許可の境界を参照してください。
      4
      ロール作成モードを選択します。auto モードを使用して、OpenShift Cluster Manager IAM ロールを自動的に作成し、それを Red Hat 組織アカウントにリンクすることができます。manual モードでは、rosa CLI はロールの作成とリンクに必要な aws コマンドを生成します。manual モードでは、対応するポリシー JSON ファイルも現在のディレクトリーに保存されます。manual モードでは、aws コマンドを手動で実行する前に詳細を確認することができます。
      5
      OpenShift Cluster Manager IAM ロールを Red Hat 組織アカウントにリンクします。
    6. 上記のコマンドで OpenShift Cluster Manager IAM ロールを Red Hat 組織アカウントにリンクしないことを選択した場合は、OpenShift Cluster Manager OCM role ページから rosa link コマンドをコピーして実行します。

      $ rosa link ocm-role <arn> 1
      1
      <arn> を、前のコマンドの出力に含まれている OpenShift Cluster Manager IAM の ARN に置き換えます。
    7. OpenShift Cluster Manager OCM role ページで Next を選択します。
    8. User role ページで、User role コマンドのコピーボタンをクリックし、CLI でコマンドを実行します。プロンプトに従って、ユーザーロールを作成します。

      $ rosa create user-role

      出力例

      I: Creating User role
      ? Role prefix: ManagedOpenShift 1
      ? Permissions boundary ARN (optional): 2
      ? Role creation mode: auto 3
      I: Creating ocm user role using 'arn:aws:iam::<aws_account_id>:user/<aws_username>'
      ? Create the 'ManagedOpenShift-User-<ocm_username>-Role' role? Yes
      I: Created role 'ManagedOpenShift-User-<ocm_username>-Role' with ARN 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_username>-Role'
      I: Linking User role
      ? User Role ARN: arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_username>-Role
      ? Link the 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_username>-Role' role with account '<ocm_user_account_id>'? Yes 4
      I: Successfully linked role ARN 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_username>-Role' with account '<ocm_user_account_id>'

      1
      ユーザーロール名に含める接頭辞を指定します。デフォルトは ManagedOpenShift です。
      2
      オプション: ロールのパーミッション境界 Amazon Resource Name (ARN) を指定します。詳細は、AWS ドキュメントの IAM エンティティーのアクセス許可の境界を参照してください。
      3
      ロール作成モードを選択します。auto モードを使用して、ユーザーロールを自動的に作成し、OpenShift Cluster Manager ユーザーアカウントにリンクすることができます。manual モードでは、rosa CLI はロールの作成とリンクに必要な aws コマンドを生成します。manual モードでは、対応するポリシー JSON ファイルも現在のディレクトリーに保存されます。manual モードでは、aws コマンドを手動で実行する前に詳細を確認することができます。
      4
      ユーザーロールを OpenShift Cluster Manager ユーザーアカウントにリンクします。
    9. 上記のコマンドでユーザーロールを OpenShift Cluster Manager ユーザーアカウントにリンクしないことを選択した場合は、OpenShift Cluster Manager User role ページから rosa link コマンドをコピーして実行します。

      $ rosa link user-role <arn> 1
      1
      <arn> を、前のコマンドの出力に含まれているユーザーロールの ARN に置き換えます。
    10. OpenShift Cluster Manager の User role ページで、Ok を選択します。
    11. Accounts and roles ページで、AWS アカウントが関連付けられた AWS アカウントとしてリストされていることを確認します。
  5. 必要な AWS IAM アカウントのロール が自動的に検出されず、Accounts and roles ページに一覧表示されない場合は、ロールとポリシーを作成します。

    1. rosa create account-roles コマンドの横にあるコピーバッファーをクリックします。CLI でコマンドを実行して、Operator ポリシーを含む必要な AWS アカウント全体のロールとポリシーを作成します。

      $ rosa create account-roles

      出力例

      I: Logged in as '<ocm_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: 4.9.12
      I: Creating account roles
      ? Role prefix: ManagedOpenShift 1
      ? Permissions boundary ARN (optional): 2
      ? Role creation mode: auto 3
      I: Creating roles using 'arn:aws:iam::<aws_account_number>:user/<aws_username>'
      ? Create the 'ManagedOpenShift-Installer-Role' role? Yes 4
      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 6
      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 7
      I: Created role 'ManagedOpenShift-Support-Role' with ARN 'arn:aws:iam::<aws_account_number>:role/ManagedOpenShift-Support-Role'
      ? Create the operator policies? Yes 8
      I: Created policy with ARN 'arn:aws:iam::<aws_account_number>:policy/ManagedOpenShift-openshift-cloud-credential-operator-cloud-crede'
      I: Created policy with ARN 'arn:aws:iam::<aws_account_number>:policy/ManagedOpenShift-openshift-image-registry-installer-cloud-creden'
      I: Created policy with ARN 'arn:aws:iam::<aws_account_number>:policy/ManagedOpenShift-openshift-ingress-operator-cloud-credentials'
      I: Created policy with ARN 'arn:aws:iam::<aws_account_number>:policy/ManagedOpenShift-openshift-cluster-csi-drivers-ebs-cloud-credent'
      I: Created policy with ARN 'arn:aws:iam::<aws_account_number>:policy/ManagedOpenShift-openshift-cloud-network-config-controller-cloud'
      I: Created policy with ARN 'arn:aws:iam::<aws_account_number>:policy/ManagedOpenShift-openshift-machine-api-aws-cloud-credentials'
      I: To create a cluster with these roles, run the following command:
      rosa create cluster --sts

      1
      OpenShift Cluster Manager IAM ロール名に含める接頭辞を指定します。デフォルトは ManagedOpenShift です。
      2
      オプション: ロールのパーミッション境界 Amazon Resource Name (ARN) を指定します。詳細は、AWS ドキュメントの IAM エンティティーのアクセス許可の境界を参照してください。
      3
      ロール作成モードを選択します。auto モードを使用して、アカウント全体のロールとポリシーを自動的に作成できます。manual モードでは、rosa CLI はロールとポリシーの作成に必要な aws コマンドを生成します。manual モードでは、対応するポリシー JSON ファイルも現在のディレクトリーに保存されます。manual モードでは、aws コマンドを手動で実行する前に詳細を確認することができます。
      4 5 6 7
      アカウント全体のインストーラー、コントロールプレーン、ワーカー、サポートロールおよび対応する IAM ポリシーを作成します。詳細については、アカウント全体の IAM ロールとポリシーリファレンスを参照してください。
      8
      ROSA クラスター Operator がコア OpenShift 機能を実行できるようにするクラスター固有の Operator IAM ロールを作成します。詳細については、アカウント全体の IAM ロールとポリシーリファレンスを参照してください。
    2. Accounts and roles ページで、Refresh ARNs をクリックし、インストーラー、サポート、ワーカー、およびコントロールプレーンのアカウントのロールが検出されていることを確認します。
  6. Next を選択します。
  7. Cluster details ページで、クラスターの名前を指定し、クラスターの詳細を指定します。

    1. クラスター名 を追加します。
    2. Version ドロップダウンメニューからクラスターバージョンを選択します。
    3. Region ドロップダウンメニューからクラウドプロバイダーのリージョンを選択します。
    4. Single zone または Multi-zone 設定を選択し ます。
    5. Enable user workloads monitoring を選択したままにして、Red Hat サイト信頼性エンジニアリング (SRE) プラットフォームメトリクスから切り離して独自のプロジェクトをモニターします。このオプションはデフォルトで有効になっています。
    6. オプション:etcd キー値の暗号化が必要な場合には、Enable additional etcd encryption を選択します。このオプションを使用すると、etcd キーの値は暗号化されますが、キーは暗号化されません。このオプションは、デフォルトで Red Hat OpenShift Service on AWS クラスター内の etcd ボリュームを暗号化するコントロールプレーンストレージ暗号化に追加されます。

      注記

      etcd のキー値の etcd 暗号化を有効にすると、約 20% のパフォーマンスのオーバーヘッドが発生します。このオーバーヘッドは、etcd ボリュームを暗号化するデフォルトのコントロールプレーンのストレージ暗号化に加えて、この 2 つ目の暗号化レイヤーの導入により生じます。お客様のユースケースで特にetcd 暗号化が必要な場合にのみ、暗号化を有効にすることを検討してください。

    7. オプション:独自の AWS Key Management Service (KMS)キーの Amazon Resource Name (ARN)を提供する場合は、Encrypt persistent volumes with customer keys を選択します。このキーは、クラスター内の永続ボリュームの暗号化に使用されます。
    8. 次へ をクリックします。
  8. Default machine pool ページで、Compute node instance type を選択します。

    注記

    クラスターの作成後に、クラスター内のコンピュートノード数を変更できますが、デフォルトのマシンプールのコンピュートノードインスタンスのタイプを変更することはできません。使用可能なノードの数とタイプは、単一または複数のアベイラビリティーゾーンを使用するかどうかによって異なります。また、AWS アカウントと選択したリージョンで何が有効で利用可能かによっても異なります。

  9. オプション: デフォルトのマシンプールの自動スケーリングを設定します。

    1. Enable autoscaling を選択し、デプロイメントのニーズを満たすためにデフォルトのマシンプール内のマシン数を自動的にスケーリングします。
    2. 自動スケーリングの最小および最大のノード数制限を設定します。Cluster Autoscaler は、指定する制限を超えてデフォルトのマシンプールノード数を減らしたり、増やしたりできません。

      • 単一アベイラビリティーゾーンを使用してクラスターをデプロイした場合は、最小および最大のノード数 を設定します。これは、アベイラビリティーゾーンのコンピュートノードの最小および最大の制限を定義します。
      • 複数のアベイラビリティーゾーンを使用してクラスターをデプロイした場合は、Minimum nodes per zone および Maximum nodes per zone を設定します。これは、ゾーンごとの最小および最大のコンピュート制限を定義します。
      注記

      または、デフォルトのマシンプールの作成後にマシンプールの自動スケーリングを設定できます。

  10. 自動スケーリングを有効にしなかった場合は、デフォルトのマシンプールのコンピュートノード数を選択します。

    • 単一アベイラビリティーゾーンを使用してクラスターをデプロイした場合は、ドロップダウンメニューから コンピュートノード数 を選択します。これは、ゾーンのマシンプールにプロビジョニングするコンピュートノードの数を定義します。
    • 複数のアベイラビリティーゾーンを使用してクラスターをデプロイした場合は、ドロップダウンメニューから コンピュートノードの数 (ゾーンごと) を選択します。これは、ゾーンごとにマシンプールにプロビジョニングするコンピュートノードの数を定義します。
  11. 任意手順: Edit node labels を展開してラベルをノードに追加します。Add label をクリックしてさらにノードラベルを追加し、Next を選択します。
  12. Network configuration ページの Cluster privacy セクションで、Public または Privateを選択して、クラスターのパブリックまたはプライベート API エンドポイントとアプリケーションルートを使用します。

    重要

    プライベート API エンドポイントを使用している場合、クラウドプロバイダーアカウントのネットワーク設定を更新するまでクラスターにはアクセスできません。

  13. オプション: パブリック API エンドポイントを使用することを選択した場合は、既存の VPC にインストールを選択して、クラスターを 既存の VPC にインストールできます。

    注記

    プライベート API エンドポイントを使用することを選択した場合は、既存の VPC と PrivateLink を使用する必要があり、既存の VPC にインストールしてUse a PrivateLink オプションが自動的に選択されます。これらのオプションを使用すると、Red Hat サイト信頼性エンジニアリング (SRE) チームはクラスターに接続して、AWS PrivateLink エンドポイントのみを使用してサポートを行うことができます。

  14. オプション: クラスターを既存の VPC にインストールする場合は、Configure a cluster-wide proxy を選択して、HTTP または HTTPS プロキシーがクラスターからインターネットへの直接アクセスを拒否できるようにします。
  15. 次へ をクリックします。
  16. クラスターを既存の AWS VPC にインストールする場合、Virtual Private Cloud (VPC)サブネット設定 を指定します。

    注記

    クラスターをインストールするアベイラビリティーゾーンごとに、VPC がパブリックおよびプライベートサブネットで設定されるようにする必要があります。PrivateLink を使用する場合には、プライベートサブネットのみが必要になります。

  17. CIDR ranges ダイアログで、カスタムのClassless Inter-Domain Routing (CIDR)範囲を設定するか、または提供されるデフォルトを使用して、Next を、クリックします。

    注記

    VPC にインストールする場合、Machine CIDR 範囲は VPC サブネットに一致する必要があります。

    重要

    CIDR 設定は後で変更することはできません。続行する前に、ネットワーク管理者と選択内容を確認してください。

  18. クラスターのロールとポリシーページで、優先するクラスター固有のオペレーター IAM のロールと OIDC プロバイダーの作成モードを選択します。

    Manual モードでは、rosa CLI コマンドまたは aws CLI コマンドのいずれかを使用して、クラスターに必要な Operator ロールと OIDC プロバイダーを生成できます。手動 モードでは、優先オプションを使用して IAM リソースを手動で作成し、クラスターのインストールを完了する前に、詳細を確認できます。

    または、自動 モードを使用して、オペレーターのロールと OIDC プロバイダーを自動的に作成することもできます。

    注記

    Auto モードを有効にするには、OpenShift Cluster Manager IAM ロールに管理者機能が必要です。

  19. オプション: クラスター固有の Operator IAM ロールの カスタム Operator ロール接頭辞 を指定します。

    注記

    デフォルトでは、クラスター固有のオペレーターのロール名には、クラスター名とランダムな 4 桁のハッシュが接頭辞として付けられます。オプションで、ロール名の <cluster_name>-<hash> を置き換えるカスタム接頭辞を指定できます。接頭辞は、クラスター固有の Operator IAM ロールを作成するときに適用されます。接頭辞の詳細は、カスタム Operator IAM ロール接頭辞についてを参照してください。

  20. Next を選択します。
  21. Cluster update strategy ページで、更新設定を行います。

    1. クラスターの更新方法を選択します。

      • 各更新を個別にスケジュールする場合は、Individual updatesを選択します。以下はデフォルトのオプションになります。
      • Recurring updatesを選択して、更新が利用可能な場合に、希望の曜日と開始時刻にクラスターを更新します。

        重要

        定期的な更新を選択した場合でも、マイナーリリース間でクラスターをアップグレードする前に、アカウント全体およびクラスター固有の IAM リソースを更新する必要があります。

        注記

        保守終了日は、Red Hat OpenShift Service on AWS の更新ライフサイクルドキュメントで確認できます。詳細については、Red Hat OpenShift Service on AWS 更新ライフサイクル を参照してください。

    2. 繰り返し更新を選択した場合は、ドロップダウンメニューから希望の曜日およびアップグレード開始時刻(UTC)を選択します。
    3. オプション: クラスターアップグレード時の ノードのドレイン (解放) の猶予期間を設定できます。デフォルトで 1 時間 の猶予期間が設定されます。
    4. 次へ をクリックします。

      注記

      クラスターのセキュリティーまたは安定性に大きく影響する重大なセキュリティー問題がある場合、Red Hat サイト信頼性エンジニアリング(SRE)は、影響を受けない最新の zストリームバージョンへの自動更新をスケジュールする場合があります。更新は、お客様に通知された後、48 時間以内に適用されます。重大な影響を及ぼすセキュリティー評価の説明は、「Understanding Red Hat security ratings」を参照してください。

  22. 選択の概要を確認し、Create cluster をクリックしてクラスターのインストールを開始します。
  23. 手動 モードを使用することを選択した場合は、クラスター固有の Operator のロールと OIDC プロバイダーを手動で作成して、インストールを続行します。

    1. Action required to continue installation ダイアログで、AWS CLI または ROSA CLI タブを選択し、リソースを手動で作成します。

      • AWS CLI メソッドを使用することを選択した場合は、Download .zip をクリックしてファイルを保存してから、AWS CLI コマンドとポリシーファイルを展開します。次に、CLI で提供されている aws コマンドを実行します。

        注記

        ポリシーファイルを含むディレクトリーで aws コマンドを実行する必要があります。

      • ROSA CLI メソッドを使用することを選択した場合は、rosa create コマンドの横にあるコピーボタンをクリックして、CLI で実行します。
    2. Action required to continue installation ダイアログで、x をクリックしてクラスターの Overview ページに戻ります。
    3. Overview ページの Details セクションで、クラスターの StatusWaiting から Installing に変更されていることを確認します。ステータスが変わるまでに約 2 分の短い遅延が発生する場合があります。
    注記

    自動 モードの使用を選択した場合、OpenShift Cluster Manager は Operator ロールと OIDC プロバイダーを自動的に作成します。

検証

  • クラスターの Overview ページで、インストールの進捗をモニターできます。同じページでインストールのログを表示できます。そのページの Details セクションの StatusReady として表示されると、クラスターは準備が完了した状態になります。

    注記

    インストールが失敗するか、約 40 分経ってもクラスターの 状態Ready に変わらない場合は、インストールのトラブルシューティングのドキュメントで詳細を確認してください。詳細は、インストールのトラブルシューティングを参照してください。Red Hat サポートにサポートを依頼する手順は、Red Hat OpenShift Service on AWS のサポートを受けるを参照してください。

2.3.2. CLI を使用してカスタマイズしたクラスターを作成する

AWS Security Token Service (STS) を使用する Red Hat OpenShift Service on AWS (ROSA) クラスターを作成する場合は、インストールを対話的にカスタマイズできます。

rosa create cluster --interactive をクラスターの作成時に実行すると、デプロイメントのカスタマイズを可能にする一連の対話式プロンプトが表示されます。詳細は、対話式クラスター作成モードリファレンス を参照してください。

対話モードを使用したクラスターのインストールが完了すると、同じカスタム設定を使用してさらにクラスターをデプロイできるようにする単一のコマンドが出力に提供されます。

重要

STS では、パブリックおよび AWS PrivateLink クラスターのみがサポートされます。通常の プライベートクラスター (PrivateLink 以外) は STS では使用できません。

注記

現時点で、AWS 共有 VPC は ROSA インストールではサポートされていません。

前提条件

  • STS で ROSA の AWS の前提条件を完了している。
  • 利用可能な AWS サービスクォータがある。
  • AWS コンソールで ROSA サービスを有効にしている。
  • インストールホストに最新の ROSA (rosa) および AWS (aws) CLI をインストールして設定しました。

    注記

    ROSA 4.10 クラスターを正常にインストールするには、最新バージョンの ROSA CLI を使用します。

  • 暗号化にお客様が管理する AWS Key Management Service (KMS) キーを使用している場合は、対称 KMS キーを作成し、キー ID および Amazon Resource Name (ARN) がある。AWS KMS キーの作成に関する詳細は、AWS ドキュメント を参照してください。

手順

  1. Operator ポリシーを含む、必要なアカウント全体のロールおよびポリシーを作成します。

    1. 現在の作業ディレクトリーに IAM ポリシー JSON ファイルを作成し、確認用に aws CLI コマンドを実行します。

      $ rosa create account-roles --mode manual 1
      1
      manual モードは、アカウント全体のロールおよびポリシーの作成に必要な aws CLI コマンドおよび JSON ファイルを生成します。確認後、手動でコマンドを実行してリソースを作成する必要があります。
    2. 確認後は、aws コマンドを手動で実行し、ロールおよびポリシーを作成します。または、--mode auto を使用して前述のコマンドを実行して、aws コマンドを即座に実行できます。
  2. オプション: 独自の AWS KMS キーを使用してコントロールプレーン、インフラストラクチャー、およびワーカーノードのルートボリュームを暗号化する場合は、アカウント全体のインストーラーロールの ARN を KMS キーポリシーに追加します。

    1. KMS キーのキーポリシーをローカルマシンのファイルに保存します。次の例では、出力を現在の作業ディレクトリーの kms-key-policy.json に保存します。

      $ aws kms get-key-policy --key-id <key_id_or_arn> --policy-name default --output text > kms-key-policy.json 1
      1
      <key_id_or_arn> を KMS キーの ID または ARN に置き換えます。
    2. 前述の手順で作成したアカウント全体のインストーラーロールの ARN を、ファイルの Statement.Principal.AWS セクションに追加します。以下の例では、デフォルトの ManagedOpenShift-Installer-Role ロールの ARN が追加されます。

      {
          "Version": "2012-10-17",
          "Id": "key-rosa-policy-1",
          "Statement": [
              {
                  "Sid": "Enable IAM User Permissions",
                  "Effect": "Allow",
                  "Principal": {
                      "AWS": "arn:aws:iam::<aws-account-id>:root"
                  },
                  "Action": "kms:*",
                  "Resource": "*"
              },
              {
                  "Sid": "Allow ROSA use of the key",
                  "Effect": "Allow",
                  "Principal": {
                      "AWS": [
                          "arn:aws:iam::<aws-account-id>:role/ManagedOpenShift-Support-Role", 1
                          "arn:aws:iam::<aws-account-id>:role/ManagedOpenShift-Installer-Role",
                          "arn:aws:iam::<aws-account-id>:role/ManagedOpenShift-Worker-Role",
                          "arn:aws:iam::<aws-account-id>:role/ManagedOpenShift-ControlPlane-Role"
                      ]
                  },
                  "Action": [
                      "kms:Encrypt",
                      "kms:Decrypt",
                      "kms:ReEncrypt*",
                      "kms:GenerateDataKey*",
                      "kms:DescribeKey"
                  ],
                  "Resource": "*"
              },
              {
                  "Sid": "Allow attachment of persistent resources",
                  "Effect": "Allow",
                  "Principal": {
                      "AWS": [
                          "arn:aws:iam::<aws-account-id>:role/ManagedOpenShift-Support-Role", 2
                          "arn:aws:iam::<aws-account-id>:role/ManagedOpenShift-Installer-Role",
                          "arn:aws:iam::<aws-account-id>:role/ManagedOpenShift-Worker-Role",
                          "arn:aws:iam::<aws-account-id>:role/ManagedOpenShift-ControlPlane-Role"
                      ]
                  },
                  "Action": [
                      "kms:CreateGrant",
                      "kms:ListGrants",
                      "kms:RevokeGrant"
                  ],
                  "Resource": "*",
                  "Condition": {
                      "Bool": {
                          "kms:GrantIsForAWSResource": "true"
                      }
                  }
              }
          ]
      }
      1 2
      ROSA クラスターの作成時に使用されるアカウント全体のロールの ARN を指定する必要があります。セクションに一覧表示される ARN はコンマで区切る必要があります。
    3. KMS キーポリシーに変更を適用します。

      $ aws kms put-key-policy --key-id <key_id_or_arn> \ 1
          --policy file://kms-key-policy.json \ 2
          --policy-name default
      1
      <key_id_or_arn> を KMS キーの ID または ARN に置き換えます。
      2
      ローカルファイルでキーポリシーを参照する場合は、file:// プレフィックスを含める必要があります。

      次の手順でクラスターを作成すると、KMS キーの ARN を参照できます。

  3. カスタムインストールオプションを使用して STS でクラスターを作成します。--interactive モードを使用して、カスタム設定を対話的に指定できます。

    $ rosa create cluster --interactive --sts

    出力例

    I: Interactive mode enabled.
    Any optional fields can be left empty and a default will be selected.
    ? Cluster name: <cluster_name>
    ? OpenShift version: 4.8.9 1
    I: Using arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Installer-Role for the Installer role 2
    I: Using arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-ControlPlane-Role for the ControlPlane role
    I: Using arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Worker-Role for the Worker role
    I: Using arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Support-Role for the Support role
    ? External ID (optional):
    ? Operator roles prefix: <cluster_name>-<random_string> 3
    ? Multiple availability zones (optional): No 4
    ? AWS region: us-east-1
    ? PrivateLink cluster (optional): No
    ? Install into an existing VPC (optional): No
    ? Enable Customer Managed key (optional): No 5
    ? Compute nodes instance type (optional):
    ? Enable autoscaling (optional): No
    ? Compute nodes: 2
    ? Machine CIDR: 10.0.0.0/16
    ? Service CIDR: 172.30.0.0/16
    ? Pod CIDR: 10.128.0.0/14
    ? Host prefix: 23
    ? Encrypt etcd data (optional): No 6
    ? Disable Workload monitoring (optional): No
    I: Creating cluster '<cluster_name>'
    I: To create this cluster again in the future, you can run:
       rosa create cluster --cluster-name <cluster_name> --role-arn arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Installer-Role --support-role-arn arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Support-Role --master-iam-role arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-ControlPlane-Role --worker-iam-role arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Worker-Role --operator-roles-prefix <cluster_name>-<random_string> --region us-east-1 --version 4.8.9 --compute-nodes 2 --machine-cidr 10.0.0.0/16 --service-cidr 172.30.0.0/16 --pod-cidr 10.128.0.0/14 --host-prefix 23 7
    I: To view a list of clusters and their status, run 'rosa list clusters'
    I: Cluster '<cluster_name>' has been created.
    I: Once the cluster is installed you will need to add an Identity Provider before you can login into the cluster. See 'rosa create idp --help' for more information.
    I: To determine when your cluster is Ready, run 'rosa describe cluster -c <cluster_name>'.
    I: To watch your cluster installation logs, run 'rosa logs install -c <cluster_name> --watch'.

    1
    クラスターの作成時に、一覧表示された OpenShift バージョン オプションには、4.8.9 などのメジャー、マイナー、およびパッチバージョンが含まれます。
    2
    クラスターバージョンのアカウントで、一致するアカウント全体のロールのセットが複数ある場合は、オプションのインタラクティブなリストが提供されます。
    3
    オプション: デフォルトでは、クラスター固有のオペレーターのロール名には、クラスター名とランダムな 4 桁のハッシュが接頭辞として付けられます。オプションで、ロール名の <cluster_name>-<hash> を置き換えるカスタム接頭辞を指定できます。接頭辞は、クラスター固有の Operator IAM ロールを作成するときに適用されます。接頭辞の詳細は、Operator IAM ロール接頭辞の定義を参照してください。
    4
    実稼働環境のワークロードには、複数のアベイラビリティーゾーンの使用が推奨されます。デフォルトは単一のアベイラビリティーゾーンです。
    5
    独自の AWS KMS キーを使用してコントロールプレーン、インフラストラクチャー、およびワーカーノードのルートボリュームを暗号化する場合は、このオプションを有効にします。前述の手順でアカウント全体のロール ARN を追加した KMS キーの ARN を指定します。
    6
    このオプションを有効にするのは、デフォルトで etcd ボリュームを暗号化するコントロールプレーンストレージ暗号化に加えて、etcd キー値の暗号化が必要なユースケースの場合のみです。このオプションを使用すると、etcd キーの値は暗号化されますが、キーは暗号化されません。
    重要

    etcd のキー値の etcd 暗号化を有効にすると、約 20% のパフォーマンスのオーバーヘッドが発生します。このオーバーヘッドは、etcd ボリュームを暗号化するデフォルトのコントロールプレーンのストレージ暗号化に加えて、この 2 つ目の暗号化レイヤーの導入により生じます。Red Hat は、お客様のユースケースで特に etcd 暗号化が必要な場合にのみ有効にすることを推奨します。

    7
    この出力には、今後も同じ設定でクラスターを作成するのに実行できるカスタムコマンドが含まれます。

    --interactive モードを使用する代わりに、rosa create cluster の実行時にカスタマイズオプションを直接指定できます。rosa create cluster --help を実行して、利用可能な CLI オプションの一覧を表示します。

    重要

    Operator IAM ロールおよび OpenID Connect (OIDC) プロバイダーを作成し、クラスターの状態を ready に移行するには、以下の手順を実行する必要があります。

  4. クラスター固有の Operator IAM ロールを作成します。

    1. 現在の作業ディレクトリーに Operator IAM ポリシー JSON ファイルを作成し、確認用に aws CLI コマンドを実行します。

      $ rosa create operator-roles --mode manual --cluster <cluster_name|cluster_id> 1
      1
      manual モードは、Operator ロールの作成に必要な aws CLI コマンドおよび JSON ファイルを生成します。確認後、手動でコマンドを実行してリソースを作成する必要があります。
    2. 確認後は、aws コマンドを手動で実行し、Operator IAM ロールを作成し、管理対象 Operator ポリシーをそれらに割り当てます。または、--mode auto を使用して前述のコマンドを実行して、aws コマンドを即座に実行できます。

      注記

      前の手順で接頭辞を指定した場合、カスタム接頭辞が Operator ロール名に適用されます。

  5. クラスター Operator が認証に使用する OpenID Connect (OIDC) プロバイダーを作成します。

    $ rosa create oidc-provider --mode auto --cluster <cluster_name|cluster_id> 1
    1
    auto モードは、OIDC プロバイダーを作成する aws CLI コマンドを即時実行します。
  6. クラスターのステータスを確認します。

    $ rosa describe cluster --cluster <cluster_name|cluster_id>

    出力例

    Name:                       <cluster_name>
    ID:                         <cluster_id>
    External ID:                <external_id>
    OpenShift Version:          <version>
    Channel Group:              stable
    DNS:                        <cluster_name>.xxxx.p1.openshiftapps.com
    AWS Account:                <aws_account_id>
    API URL:                    https://api.<cluster_name>.xxxx.p1.openshiftapps.com:6443
    Console URL:                https://console-openshift-console.apps.<cluster_name>.xxxx.p1.openshiftapps.com
    Region:                     <aws_region>
    Multi-AZ:                   false
    Nodes:
     - Master:                  3
     - Infra:                   2
     - Compute:                 2
    Network:
     - Service CIDR:            172.30.0.0/16
     - Machine CIDR:            10.0.0.0/16
     - Pod CIDR:                10.128.0.0/14
     - Host Prefix:             /23
    STS Role ARN:               arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Installer-Role
    Support Role ARN:           arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Support-Role
    Instance IAM Roles:
     - Master:                  arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-ControlPlane-Role
     - Worker:                  arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Worker-Role
    Operator IAM Roles:
     - arn:aws:iam::<aws_account_id>:role/<cluster_name>-xxxx-openshift-ingress-operator-cloud-credentials
     - arn:aws:iam::<aws_account_id>:role/<cluster_name-xxxx-openshift-cluster-csi-drivers-ebs-cloud-credent
     - arn:aws:iam::<aws_account_id>:role/<cluster_name-xxxx-openshift-machine-api-aws-cloud-credentials
     - arn:aws:iam::<aws_account_id>:role/<cluster_name-xxxx-openshift-cloud-credential-operator-cloud-crede
     - arn:aws:iam::<aws_account_id>:role/<cluster_name-xxxx-openshift-image-registry-installer-cloud-creden
    State:                      ready
    Private:                    No
    Created:                    Oct  1 2021 08:12:25 UTC
    Details Page:               https://console.redhat.com/openshift/details/s/<subscription_id>
    OIDC Endpoint URL:          https://rh-oidc.s3.<aws_region>.amazonaws.com/<cluster_id>

    以下の State フィールドの変更は、クラスターインストールの進捗として出力に表示されます。

    • waiting (Waiting for OIDC configuration)
    • pending (Preparing account)
    • installing (DNS setup in progress)
    • installing
    • ready

      注記

      インストールが失敗した場合や、約 40 分後に State フィールドが ready に変わらない場合は、インストールのトラブルシューティングに関するドキュメントで詳細を確認してください。詳細は、インストールのトラブルシューティングを参照してください。Red Hat サポートにサポートを依頼する手順は、Red Hat OpenShift Service on AWS のサポートを受けるを参照してください。

  7. OpenShift インストーラーログを監視して、クラスター作成の進捗を追跡します。

    $ rosa logs install --cluster <cluster_name|cluster_id> --watch 1
    1
    --watch フラグを指定して、新規ログメッセージをインストールの進捗として監視します。この引数は任意です。

2.4. 次のステップ

2.5. 関連情報

第3章 インタラクティブなクラスター作成モードリファレンス

このセクションでは、インタラクティブモードを使用して Red Hat OpenShift Service on AWS (ROSA) CLI (rosa) を使用してクラスターを作成するときに表示されるオプションの概要を説明します。

3.1. インタラクティブなクラスター作成モードオプションについて

インタラクティブモードを使用して AWS Security Token Service (STS) で Red Hat OpenShift Service on AWS クラスターを作成できます。rosa create cluster の実行時に --interactive オプションを指定することで、モードを有効にできます。以下の表は、インタラクティブモードのオプションを示しています。

表3.1 --interactive モードオプション

フィールド説明

Cluster name

クラスターの名前を入力します (例: my-rosa-cluster)。

Deploy cluster using AWS STS

AWS Security Token Service (STS) を使用して、コンポーネント固有の AWS Identity and Access Management (IAM) ロールについて一時的な制限付き権限の認証情報を割り当てる OpenShift クラスターを作成します。サービスを使用すると、クラスターコンポーネントはセキュアなクラウドリソース管理プラクティスを使用して AWS API 呼び出しを実行できます。デフォルトは Yes です。

OpenShift バージョン

インストールする OpenShift のバージョンを選択します (例: 4.3.12)。デフォルトは最新のバージョンです。

External ID (optional)

アカウントロールが仮定される際に OpenShift Cluster Manager および OpenShift インストーラーによって渡される一意の識別子を指定します。このオプションは、外部 ID を予想されるカスタムアカウントロールにのみ必要です。

Operator roles prefix

クラスター固有の Operator IAM ロールに割り当てるプレフィックスを入力します。デフォルトはクラスターの名前であり、4 桁のランダムな文字列です (例: my-rosa-cluster-a0b1)。

Multiple availability zones

クラスターを AWS リージョンの複数のアベイラビリティーゾーンにデプロイします。デフォルトは No で、クラスターは単一のアベイラビリティーゾーンにデプロイされます。クラスターを複数のアベイラビリティーゾーンにデプロイする場合、AWS リージョンには少なくとも 3 つのアベイラビリティーゾーンが必要です。実稼働環境のワークロードには、複数のアベイラビリティーゾーンの使用が推奨されます。

AWS region

クラスターをデプロイする AWS リージョンを指定します。これにより、AWS_REGION 環境変数が上書きされます。

PrivateLink cluster

AWS PrivateLink を使用してクラスターを作成します。このオプションは、トラフィックをパブリックインターネットに公開することなく、Virtual Private Cloud (VPC)、AWS サービス、およびオンプレミスネットワーク間のプライベート接続を提供します。サポートを提供するために、Red Hat Site Reliability Engineering (SRE) は AWS PrivateLink Virtual Private Cloud (VPC) エンドポイントを使用してクラスターに接続できます。このオプションは、クラスターの作成後に変更できません。デフォルトは No です。

Install into an existing VPC

クラスターを既存の AWS VPC にインストールします。このオプションを使用するには、VPC にはクラスターをインストールする各アベイラビリティーゾーンの 2 つのサブネットが必要です。デフォルトは No です。

Enable customer managed key

このオプションを有効にすると、特定の AWS Key Management Service (KMS) キーを永続データの暗号化キーとして使用できます。このキーは、コントロールプレーン、インフラストラクチャー、およびワーカーノードのルートボリュームの暗号化キーとして使用されます。これを無効にすると、永続データが常に暗号化されるように、指定されたリージョンのアカウント KMS キーがデフォルトで使用されます。デフォルトは No です。

Compute nodes instance type

コンピュートノードのインスタンスタイプを選択します。デフォルトは m5.xlarge です。

Enable autoscaling

コンピュートノードの自動スケーリングを有効にします。Autoscaler は、デプロイメントの需要に合わせてクラスターのサイズを調整します。デフォルトは No です。

Compute nodes

各アベイラビリティーゾーンにプロビジョニングするコンピュートノードの数を指定します。単一アベイラビリティーゾーンにデプロイされたクラスターには、2 つ以上のノードが必要です。複数のゾーンにデプロイされるクラスターには 3 つ以上のノードが必要です。ワーカーノードの最大数は 180 ノードです。デフォルト値は 2 です。

Machine CIDR

マシン (クラスターノード) の IP アドレス範囲を指定します。この IP アドレス範囲は、VPC サブネットのすべての CIDR アドレス範囲を包含する必要があります。サブネットは連続している必要があります。単一のアベイラビリティーゾーンデプロイメントでは、サブネットプレフィックス /25 を使用した 128 アドレスの最小 IP アドレス範囲がサポートされます。サブネットプレフィックス /24 を使用する最小アドレス範囲 256 アドレスの範囲は、複数のアベイラビリティーゾーンを使用するデプロイメントでサポートされます。デフォルトは 10.0.0.0/16 です。この範囲は、接続されているネットワークと競合しないようにする必要があります。

Service CIDR

サービスの IP アドレス範囲を指定します。範囲は、ワークロードに対応するのに十分な大きさである必要があります。アドレスブロックは、クラスター内からアクセスする外部サービスと重複してはいけません。デフォルトは 172.30.0.0/16 です。クラスター間で同じにすることをお勧めします。

Pod CIDR

Pod の IP アドレス範囲を指定します。範囲は、ワークロードに対応するのに十分な大きさである必要があります。アドレスブロックは、クラスター内からアクセスする外部サービスと重複してはいけません。デフォルトは 10.128.0.0/14 です。クラスター間で同じにすることをお勧めします。

Host prefix

個々のマシンにスケジューリングされた Pod に割り当てるサブネットプレフィックスの長さを指定します。ホストプレフィックスは、各マシンの Pod IP アドレスプールを決定します。例えば、ホストプレフィックスを /23 に設定した場合、各マシンには Pod CIDR アドレス範囲から /23 のサブネットが割り当てられます。デフォルトは /23 で、クラスターノード数は 512、ノードあたりの Pod 数は 512 となっていますが、いずれも当社がサポートする最大値を超えています。サポートされている最大値については、以下の関連情報のセクションを参照してください。

Encrypt etcd data (optional)

Red Hat Open Shift Service on AWS では、コントロールプレーンストレージはデフォルトで静止時に暗号化され、これには etcd ボリュームの暗号化も含まれます。さらに、Encrypt etcd data オプションを有効にすると、鍵ではなく、etcd 内の一部のリソースの鍵の値を暗号化することができます。

重要

etcd のキー値の etcd 暗号化を有効にすると、約 20% のパフォーマンスのオーバーヘッドが発生します。このオーバーヘッドは、etcd ボリュームを暗号化するデフォルトのコントロールプレーンのストレージ暗号化に加えて、この 2 つ目の暗号化レイヤーの導入により生じます。Red Hat は、お客様のユースケースで特に etcd 暗号化が必要な場合にのみ有効にすることを推奨します。

Disable workload monitoring

ユーザー定義プロジェクトの監視を無効にします。ユーザー定義プロジェクトの監視はデフォルトで有効にされます。

3.2. 関連情報

第5章 ROSA クラスターへのアクセス

アイデンティティープロバイダー (IDP) アカウントを使用して Red Hat OpenShift Service on AWS (ROSA) クラスターにアクセスすることが推奨されます。ただし、クラスターを作成したクラスター管理者は、クイックアクセス手順を使用してこれにアクセスできます。

本書では、クラスターにアクセスし、rosa CLI を使用して IDP を設定する方法を説明します。または、OpenShift Cluster Manager コンソールを使用して IDP アカウントを作成できます。

5.1. クラスターへの迅速なアクセス

この迅速なクイックアクセスを実行する手順を使用してクラスターにログインできます。

注記

ベストプラクティスとして、IDP アカウントを代わりに使用してクラスターにアクセスできます。

手順

  1. 以下のコマンドを実行します。

    $ rosa create admin --cluster=<cluster_name>

    出力例

    W: It is recommended to add an identity provider to login to this cluster. See 'rosa create idp --help' for more information.
    I: Admin account has been added to cluster 'cluster_name'. It may take up to a minute for the account to become active.
    I: To login, run the following command:
    oc login https://api.cluster-name.t6k4.i1.oragnization.org:6443 \
    --username cluster-admin \
    --password FWGYL-2mkJI-3ZTTZ-rINns

  2. 直前のコマンドの出力の oc login コマンド、ユーザー名、およびパスワードを入力します。

    出力例

    $ oc login https://api.cluster_name.t6k4.i1.oragnization.org:6443 \
    >  --username cluster-admin \
    >  --password FWGYL-2mkJI-3ZTTZ-rINns
    Login successful.                                                                                                                                                                                                                                                       You have access to 77 projects, the list has been suppressed. You can list all projects with ' projects'

  3. デフォルトプロジェクトを使用して、この oc コマンドを実行してクラスター管理者のアクセスが作成されていることを確認します。

    $ oc whoami

    出力例

    cluster-admin

5.2. IDP アカウントでのクラスターへのアクセス

クラスターにログインするには、アイデンティティープロバイダー (IDP) を設定できます。この手順では、IDP の例として GitHub を使用します。サポートされている他の IDP を表示するには、rosa create idp --help コマンドを実行します。

注記

または、クラスターを作成したユーザーとして、クイックアクセス手順を使用できます。

手順

IDP アカウントを使用してクラスターにアクセスするには、以下を実行します。

  1. IDP を追加します。

    1. 以下のコマンドは、GitHub がサポートする IDP を作成します。コマンドを実行後に、出力の対話式プロンプトに従って GitHub 開発者の設定にアクセスし、新規の OAuth アプリケーションを設定します。

      $ rosa create idp --cluster=<cluster_name> --interactive
    2. 以下の値を入力します。

      • アイデンティティープロバイダーのタイプ: github
      • メンバーの制限: organizations (GitHub Organization がない場合は、これを作成できます。)
      • GitHub Organization: rh-test-org (組織の名前を入力します)

      出力例

      I: Interactive mode enabled.
      Any optional fields can be left empty and a default will be selected.
      ? Type of identity provider: github
      ? Restrict to members of: organizations
      ? GitHub organizations: rh-test-org
      ? To use GitHub as an identity provider, you must first register the application:
        - Open the following URL:
          https://github.com/organizations/rh-rosa-test-cluster/settings/applications/new?oauth_application%5Bcallback_url%5D=https%3A%2F%2Foauth-openshift.apps.rh-rosa-test-cluster.z7v0.s1.devshift.org%2Foauth2callback%2Fgithub-1&oauth_application%5Bname%5D=rh-rosa-test-cluster-stage&oauth_application%5Burl%5D=https%3A%2F%2Fconsole-openshift-console.apps.rh-rosa-test-cluster.z7v0.s1.devshift.org
        - Click on 'Register application'
      ...

    3. 出力された URL に従い、Register application を選択すると、Git Hub の組織に新しい OAuth アプリケーションが登録されます。アプリケーションを登録することで、ROSA に内蔵されている OAuth サーバーが GitHub 組織のメンバーをクラスターに認証することができるようになります。

      注記

      GitHub フォーム Register a new OAuth application のフィールドには、rosa CLI ツールで定義された URL を介して、必要な値が自動的に入力されます。

    4. 作成した GitHub アプリケーションの情報を使用し、プロンプトを続行します。以下の値を入力します。

      • クライアント ID: <my_github_client_id>
      • クライアントシークレット: [? for help] <my_github_client_secret>
      • ホスト名: (オプション。一時的にブランクにしておくことができます)
      • マッピング方法: claim

      出力例

      ...
      ? Client ID: <my_github_client_id>
      ? Client Secret: [? for help] <my_github_client_secret>
      ? Hostname:
      ? Mapping method: claim
      I: Configuring IDP for cluster 'rh_rosa_test_cluster'
      I: Identity Provider 'github-1' has been created. You need to ensure that there is a list of cluster administrators defined. See 'rosa create user --help' for more information. To login into the console, open https://console-openshift-console.apps.rh-test-org.z7v0.s1.devshift.org and click on github-1

      IDP は、クラスター内で設定するのに 1 - 2 分かかる場合があります。

    5. 以下のコマンドを実行して、IDP が正しく設定されていることを確認します。

      $ rosa list idps --cluster=<cluster_name>

      出力例

      NAME        TYPE      AUTH URL
      github-1    GitHub    https://oauth-openshift.apps.rh-rosa-test-cluster1.j9n4.s1.devshift.org/oauth2callback/github-1

  2. クラスターにログインします。

    1. 以下のコマンドを実行して、クラスターの Console URL を取得します。

      $ rosa describe cluster --cluster=<cluster_name>

      出力例

      Name:        rh-rosa-test-cluster1
      ID:          1de87g7c30g75qechgh7l5b2bha6r04e
      External ID: 34322be7-b2a7-45c2-af39-2c684ce624e1
      API URL:     https://api.rh-rosa-test-cluster1.j9n4.s1.devshift.org:6443
      Console URL: https://console-openshift-console.apps.rh-rosa-test-cluster1.j9n4.s1.devshift.org
      Nodes:       Master: 3, Infra: 3, Compute: 4
      Region:      us-east-2
      State:       ready
      Created:     May 27, 2020

    2. Console URL に移動し、Github 認証情報を使用してログインします。
    3. OpenShift コンソールの右上で、名前をクリックして Copy Login Command をクリックします。
    4. 追加した IDP の名前 (この場合は github-1) を選択し、Display Token をクリックします。
    5. oc ログインコマンドをコピーし、これをターミナルに貼り付けます。

      $ oc login --token=z3sgOGVDk0k4vbqo_wFqBQQTnT-nA-nQLb8XEmWnw4X --server=https://api.rh-rosa-test-cluster1.j9n4.s1.devshift.org:6443

      出力例

      Logged into "https://api.rh-rosa-cluster1.j9n4.s1.devshift.org:6443" as "rh-rosa-test-user" using the token provided.
      
      You have access to 67 projects, the list has been suppressed. You can list all projects with 'oc projects'
      
      Using project "default".

    6. 単純な oc コマンドを実行して、すべての設定が適切でログインしていることを確認します。

      $ oc version

      出力例

      Client Version: 4.4.0-202005231254-4a4cd75
      Server Version: 4.3.18
      Kubernetes Version: v1.16.2

5.3. cluster-admin アクセス権限の付与

クラスターを作成したユーザーは、cluster-admin ユーザーロールをアカウントに追加して、これに最大の管理者権限を持たせることができます。このような権限は、クラスターの作成時に自動的にユーザーアカウントに割り当てられる訳ではありません。

さらに、クラスターを作成したユーザーのみが、他の cluster-admin または dedicated-admin ユーザーにクラスターアクセスを付与できます。dedicated-admin 権限を持つユーザーの権限は少なくなります。ベストプラクティスとして、cluster-admin ユーザーの数をできるだけ少ないに制限することができます。

前提条件

  • アイデンティティープロバイダー (IDP) をクラスターに追加している。
  • 作成するユーザーの IDP ユーザー名がある。
  • クラスターにログインしている。

手順

  1. ユーザーに cluster-admin 権限を付与します。

    $ rosa grant user cluster-admin --user=<idp_user_name> --cluster=<cluster_name>
  2. ユーザーがクラスター管理者として一覧表示されていることを確認します。

    $ rosa list users --cluster=<cluster_name>

    出力例

    GROUP             NAME
    cluster-admins    rh-rosa-test-user
    dedicated-admins  rh-rosa-test-user

  3. 以下のコマンドを実行して、ユーザーが cluster-admin アクセスを持つことを確認します。クラスター管理者はエラーを出さずにこのコマンドを実行できますが、専用の管理者は実行できません。

    $ oc get all -n openshift-apiserver

    出力例

    NAME                  READY   STATUS    RESTARTS   AGE
    pod/apiserver-6ndg2   1/1     Running   0          17h
    pod/apiserver-lrmxs   1/1     Running   0          17h
    pod/apiserver-tsqhz   1/1     Running   0          17h
    NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
    service/api   ClusterIP   172.30.23.241   <none>        443/TCP   18h
    NAME                       DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                     AGE
    daemonset.apps/apiserver   3         3         3       3            3           node-role.kubernetes.io/master=   18h

5.4. dedicated-admin アクセスの付与

クラスターを作成したユーザーのみが、他の cluster-admin または dedicated-admin ユーザーにクラスターアクセスを付与できます。dedicated-admin 権限を持つユーザーの権限は少なくなります。ベストプラクティスとして、dedicated-admin アクセスをほとんど管理者に付与することができます。

前提条件

  • アイデンティティープロバイダー (IDP) をクラスターに追加している。
  • 作成するユーザーの IDP ユーザー名がある。
  • クラスターにログインしている。

手順

  1. 以下のコマンドを実行して、ユーザーを dedicated-admin にプロモートします。

    $ rosa grant user dedicated-admin --user=<idp_user_name> --cluster=<cluster_name>
  2. 以下のコマンドを実行して、ユーザーに dedicated-admin アクセスがあることを確認します。

    $ oc get groups dedicated-admins

    出力例

    NAME               USERS
    dedicated-admins   rh-rosa-test-user

    注記

    Forbidden エラーは、dedicated-admin 権限を持たないユーザーがこのコマンドを実行する場合に表示されます。

5.5. 関連情報

第6章 STS のアイデンティティープロバイダーの設定

Red Hat OpenShift Service on AWS (ROSA) クラスターの作成後に、アイデンティティープロバイダーを設定して、ユーザーがクラスターにアクセスする方法を判別する必要があります。

以下のトピックでは、OpenShift Cluster Manager コンソールを使用してアイデンティティープロバイダーを設定する方法を説明します。または、rosa CLI を使用してアイデンティティープロバイダーを設定し、クラスターにアクセスできます。

6.1. アイデンティティープロバイダーについて

Red Hat OpenShift Service on AWS には、ビルトイン OAuth サーバーが含まれます。開発者および管理者は OAuth アクセストークンを取得して、API に対して認証します。管理者は、クラスターのインストール後に、OAuth をアイデンティティープロバイダーを指定するように設定できます。アイデンティティープロバイダーを設定すると、ユーザーはログインし、クラスターにアクセスできます。

6.1.1. サポートされるアイデンティティープロバイダー

以下の種類のアイデンティティープロバイダーを設定できます。

アイデンティティープロバイダー説明

GitHub または GitHub Enterprise

GitHub または GitHub Enterprise の OAuth 認証サーバーに対して、ユーザー名とパスワードを検証するように Github アイデンティティープロバイダーを設定します。

GitLab

GitLab.com またはその他の GitLab インスタンスをアイデンティティープロバイダーとして使用するように GitLab アイデンティティープロバイダーを設定します。

Google

Google の OpenID Connect 統合 を使用して Google アイデンティティープロバイダーを設定します。

LDAP

単純なバインド認証を使用して、LDAPv3 サーバーに対してユーザー名とパスワードを検証するように LDAP アイデンティティープロバイダーを設定します。

OpenID Connect

Authorization Code Flow を使用して OpenID Connect アイデンティティープロバイダーと統合するように OpenID Connect (OIDC) アイデンティティープロバイダーを設定します。

HTPasswd

単一の静的管理ユーザー用に HTPasswd アイデンティティープロバイダーを設定します。問題のトラブルシューティングを行うには、ユーザーとしてクラスターにログインできます。

重要

HTPasswd アイデンティティープロバイダーのオプションは、静的な管理者ユーザーを 1 つ作成するのを可能にするために含まれています。Htpasswd は、Red Hat OpenShift Service on AWS の一般使用向けのアイデンティティープロバイダーとしてはサポートされていません。単一ユーザーを設定する手順は、HTPasswd アイデンティティープロバイダーの設定 を参照してください。

6.1.2. アイデンティティープロバイダーパラメーター

以下のパラメーターは、すべてのアイデンティティープロバイダーに共通するパラメーターです。

パラメーター説明

name

プロバイダー名は、プロバイダーのユーザー名にプレフィックスとして付加され、アイデンティティー名が作成されます。

mappingMethod

新規アイデンティティーがログイン時にユーザーにマップされる方法を定義します。以下の値のいずれかを入力します。

claim
デフォルトの値です。アイデンティティーの推奨ユーザー名を持つユーザーをプロビジョニングします。そのユーザー名を持つユーザーがすでに別のアイデンティティーにマッピングされている場合は失敗します。
lookup
既存のアイデンティティー、ユーザーアイデンティティーマッピング、およびユーザーを検索しますが、ユーザーまたはアイデンティティーの自動プロビジョニングは行いません。これにより、クラスター管理者は手動で、または外部のプロセスを使用してアイデンティティーとユーザーを設定できます。この方法を使用する場合は、ユーザーを手動でプロビジョニングする必要があります。
generate
アイデンティティーの推奨ユーザー名を持つユーザーをプロビジョニングします。推奨ユーザー名を持つユーザーがすでに既存のアイデンティティーにマッピングされている場合は、一意のユーザー名が生成されます。例: myuser2この方法は、Red Hat OpenShift Service on AWS のユーザー名とアイデンティティープロバイダーのユーザー名との正確な一致を必要とする外部プロセス (LDAP グループ同期など) と組み合わせて使用することはできません。
add
アイデンティティーの推奨ユーザー名を持つユーザーをプロビジョニングします。推奨ユーザー名を持つユーザーがすでに存在する場合、アイデンティティーは既存のユーザーにマッピングされ、そのユーザーの既存のアイデンティティーマッピングに追加されます。これは、同じユーザーセットを識別して同じユーザー名にマッピングするアイデンティティープロバイダーが複数設定されている場合に必要です。
注記

mappingMethod パラメーターを add に設定すると、アイデンティティープロバイダーの追加または変更時に新規プロバイダーのアイデンティティーを既存ユーザーにマッピングできます。

6.2. GitHub アイデンティティープロバイダーの設定

GitHub アイデンティティープロバイダーを、GitHub または GitHub Enterprise の OAuth 認証サーバーに対してユーザー名とパスワードを検証し、Red Hat OpenShift Service on AWS クラスターにアクセスするように設定します。OAuth は Red Hat OpenShift Service on AWS と GitHub または GitHub Enterprise 間のトークン交換フローを容易にします。

警告

GitHub 認証を設定することによって、ユーザーは GitHub 認証情報を使用して Red Hat OpenShift Service on AWS にログインできます。GitHub ユーザー ID を持つすべてのユーザーが Red Hat OpenShift Service on AWS クラスターにログインできないようにするために、アクセスを特定の GitHub 組織のユーザーに制限する必要があります。

前提条件

手順

  1. OpenShift Cluster Manager から、Clusters ページに移動し、アイデンティティープロバイダーを設定する必要のあるクラスターを選択します。
  2. Access control タブをクリックします。
  3. Add identity provider をクリックします。

    注記

    クラスターの作成後に表示される警告メッセージの Add Oauth 設定リンクをクリックして、アイデンティティープロバイダーを設定することもできます。

  4. ドロップダウンメニューから GitHub を選択します。
  5. アイデンティティープロバイダーの一意の名前を入力します。この名前は後で変更することはできません。

    • OAuth callback URL は提供されるフィールドに自動的に生成されます。これを使用して GitHub アプリケーションを登録します。

      https://oauth-openshift.apps.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>

      以下は例になります。

      https://oauth-openshift.apps.openshift-cluster.example.com/oauth2callback/github
  6. アプリケーションを GitHub に登録します
  7. Red Hat OpenShift Service on AWS に戻り、ドロップダウンメニューからマッピング方法を選択します。ほとんどの場合、Claim の使用が推奨されます。
  8. GitHub が提供する Client ID および Client secret を入力します。
  9. hostname を入力します。GitHub Enterprise のホストされているインスタンスを使用する場合は、ホスト名を入力する必要があります。
  10. オプション: 認証局 (CA) ファイルを使用して、設定された GitHub Enterprise URL のサーバー証明書を検証できます。Browse をクリックして CA ファイルを見つけ、これをアイデンティティープロバイダーに割り当てます。
  11. Use organizations または Use teams を選択し、アクセスを特定の GitHub Organization または GitHub チームに制限します。
  12. アクセスを制限する組織またはチームの名前を入力します。Add more をクリックして、ユーザーを所属させる複数の組織またはチームを指定します。
  13. Confirm をクリックします。

検証

  • 設定されたアイデンティティープロバイダーが Clusters ページの Access control タブに表示されるようになりました。

6.3. GitLab アイデンティティープロバイダーの設定

GitLab.com またはその他の GitLab インスタンスをアイデンティティープロバイダーとして使用するように GitLab アイデンティティープロバイダーを設定します。

前提条件

  • GitLab バージョン 7.7.0 から 11.0 を使用する場合は、OAuth 統合 を使用して接続します。GitLab バージョン 11.1 以降の場合、OAuth ではなく OpenID Connect (OIDC) を使用して接続します。

手順

  1. OpenShift Cluster Manager から、Clusters ページに移動し、アイデンティティープロバイダーを設定する必要のあるクラスターを選択します。
  2. Access control タブをクリックします。
  3. Add identity provider をクリックします。

    注記

    クラスターの作成後に表示される警告メッセージの Add Oauth 設定リンクをクリックして、アイデンティティープロバイダーを設定することもできます。

  4. ドロップダウンメニューから GitLab を選択します。
  5. アイデンティティープロバイダーの一意の名前を入力します。この名前は後で変更することはできません。

    • OAuth callback URL は提供されるフィールドに自動的に生成されます。この URL を GitLab に指定します。

      https://oauth-openshift.apps.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>

      以下は例になります。

      https://oauth-openshift.apps.openshift-cluster.example.com/oauth2callback/gitlab
  6. GitLab に新規アプリケーションを追加します
  7. Red Hat OpenShift Service on AWS に戻り、ドロップダウンメニューからマッピング方法を選択します。ほとんどの場合、Claim の使用が推奨されます。
  8. GitLab が提供する Client ID および Client secret を入力します。
  9. GitLab プロバイダーの URL を入力します。
  10. オプション: 認証局 (CA) ファイルを使用して、設定された GitLab URL のサーバー証明書を検証できます。Browse をクリックして CA ファイルを見つけ、これをアイデンティティープロバイダーに割り当てます。
  11. Confirm をクリックします。

検証

  • 設定されたアイデンティティープロバイダーが Clusters ページの Access control タブに表示されるようになりました。

6.4. Google アイデンティティープロバイダーの設定

Google アイデンティティープロバイダーを、ユーザーが Google 認証情報で認証できるように設定します。

警告

Google をアイデンティティープロバイダーとして使用することで、Google ユーザーはサーバーに対して認証されます。hostedDomain 設定属性を使用して、特定のホストドメインのメンバーに認証を限定することができます。

手順

  1. OpenShift Cluster Manager から、Clusters ページに移動し、アイデンティティープロバイダーを設定する必要のあるクラスターを選択します。
  2. Access control タブをクリックします。
  3. Add identity provider をクリックします。

    注記

    クラスターの作成後に表示される警告メッセージの Add Oauth 設定リンクをクリックして、アイデンティティープロバイダーを設定することもできます。

  4. ドロップダウンメニューから Google を選択します。
  5. アイデンティティープロバイダーの一意の名前を入力します。この名前は後で変更することはできません。

    • OAuth callback URL は提供されるフィールドに自動的に生成されます。この URL を Google に指定します。

      https://oauth-openshift.apps.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>

      以下は例になります。

      https://oauth-openshift.apps.openshift-cluster.example.com/oauth2callback/github
  6. Google の OpenID Connect 統合 を使用して Google アイデンティティープロバイダーを設定します。
  7. Red Hat OpenShift Service on AWS に戻り、ドロップダウンメニューからマッピング方法を選択します。ほとんどの場合、Claim の使用が推奨されます。
  8. 登録済みの Google プロジェクトの Client ID と、Google が発行する Client secret を入力します。
  9. ホストされているドメインを入力して、ユーザーを Google Apps ドメインに制限します。
  10. Confirm をクリックします。

検証

  • 設定されたアイデンティティープロバイダーが Clusters ページの Access control タブに表示されるようになりました。

6.5. LDAP アイデンティティープロバイダーの設定

単純なバインド認証を使用して LDAPv3 サーバーに対してユーザー名とパスワードを検証するように LDAP アイデンティティープロバイダーを設定します。

前提条件

  • LDAP アイデンティティープロバイダーを設定する場合は、設定済みの LDAP URL を入力する必要があります。設定される URL は、LDAP ホストと使用する検索パラメーターを指定する RFC 2255 URL です。URL の構文は以下のようになります。

    ldap://host:port/basedn?attribute?scope?filter
    URL コンポーネント説明

    ldap

    通常の LDAP の場合は、文字列 ldap を使用します。セキュアな LDAP (LDAPS) の場合は、代わりに ldaps を使用します。

    host:port

    LDAP サーバーの名前とポートです。デフォルトは、ldap の場合は localhost:389、LDAPS の場合は localhost:636 です。

    basedn

    すべての検索が開始されるディレクトリーのブランチの DN です。これは少なくともディレクトリーツリーの最上位になければなりませんが、ディレクトリーのサブツリーを指定することもできます。

    attribute

    検索対象の属性です。RFC 2255 はカンマ区切りの属性の一覧を許可しますが、属性をどれだけ指定しても最初の属性のみが使用されます。属性を指定しない場合は、デフォルトで uid が使用されます。使用しているサブツリーのすべてのエントリー間で一意の属性を選択することを推奨します。

    scope

    検索の範囲です。one または sub のいずれかを指定できます。範囲を指定しない場合は、デフォルトの範囲として sub が使用されます。

    filter

    有効な LDAP 検索フィルターです。指定しない場合、デフォルトは (objectClass=*) です。

    検索の実行時に属性、フィルター、指定したユーザー名が組み合わされて以下のような検索フィルターが作成されます。

    (&(<filter>)(<attribute>=<username>))
    重要

    LDAP ディレクトリーの検索に認証が必要な場合は、エントリー検索の実行に使用する bindDNbindPassword を指定します。

手順

  1. OpenShift Cluster Manager から、Clusters ページに移動し、アイデンティティープロバイダーを設定する必要のあるクラスターを選択します。
  2. Access control タブをクリックします。
  3. Add identity provider をクリックします。

    注記

    クラスターの作成後に表示される警告メッセージの Add Oauth 設定リンクをクリックして、アイデンティティープロバイダーを設定することもできます。

  4. ドロップメニューから LDAP を選択します。
  5. アイデンティティープロバイダーの一意の名前を入力します。この名前は後で変更することはできません。
  6. ドロップダウンメニューからマッピング方法を選択します。ほとんどの場合、Claim の使用が推奨されます。
  7. LDAP URL を入力して、使用する LDAP 検索パラメーターを指定します。
  8. オプション: Bind DN および Bind password を入力します。
  9. LDAP 属性をアイデンティティーにマップする属性を入力します。

    • ユーザー ID の値として使用する ID 属性を入力します。Add more をクリックして、複数の ID 属性を追加します。
    • オプション: 表示名の値として使用する Preferred username 属性を入力します。Add more をクリックして、優先する複数のユーザー名の属性を追加します。
    • オプション: メールアドレスの値として使用する Email 属性を入力します。Add more をクリックして、複数のメール属性を追加します。
  10. オプション: Show advanced Options をクリックし、認証局 (CA) ファイルを LDAP アイデンティティープロバイダーに追加し、設定された URL のサーバー証明書を検証します。Browse をクリックして CA ファイルを見つけ、これをアイデンティティープロバイダーに割り当てます。
  11. オプション: 高度なオプションで、LDAP プロバイダーを Insecure (非セキュア) にするよう選択します。このオプションを選択すると、CA ファイルは使用できません。

    重要

    非セキュアな LDAP 接続(ldap:// またはポート 389)を使用している場合は、設定ウィザードで で Insecure オプションを確認する必要があります。

  12. Confirm をクリックします。

検証

  • 設定されたアイデンティティープロバイダーが Clusters ページの Access control タブに表示されるようになりました。

6.6. OpenID アイデンティティープロバイダーの設定

OpenID アイデンティティープロバイダーを、 Authorization Code Flow を使用して OpenID Connect アイデンティティープロバイダーに統合するように設定します。

重要

Red Hat OpenShift Service on AWS の認証 Operator では、設定済みの OpenID Connect アイデンティティープロバイダーが OpenID Connect Discovery 仕様を実装する必要があります。

要求は、OpenID アイデンティティープロバイダーから返される JWT id_token から読み取られ、指定される場合は発行者 URL によって返される JSON から読み取られます。

1 つ以上の要求をユーザーのアイデンティティーを使用するように設定される必要があります。

また、どの要求をユーザーの推奨ユーザー名、表示名およびメールアドレスとして使用するか指定することができます。複数の要求が指定されている場合、値が入力されている最初の要求が使用されます。標準の要求は以下の通りです。

要求説明

preferred_username

ユーザーのプロビジョニング時に優先されるユーザー名です。janedoe などのユーザーを参照する際に使用する省略形の名前です。通常は、ユーザー名またはメールなどの、認証システムのユーザーのログインまたはユーザー名に対応する値です。

email

メールアドレス。

name

表示名。

詳細は、OpenID claim のドキュメント を参照してください。

前提条件

  • OpenID Connect を設定する前に、Red Hat OpenShift Service on AWS クラスターで使用する Red Hat 製品またはサービスのインストール前提条件を確認してください。

手順

  1. OpenShift Cluster Manager から、Clusters ページに移動し、アイデンティティープロバイダーを設定する必要のあるクラスターを選択します。
  2. Access control タブをクリックします。
  3. Add identity provider をクリックします。

    注記

    クラスターの作成後に表示される警告メッセージの Add Oauth 設定リンクをクリックして、アイデンティティープロバイダーを設定することもできます。

  4. ドロップダウンメニューから OpenID を選択します。
  5. アイデンティティープロバイダーの一意の名前を入力します。この名前は後で変更することはできません。

    • OAuth callback URL は提供されるフィールドに自動的に生成されます。

      https://oauth-openshift.apps.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>

      以下は例になります。

      https://oauth-openshift.apps.openshift-cluster.example.com/oauth2callback/openid
  6. Authorization Code Flow を使用して承認リクエストを作成します
  7. Red Hat OpenShift Service on AWS に戻り、ドロップダウンメニューからマッピング方法を選択します。ほとんどの場合、Claim の使用が推奨されます。
  8. OpenID から提供される Client ID および Client secret を入力します。
  9. Issuer URL を入力します。これは、OpenID プロバイダーが発行者 ID としてアサートする URL です。URL クエリーパラメーターまたはフラグメントのない https スキームを使用する必要があります。
  10. メールアドレスの値として使用する Email 属性を入力します。Add more をクリックして、複数のメール属性を追加します。
  11. 優先するユーザー名の値として使用する Name 属性を入力します。Add more をクリックして、優先する複数のユーザー名を追加します。
  12. 表示名の値として使用する Preferred username 属性を入力します。Add more をクリックして、複数の表示名を追加します。
  13. オプション: Show advanced Options をクリックして認証局 (CA) ファイルを OpenID アイデンティティープロバイダーに追加します。
  14. オプション: Additional scopes (追加の範囲) を追加できます。デフォルトで、OpenID の範囲が求められます。
  15. Confirm をクリックします。

検証

  • 設定されたアイデンティティープロバイダーが Clusters ページの Access control タブに表示されるようになりました。

6.7. HTPasswd アイデンティティープロバイダーの設定

クラスター管理者権限で単一の静的ユーザーを作成するように HTPasswd アイデンティティープロバイダーを設定します。問題のトラブルシューティングを行うには、ユーザーとしてクラスターにログインできます。

重要

HTPasswd アイデンティティープロバイダーのオプションは、静的な管理者ユーザーを 1 つ作成するのを可能にするために含まれています。Htpasswd は、Red Hat OpenShift Service on AWS の一般使用向けのアイデンティティープロバイダーとしてはサポートされていません。

手順

  1. OpenShift Cluster Manager から、Clusters ページに移動し、クラスターを選択します。
  2. Access controlIdentity providers の順に選択します。
  3. Add identity provider をクリックします。
  4. Identity Provider ドロップダウンメニューから HTPasswd を選択します。
  5. アイデンティティープロバイダーの Name フィールドに一意の名前を追加します。
  6. 静的ユーザーに推奨されるユーザー名およびパスワードを使用するか、独自のユーザー名およびパスワードを作成します。

    注記

    この手順で定義した認証情報は、以下の手順で Add を選択した後に表示されません。認証情報を失った場合は、アイデンティティープロバイダーを再作成し、認証情報を再度定義する必要があります。

  7. Add を選択して HTPasswd アイデンティティープロバイダーおよび単一の静的ユーザーを作成します。
  8. クラスターを管理する静的ユーザーにパーミッションを付与します。

    1. Access controlCluster Roles and Access で、Add user を選択します。
    2. 前のステップで作成した静的ユーザーの User ID を入力します。
    3. グループ を選択します。dedicated-admins グループのユーザーには、Red Hat OpenShift Service on AWS の標準の管理者権限があります。cluster-admins グループのユーザーには、クラスターへの完全な管理アクセス権限があります。
    4. Add user を選択して、管理者権限をユーザーに付与します。

検証

  • 設定された HTPasswd アイデンティティープロバイダーは、Access controlIdentity providers ページに表示されます。

    注記

    アイデンティティープロバイダーの作成後に、同期は通常 2 分以内に完了します。HTPasswd アイデンティティープロバイダーが利用可能になると、ユーザーとしてクラスターにログインできます。

  • 管理ユーザーは、Access controlCluster Roles and Access ページで確認できます。ユーザーの管理グループメンバーシップも表示されます。

6.8. 関連情報

第7章 ROSA クラスターへのアクセスの取り消し

IDP (アイデンティティプロバイダー) は、Red Hat OpenShift Service on AWS (ROSA) クラスターへのアクセスを制御します。ユーザーのクラスターへのアクセスを取り消すには、認証用に設定された IDP 内で設定する必要があります。

7.1. rosa CLI を使用した管理者アクセスの取り消し

ユーザーの管理者権限を取り消して、管理者権限がなくてもクラスターにアクセスできるようにすることができます。ユーザーの管理者アクセスを削除するには、dedicated-admin または cluster-admin の権限を取り消す必要があります。管理者権限を取り消すには、rosa コマンドラインユーティリティーを使用するか、Open Shift Cluster Manager コンソールを使用します。

7.1.1. rosa CLI を使用した dedicated-admin アクセスの取り消し

dedicated-admin ユーザーのアクセス権を取り消すことができるのは、自分がクラスターを作成したユーザー、組織管理者ユーザー、またはスーパー管理者ユーザーの場合です。

前提条件

  • アイデンティティープロバイダー (IDP) をクラスターに追加している。
  • 取り消す権限を持つユーザーの IDP ユーザー名がある。
  • クラスターにログインしている。

手順

  1. ユーザーの dedicated-admin アクセスを取り消すには、次のコマンドを入力してください。

    $ rosa revoke user dedicated-admin --user=<idp_user_name> --cluster=<cluster_name>
  2. 以下のコマンドを実行して、ユーザーに dedicated-admin アクセスがなくなったことを確認します。出力には、取り消したユーザーが表示されません。

    $ oc get groups dedicated-admins

7.1.2. rosa CLI を使用した cluster-admin アクセス権の取り消し

クラスターを作成したユーザーのみが、cluster-admin ユーザーのアクセスを取り消すことができます。

前提条件

  • アイデンティティープロバイダー (IDP) をクラスターに追加している。
  • 取り消す権限を持つユーザーの IDP ユーザー名がある。
  • クラスターにログインしている。

手順

  1. ユーザーの cluster-admin アクセスを取り消すには、次のコマンドを入力してください。

    $ rosa revoke user cluster-admins --user=myusername --cluster=mycluster
  2. 次のコマンドを入力して、そのユーザーが cluster-admin アクセス権を失ったことを確認します。出力には、取り消したユーザーが表示されません。

    $ oc get groups cluster-admins

7.2. OpenShift Cluster Manager コンソールを使用した管理者アクセスの取り消し

OpenShift Cluster Manager のコンソールから、ユーザーの dedicated-admin または cluster-admin アクセスを取り消すことができます。ユーザーは、管理者権限がなくてもクラスターにアクセスできるようになります。

前提条件

  • アイデンティティープロバイダー (IDP) をクラスターに追加している。
  • 取り消す権限を持つユーザーの IDP ユーザー名がある。
  • クラスターの作成に使用した OpenShift Cluster Manager アカウント、組織の管理者ユーザー、またはスーパーユーザーを使用して OpenShift Cluster Manager コンソールにログインしている。

手順

  1. OpenShift Cluster Manager の Clusters タブで、クラスターの名前を選択し、クラスターの詳細を表示します。
  2. Access control > Cluster Roles and Access を選択します。
  3. 削除するユーザーについて、ユーザーとグループの組み合わせの右にある Options メニュー kebab をクリックし、Delete をクリックします。

第8章 ROSA クラスターの削除

このドキュメントでは、AWS Security Token Service (STS) を使用する Red Hat OpenShift Service on AWS (ROSA) クラスターを削除する手順について説明します。クラスターを削除した後、クラスターで使用されている AWS Identity and Access Management (IAM) リソースを削除することもできます。

8.1. 前提条件

  • Red Hat OpenShift Service on AWS が VPC を作成した場合は、クラスターを正常に削除する前に、クラスターから次のアイテムを削除する必要があります。

    • VPN 構成や VPC ピアリング接続などのネットワーク構成
    • VPC に追加された追加サービス

これらの構成とサービスが残っている場合、クラスターは適切に削除されません。

8.2. ROSA クラスターとクラスター固有の IAM リソースの削除

ROSA CLI (rosa) または Red Hat OpenShift Cluster Manager を使用して、AWS Security Token Service (STS) クラスターを備えた Red Hat OpenShift Service on AWS (ROSA) を削除できます。

クラスターを削除した後、ROSA CLI (rosa) を使用して、AWS アカウントのクラスター固有の Identity and Access Management (IAM) リソースをクリーンアップできます。クラスター固有のリソースには、Operator ロールと OpenID Connect (OIDC) プロバイダーが含まれます。

重要

IAM リソースは、クラスターの削除およびクリーンアップのプロセスで使用されるため、クラスターの削除は、IAM リソースを削除する前に完了する必要があります。

アドオンがインストールされている場合、クラスターの削除前にアドオンをアンインストールするため、削除により多くの時間がかかります。所要時間は、アドオンの数とサイズによって異なります。

前提条件

  • ROSA クラスターをインストールしました。
  • インストールホストに、最新の ROSA CLI (rosa) をインストールして設定している。

手順

  1. クラスター ID、クラスター固有 Operator ロールの Amazon Resource Names (ARN)、および OIDC プロバイダーのエンドポイント URL を取得します。

    $ rosa describe cluster --cluster=<cluster_name> 1
    1
    <cluster_name> は、クラスター名に置き換えます。

    出力例

    Name:                       mycluster
    ID:                         1s3v4x39lhs8sm49m90mi0822o34544a 1
    ...
    Operator IAM Roles: 2
     - arn:aws:iam::<aws_account_id>:role/mycluster-x4q9-openshift-machine-api-aws-cloud-credentials
     - arn:aws:iam::<aws_account_id>:role/mycluster-x4q9-openshift-cloud-credential-operator-cloud-crede
     - arn:aws:iam::<aws_account_id>:role/mycluster-x4q9-openshift-image-registry-installer-cloud-creden
     - arn:aws:iam::<aws_account_id>:role/mycluster-x4q9-openshift-ingress-operator-cloud-credentials
     - arn:aws:iam::<aws_account_id>:role/mycluster-x4q9-openshift-cluster-csi-drivers-ebs-cloud-credent
     - arn:aws:iam::<aws_account_id>:role/mycluster-x4q9-openshift-cloud-network-config-controller-cloud
    State:                      ready
    Private:                    No
    Created:                    May 13 2022 11:26:15 UTC
    Details Page:               https://console.redhat.com/openshift/details/s/296kyEFwzoy1CREQicFRdZybrc0
    OIDC Endpoint URL:          https://rh-oidc.s3.us-east-1.amazonaws.com/1s5v4k39lhm8sm59m90mi0822o31844a 3

    1
    クラスター ID を一覧表示します。
    2
    クラスター固有の Operator ロールの ARN を指定します。たとえば、サンプル出力では、Machine Config Operator に必要なロールの ARN は arn:aws:iam::<aws_account_id>:role/mycluster-x4q9-openshift-machine-api-aws-cloud-credentials です。
    3
    クラスター固有の OIDC プロバイダーのエンドポイント URL を指定します。
    重要

    クラスターが削除された後、ROSA CLI (rosa) を使用してクラスター固有の STS リソースを削除するには、クラスター ID が必要です。

  2. クラスターを削除します。

    • Red Hat OpenShift Cluster Manager を使用してクラスターを削除するには:

      1. OpenShift Cluster Manager に移動します。
      2. クラスターの横にあるオプションメニューをクリックし kebabDelete cluster を選択します。
      3. プロンプトでクラスターの名前を入力し、Delete をクリックします。
    • ROSA CLI (rosa) を使用してクラスターを削除するには:

      1. 以下のコマンドを実行してクラスターを削除し、ログを監視し、<my-cluster> はクラスターの名前または ID に置き換えます。

        $ rosa delete cluster --cluster=<cluster_name> --watch
        重要

        Operator ロールと OIDC プロバイダーを削除する前に、クラスターの削除が完了するのを待つ必要があります。クラスター固有の Operator ロールは、OpenShift Operator によって作成されるリソースをクリーンアップするために必要です。Operator は、OIDC プロバイダーを利用して認証を行います。

  3. クラスター Operator が認証に使用する OIDC プロバイダーを削除します。

    $ rosa delete oidc-provider -c <cluster_id> --mode auto 1
    1
    <cluster_id> をクラスターの ID に置き換えてください。
    注記

    -y オプションを使用すると、プロンプトに対して自動的に「はい」と答えることができます。

  4. クラスター固有の Operator IAM ロールを削除します。

    $ rosa delete operator-roles -c <cluster_id> --mode auto 1
    1
    <cluster_id> をクラスターの ID に置き換えてください。

その他のリソース

8.3. アカウント全体の IAM リソースを削除する

アカウント全体の AWS Identity and Access Management (IAM) リソースに依存する AWS Security Token Services (STS) クラスターを使用してすべての Red Hat OpenShift Service on AWS (ROSA) を削除した後、アカウント全体のリソースを削除できます。

Red Hat OpenShift Cluster Manager を使用して STS クラスターで ROSA をインストールする必要がなくなった場合は、OpenShift Cluster Manager とユーザー IAM ロールを削除することもできます。

重要

アカウント全体の IAM ロールおよびポリシーは、同じ AWS アカウントの他の ROSA クラスターによって使用される可能性があります。他のクラスターで必要とされていない場合に限り、リソースを削除する必要があります。

OpenShift Cluster Manager を使用して同じ AWS アカウントに他の ROSA クラスターをインストールおよび管理する場合は、OpenShift Cluster Manager とユーザー IAM ロールが必要です。OpenShift Cluster Manager を使用してアカウントに ROSA クラスターをインストールする必要がなくなった場合にのみ、ロールを削除する必要があります。

8.3.1. アカウント全体の IAM ロールとポリシーの削除

このセクションでは、STS デプロイメントで ROSA 用に作成したアカウント全体の IAM ロールおよびポリシーを削除する手順について説明します。また、アカウント全体の Operator ポリシーと共にこれを実行します。アカウント全体の AWS Identityentityand Access Management (IAM) のロールとポリシーを削除できるのは、それらに依存する AWS Security Token Services (STS) クラスターを備えたすべての Red Hat OpenShift Service on AWS (ROSA) を削除した後でのみです。

重要

アカウント全体の IAM ロールおよびポリシーは、同じ AWS アカウントの他の ROSA クラスターによって使用される可能性があります。他のクラスターで必要とされていない場合に限り、ロールを削除する必要があります。

前提条件

  • ROSA クラスターをインストールしました。
  • インストールホストに、最新の ROSA CLI (rosa) をインストールして設定している。

手順

  1. アカウント全体のロールを削除します。

    1. ROSA CLI (rosa) を使用して、AWS アカウントのアカウント全体のロールを一覧表示します。

      $ rosa list account-roles

      出力例

      I: Fetching account roles
      ROLE NAME                           ROLE TYPE      ROLE ARN                                                           OPENSHIFT VERSION
      ManagedOpenShift-ControlPlane-Role  Control plane  arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-ControlPlane-Role  4.10
      ManagedOpenShift-Installer-Role     Installer      arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Installer-Role     4.10
      ManagedOpenShift-Support-Role       Support        arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Support-Role       4.10
      ManagedOpenShift-Worker-Role        Worker         arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Worker-Role        4.10

    2. アカウント全体のロールを削除します。

      $ rosa delete account-roles --prefix <prefix> --mode auto 1
      1
      その際、--<prefix> 引数を含める必要があります。<prefix> を削除するアカウント全体のロールのプレフィックスに置き換えてください。アカウント全体のロールを作成したときにカスタムプレフィックスを指定しなかった場合は、デフォルトのプレフィックスである ManagedOpenShift を指定します。
      重要

      アカウント全体の IAM ロールは、同じ AWS アカウント内の他の ROSA クラスターによって使用される場合があります。他のクラスターで必要とされていない場合に限り、ロールを削除する必要があります。

  2. アカウント全体のインラインポリシーと Operator ポリシーを削除します。

    1. AWS IAM ConsolePolicies ページで、アカウント全体のロールとポリシーを作成したときに指定した接頭辞でポリシーのリストをフィルタリングします。

      注記

      アカウント全体のロールを作成したときにカスタムプレフィックスを指定しなかった場合は、デフォルトのプレフィックスである ManagedOpenShift を検索します。

    2. AWS IAM Console を使用して、アカウント全体のインラインポリシーと Operator ポリシーを削除します。AWS IAM コンソールを使用して IAM ポリシーを削除する方法の詳細は、AWS ドキュメントの IAM ポリシーの削除を参照してください。

      重要

      アカウント全体のインラインおよび Operator IAM ポリシーは、同じ AWS アカウント内の他の ROSA クラスターによって使用される場合があります。他のクラスターで必要とされていない場合に限り、ロールを削除する必要があります。

8.3.2. OpenShift Cluster Manager およびユーザー IAM ロールのリンク解除と削除

Red Hat OpenShift Cluster Manager を使用して Red Hat OpenShift Service on AWS (ROSA) クラスターをインストールした場合は、OpenShift Cluster Manager とユーザー ID およびアクセス管理 (IAM) のロールを作成し、それらを RedHat 組織にリンクしました。クラスターを削除した後、ROSA CLI (rosa) を使用して、ロールのリンクを解除して削除できます。

重要

OpenShift Cluster Manager を使用して同じ AWS アカウントに他の ROSA クラスターをインストールおよび管理する場合は、OpenShift Cluster Manager とユーザー IAM ロールが必要です。OpenShift Cluster Manager を使用して ROSA クラスターをインストールする必要がなくなった場合にのみ、ロールを削除する必要があります。

前提条件

  • OpenShift Cluster Manager とユーザー IAM ロールを作成し、それらを Red Hat 組織にリンクしました。
  • インストールホストに、最新の ROSA CLI (rosa) をインストールして設定している。
  • Red Hat 組織で組織管理者権限があります。

手順

  1. Red Hat 組織から OpenShift Cluster Manager IAM ロールのリンクを解除し、ロールを削除します。

    1. AWS アカウントで OpenShift Cluster Manager IAM ロールを一覧表示します。

      $ rosa list ocm-roles

      出力例

      I: Fetching ocm roles
      ROLE NAME                           ROLE ARN                                                                      LINKED  ADMIN
      ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>  arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>  Yes     Yes

    2. OpenShift Cluster Manager IAM ロールが上記のコマンドの出力にリンクされていると表示されている場合は、Red Hat 組織からロールのリンクを解除します。

      $ rosa unlink ocm-role --role-arn <arn> 1
      1
      <arn> を OpenShift Cluster Manager IAM ロールの Amazon Resource Name (ARN) に置き換えます。ARN は、前のコマンドの出力で指定されます。前の例では、ARN の形式は arn:aws:iam::<aws_account_external_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id> です。

      出力例

      I: Unlinking OCM role
      ? Unlink the 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>' role from organization '<red_hat_organization_id>'? Yes
      I: Successfully unlinked role-arn 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>' from organization account '<red_hat_organization_id>'

    3. OpenShift Cluster Manager IAM のロールとポリシーを削除します。

      $ rosa delete ocm-role --role-arn <arn>

      出力例

      I: Deleting OCM role
      ? OCM Role ARN: arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>
      ? Delete 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>' ocm role? Yes
      ? OCM role deletion mode: auto 1
      I: Successfully deleted the OCM role

      1
      削除モードを指定します。auto モードを使用して、OpenShift Cluster Manager IAM ロールとポリシーを自動的に削除できます。manual モードでは、rosa CLI はロールとポリシーを削除するために必要な aws コマンドを生成します。manual モードでは、aws コマンドを手動で実行する前に詳細を確認することができます。
  2. Red Hat 組織からユーザー IAM ロールのリンクを解除し、ロールを削除します。

    1. AWS アカウントのユーザー IAM ロールを一覧表示します。

      $ rosa list user-roles

      出力例

      I: Fetching user roles
      ROLE NAME                                  ROLE ARN                                                                  LINKED
      ManagedOpenShift-User-<ocm_user_name>-Role  arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_user_name>-Role  Yes

    2. 上記のコマンドの出力にユーザー IAM ロールがリンクされていると表示されている場合は、Red Hat 組織からロールのリンクを解除します。

      $ rosa unlink user-role --role-arn <arn> 1
      1
      <arn> をユーザー IAM ロールの Amazon Resource Name (ARN) に置き換えます。ARN は、前のコマンドの出力で指定されます。前の例では、ARN の形式は arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_user_name>-Role です。

      出力例

      I: Unlinking user role
      ? Unlink the 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_user_name>-Role' role from the current account '<ocm_user_account_id>'? Yes
      I: Successfully unlinked role ARN 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_user_name>-Role' from account '<ocm_user_account_id>'

    3. ユーザー IAM ロールを削除します。

      $ rosa delete user-role --role-arn <arn>

      出力例

      I: Deleting user role
      ? User Role ARN: arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_user_name>-Role
      ? Delete the 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_user_name>-Role' role from the AWS account? Yes
      ? User role deletion mode: auto 1
      I: Successfully deleted the user role

      1
      削除モードを指定します。auto モードを使用して、ユーザー IAM ロールを自動的に削除できます。manual モードでは、rosa CLI はロールを削除するために必要な aws コマンドを生成します。manual モードでは、aws コマンドを手動で実行する前に詳細を確認できます。

8.4. その他のリソース

第9章 AWS STS を使用しない ROSA のデプロイ

9.1. ROSA の AWS の前提条件

Red Hat OpenShift Service on AWS (ROSA) は、Red Hat によるクラスターのお客様の既存 Amazon Web Service (AWS) アカウントへのデプロイを可能にするモデルを提供します。

ROSA をインストールする前に、前提条件を満たしていることを確認する必要があります。この要件は、AWS Security Token Service (STS) には適用されません。STS を使用している場合は、STS 固有の要件 を参照してください。

ヒント

AWS Security Token Service (STS) は、セキュリティーが強化されているため、Red Hat OpenShift Service on AWS (ROSA) にクラスターをインストールして操作するのに推奨される認証情報モードです。

9.1.1. デプロイメントの前提条件

Red Hat OpenShift Service on AWS (ROSA) を既存の Amazon Web Services (AWS) アカウントにデプロイするには、Red Hat が求める複数の前提条件を満たす必要があります。

Red Hat では、複数の AWS アカウントを管理するために AWS Organizations を使用することを推奨します。お客様が管理する AWS Organizations は、複数の AWS アカウントをホストします。すべてのアカウントがアカウント階層で参照する組織には root アカウントがあります。

ROSA クラスターが AWS Organizational Unit 内の AWS アカウントでホストされるようにすることがベストプラクティスです。Service Control Policy (SCP) が作成され、AWS サブアカウントのアクセスが許可されるサービスを管理する AWS Organizational Unit に適用されます。SCP は、Organizational Unit 内のすべての AWS サブアカウントの単一の AWS アカウント内で利用可能なパーミッションにのみ適用されます。SCP を単一の AWS アカウントに適用することもできます。お客様の AWS Organizations 内の他のすべてのアカウントは、お客様が必要とされる方法に応じて管理されます。Red Hat のサイト信頼性エンジニアリング (SRE) には、AWS Organizations 内の SCP に対する制御がありません。

9.1.2. お客様の要件

Red Hat OpenShift Service on AWS (ROSA) クラスターは、デプロイする前に複数の前提条件を満たす必要があります。

注記

クラスターを作成するには、ユーザーは予想されるロールまたは STS ユーザーとしてではなく、IAM ユーザーとしてログインする必要があります。

9.1.2.1. アカウント

  • お客様は、お客様の AWS アカウント内にプロビジョニングされる Red Hat OpenShift Service on AWS をサポートするのに十分な AWS 制限 が設定されていることを確認します。
  • お客様の AWS アカウントは、該当するサービスコントロールポリシー (SCP) が適用されたお客様の AWS Organizations 組織にある必要があります。

    注記

    お客様のアカウントが AWS Organizations 内にあることや SCP を適用することは要件ではありませんが、Red Hat が制限なしで SCP に一覧表示されるすべてのアクションを実行できるようにする必要があります。

  • お客様の AWS アカウントは、Red Hat に譲渡することはできません。
  • お客様は、Red Hat の各種アクティビティーに対して AWS の使用についての制限を課すことができない場合があります。制限を課すことにより、Red Hat のインシデントへの対応が大幅に妨げられます。
  • お客様は、同じ AWS アカウント内にネイティブ AWS サービスをデプロイすることができます。

    注記

    お客様におかれましては、Red Hat OpenShift Service on AWS やその他の Red Hat がサポートするサービスをホストする VPC とは別の Virtual Private Cloud (VPC) でリソースをデプロイすることが推奨されますが、これは義務ではありません。

9.1.2.2. アクセス要件

  • Red Hat OpenShift Service on AWS サービスを適切に管理するには、Red Hat では AdministratorAccess ポリシーを管理者ロールに常に適用する必要があります。AWS Security Token Service (STS) を使用している場合、この要件は 適用されません

    注記

    このポリシーは、お客様が指定する AWS アカウントのリソースを変更するためのパーミッションおよび機能を Red Hat に提供します。

  • Red Hat には、お客様が提供する AWS アカウントに対する AWS コンソールのアクセスが必要です。このアクセスは、Red Hat により保護され、管理されます。
  • お客様は AWS アカウントを使用して Red Hat OpenShift Service on AWS クラスター内でパーミッションを昇格させることはできません。
  • rosa CLI ユーティリティーまたは OpenShift Cluster Manager コンソールで選択可能なアクションは、お客様の AWS アカウントで直接実行することはできません。

9.1.2.3. サポート要件

  • Red Hat では、お客様が少なくとも AWS の ビジネスサポートを利用できるようにすることを推奨しています。
  • Red Hat は、お客様より、お客様の代わりに AWS サポートをリクエストする権限を受けます。
  • Red Hat は、お客様より、お客様のアカウントで AWS リソース制限の引き上げをリクエストする権限を受けます。
  • Red Hat は、この要件に関するセクションで指定されていない場合に、すべての Red Hat OpenShift Service on AWS クラスターについての制約、制限、予想される内容およびデフォルトの内容を管理します。

9.1.2.4. セキュリティー要件

  • ボリュームスナップショットは、お客様の AWS アカウントおよびお客様が指定するリージョン内に残ります。
  • Red Hat には、許可リストにある IP アドレスから EC2 ホストおよび API サーバーへの ingress アクセスが必要です。
  • Red Hat では、Red Hat が管理する中央ロギングスタックにシステムおよび監査ログを転送できるようにするために egress が必要です。

9.1.3. 必要なお客様の手順

Red Hat OpenShift Service on AWS (ROSA) をデプロイする前に、以下の手順を実行します。

手順

  1. お客様が AWS Organizations を使用している場合は、組織内の AWS アカウントを使用するか、新規アカウントを作成 する必要があります。
  2. Red Hat が必要なアクションを実行できるようにするには、Service Control Policy (SCP) を作成するか、AWS アカウントに適用されているものがないことを確認する必要があります。
  3. SCP を AWS アカウントに 割り当て ます。
  4. 環境を設定するには、ROSA の手順に従います。

9.1.3.1. 最低限必要な Service Control Policy (SCP)

Service Control Policy (SCP) の管理は、お客様の責任です。これらのポリシーは AWS Organizations で維持され、割り当てられる AWS アカウント内で利用可能なサービスを管理します。

注記

AWS セキュリティートークンサービス (STS) を使用する場合は、最小 SCP 要件が適用されません。STS の詳細は、STS を使用する ROSA の AWS 前提条件 について参照してください。

 サービスアクション結果

必須

Amazon EC2

すべて

許可

Amazon EC2 Auto Scaling

すべて

許可

Amazon S3

すべて

許可

アイデンティティーおよびアクセス管理

すべて

許可

Elastic Load Balancing

すべて

許可

Elastic Load Balancing V2

すべて

許可

Amazon CloudWatch

すべて

許可

Amazon CloudWatch イベント

すべて

許可

Amazon CloudWatch ログ

すべて

許可

AWS サポート

すべて

許可

AWS Key Management Service

すべて

許可

AWS Security Token Service

すべて

許可

AWS Resource Tagging

すべて

許可

AWS Route53 DNS

すべて

許可

AWS Service Quotas

ListServices

GetRequestedServiceQuotaChange

GetServiceQuota

RequestServiceQuotaIncrease

ListServiceQuotas

許可

オプション

AWS Billing

ViewAccount

Viewbilling

ViewUsage

許可

AWS Cost and Usage Report

すべて

許可

AWS Cost Explorer Service

すべて

許可

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "autoscaling:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "elasticloadbalancing:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "cloudwatch:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "events:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "logs:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "support:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "kms:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "sts:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "tag:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "route53:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "servicequotas:ListServices",
                "servicequotas:GetRequestedServiceQuotaChange",
                "servicequotas:GetServiceQuota",
                "servicequotas:RequestServiceQuotaIncrease",
                "servicequotas:ListServiceQuotas"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

9.1.4. AWS の Red Hat 管理 IAM リファレンス

Red Hat は、IAM ポリシー、IAM ユーザー、および IAM ロールなどの以下の Amazon Web Services (AWS) リソースを作成し、管理します。

9.1.4.1. IAM ポリシー

注記

IAM ポリシーは、Red Hat OpenShift Service on AWS の機能の変更に伴って変更されることがあります。

  • AdministratorAccess ポリシーは管理ロールによって使用されます。このポリシーは、お客様の AWS アカウントで Red Hat OpenShift Service on AWS (ROSA) クラスターを管理するために必要なアクセスを Red Hat に提供します。

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Action": "*",
                "Resource": "*",
                "Effect": "Allow"
            }
        ]
    }

9.1.4.2. IAM ユーザー

osdManagedAdmin ユーザーは、ROSA をお客様の AWS アカウントにインストール後すぐに作成されます。

9.1.5. プロビジョニングされる AWS インフラストラクチャー

以下は、デプロイされた Red Hat OpenShift Service on AWS (ROSA) クラスターでプロビジョニングされる Amazon Web Services (AWS) コンポーネントの概要です。プロビジョニングされたすべての AWS コンポーネントの詳細な一覧は、OpenShift Container Platform ドキュメントを参照してください。

9.1.5.1. EC2 インスタンス

AWS EC2 インスタンスは、AWS パブリッククラウドに ROSA のコントロールプレーンおよびデータプレーン機能をデプロイするために必要です。

インスタンスタイプは、ワーカーノードの数に応じてコントロールプレーンおよびインフラストラクチャーノードによって異なる場合があります。少なくとも、以下の EC2 インスタンスがデプロイされます。

  • 3 つの m5.2xlarge コントロールプレーンノード
  • 2 つの r5.xlarge インフラストラクチャーノード
  • 2 つの m5.xlarge カスタマイズ可能なワーカーノード

ワーカーノード数の詳細は、このページの関連情報セクションの「初期計画に関する考慮事項」へのリンクを参照してください。

9.1.5.2. AWS Elastic Block Store (EBS) ストレージ

Amazon EBS ブロックストレージは、ローカルノードストレージおよび永続ボリュームストレージの両方に使用されます。

各 EC2 インスタンスのボリューム要件:

  • コントロールプレーンボリューム

    • サイズ: 350GB
    • タイプ: io1
    • 1 秒あたりの I/O 処理数: 1000
  • インフラストラクチャーボリューム

    • サイズ: 300GB
    • タイプ: gp2
    • 1 秒あたりの入出力操作: 900
  • ワーカーボリューム

    • サイズ: 300GB
    • タイプ: gp2
    • 1 秒あたりの入出力操作: 900

9.1.5.3. Elastic Load Balancer

API 用に最大 2 つの Network Elastic Load Balancer (ELB) と、アプリケーションルーター用に最大 2 つの Classic ELB。詳細は、AWS についての ELB ドキュメントを参照してください。

9.1.5.4. S3 ストレージ

イメージレジストリーは AWS S3 ストレージでサポートされます。S3 の使用およびクラスターのパフォーマンスを最適化するために、リソースのプルーニングを定期的に実行します。

注記

通常のサイズがそれぞれ 2TB の 2 つのバケットが必要です。

9.1.5.5. VPC

お客様はクラスターごとに 1 つの VPC を確認できるはずです。さらに、VPC には以下の設定が必要です。

  • Subnets: 単一アベイラビリティーゾーンのクラスターの 2 つのサブネット、または複数のアベイラビリティーゾーンのクラスターの 6 つのサブネット。
  • Router tables: プライベートサブネットごとに 1 つのルーターテーブルと、クラスターごとに 1 つの追加のテーブル。
  • Internet gateways: クラスターごとに 1 つのインターネットゲートウェイ。
  • NAT ゲートウェイ: パブリックサブネットごとに 1 つの NAT ゲートウェイ。
9.1.5.5.1. サンプル VPC アーキテクチャー
VPC Reference Architecture

9.1.5.6. セキュリティーグループ

AWS セキュリティーグループは、プロトコルおよびポートアクセスレベルでセキュリティーを提供します。これらは EC2 インスタンスおよび Elastic Load Balancer に関連付けられます。各セキュリティーグループには、EC2 インスタンス内外へ/からのトラフィックをフィルターする一連のルールが含まれます。OpenShift インストールに必要なポートがネットワーク上で開いており、ホスト間のアクセスを許可するよう設定されていることを確認する必要があります。

グループタイプIP プロトコルポート範囲

MasterSecurityGroup

AWS::EC2::SecurityGroup

icmp

0

tcp

22

tcp

6443

tcp

22623

WorkerSecurityGroup

AWS::EC2::SecurityGroup

icmp

0

tcp

22

BootstrapSecurityGroup

AWS::EC2::SecurityGroup

tcp

22

tcp

19531

9.1.7. 次のステップ

9.1.8. その他のリソース

9.2. ROSA デプロイメントワークフローを理解する

AWS Security Token Service (STS) を使用する Red Hat OpenShift Service on AWS(ROSA) クラスターを作成する前に、AWS の前提条件を満たし、必要な AWS サービスクォータが利用可能であることを確認し、環境をセットアップする必要があります。

本書では、STS デプロイメントワークフローステージを使用した ROSA の概要と、各ステージの詳細なリソースを説明します。

ヒント

AWS Security Token Service (STS) は、セキュリティーが強化されているため、Red Hat OpenShift Service on AWS (ROSA) にクラスターをインストールして操作するのに推奨される認証情報モードです。

9.2.1. ROSA デプロイメントワークフローの概要

このセクションで説明されているワークフローステージに従い、Red Hat OpenShift Service on AWS (ROSA) クラスターを設定し、アクセスできます。

  1. AWS の前提条件を実行します。ROSA クラスターをデプロイするには、AWS アカウントが前提条件を満たしている必要があります。
  2. 必要な AWS サービスクォータを確認します。クラスターのデプロイメントを準備するには、ROSA クラスターの実行に必要な AWS サービスクォータを確認します。
  3. AWS アカウントを設定します。ROSA クラスターを作成する前に、AWS アカウントで ROSA を有効にし、AWS CLI (aws) ツールをインストールして設定し、AWS CLI ツールの設定を確認する必要があります。
  4. ROSA および Open Shift CLI ツールをインストールし、AWS サービスクォータを確認します。ROSA CLI (rosa)、OpenShift CLI (oc) をインストールし、設定します。ROSA CLI を使用して、必要な AWS リソースクォータが利用可能かどうかを確認できます。
  5. ROSA クラスターを作成するAWS PrivateLink を使用して ROSA クラスターを作成します。ROSA CLI (rosa) を使用してクラスターを作成します。オプションで、AWS PrivateLink を使用して ROSA クラスターを作成できます。
  6. クラスターにアクセスします。アイデンティティープロバイダーを設定し、必要に応じてクラスター管理者権限をアイデンティティープロバイダーユーザーに付与できます。cluster-admin ユーザーを設定して、新たにデプロイされたクラスターにすばやくアクセスすることもできます。
  7. ユーザーの ROSA クラスターへのアクセスを取り消します。ROSA CLI または Web コンソールを使用して、ROSA クラスターへのアクセス権をユーザーから取り消すことができます。
  8. ROSA クラスターを削除します。ROSA CLI (rosa) を使用して、ROSA クラスターを削除できます。

9.2.2. 関連情報

9.3. 必要な AWS サービスクォータ

Red Hat OpenShift Service on AWS クラスターの実行に必要な Amazon Web Service (AWS) サービスクォータの一覧を確認します。

ヒント

AWS Security Token Service (STS) は、セキュリティーが強化されているため、Red Hat OpenShift Service on AWS (ROSA) にクラスターをインストールして操作するのに推奨される認証情報モードです。

9.3.1. 必要な AWS サービスクォータ

以下の表は、Red Hat OpenShift Service on AWS クラスターを作成し、実行するために必要な AWS サービスクォータおよびレベルを説明します。

注記

AWS SDK は ROSA がクォータの確認を可能にしますが、AWS SDK 計算には既存の使用が含まれません。そのため、クォータチェックが AWS SDK で合格しても、クラスターの作成が失敗する可能性があります。この問題を修正するには、クォータを増やします。

特定のクォータを変更または増やす必要がある場合は、Amazon のドキュメントの requesting a quota inscrease を参照してください。

クォータ名サービスコードクォータコード最小の必要な値推奨される値

EIP 数 - VPC EIP

ec2

L-0263D0A3

5

5

標準 (A、C、D、H、I、M、R、T、Z) インスタンスのオンデマンド実行

ec2

L-1216C47A

100

100

リージョンごとの VPC

vpc

L-F678F1CE

5

5

リージョンごとのインターネットゲートウェイ

vpc

L-A4707A72

5

5

リージョンごとのネットワークインターフェース

vpc

L-DF5E4CA3

5,000

5,000

汎用 SSD (gp2) ボリュームストレージ

ebs

L-D18FCD1D

50

300

EBS スナップショットの数

ebs

L-309BACF6

300

300

プロビジョニングされた IOPS

ebs

L-B3A130E6

300,000

300,000

プロビジョニングされた IOPS SSD (io1) ボリュームストレージ

ebs

L-FD252861

50

300

リージョンごとのアプリケーションロードバランサー

elasticloadbalancing

L-53DA6B97

50

50

リージョンごとの Classic Load Balancer

elasticloadbalancing

L-E9E9831D

20

20

9.3.2. 次のステップ

9.3.3. 関連情報

9.4. AWS アカウントの設定

AWS の前提条件が完了したら、AWS アカウントを設定し、Red Hat OpenShift Service on AWS (ROSA) サービスを有効にします。

ヒント

AWS Security Token Service (STS) は、セキュリティーが強化されているため、Red Hat OpenShift Service on AWS (ROSA) にクラスターをインストールして操作するのに推奨される認証情報モードです。

9.4.1. AWS アカウントの設定

AWS アカウントを ROSA サービスを使用するように設定するには、以下の手順を実行します。

前提条件

  • デプロイメントの前提条件およびポリシーを確認し、実行します。
  • Red Hat アカウントがない場合はこれを作成します。次に、確認リンクについてのメールを確認します。ROSA をインストールするには認証情報が必要です。

手順

  1. 使用する Amazon Web Services (AWS) アカウントにログインします。

    実稼働クラスターを実行するには、専用の AWS アカウントを使用することが推奨されます。AWS Organizations を使用している場合は、組織内の AWS アカウントを使用するか、アカウントを新規作成 できます。

    AWS Organizations を使用しており、使用する予定の AWS アカウントにサービスコントロールポリシー (SCP) を適用する必要がある場合は、最小限必要な SCP についての詳細を AWS 前提条件で確認してください。

    クラスター作成プロセスの一環として、rosaosdCcsAdmin IAM ユーザーを作成します。このユーザーは、AWS CLI の設定時に指定する IAM 認証情報を使用します。

    注記

    このユーザーは Programmatic アクセスを有効にしており、 AdministratorAccess ポリシーがこれに割り当てられています。

  2. AWS コンソールで ROSA サービスを有効にします。

    1. AWS アカウントにサインインします。
    2. ROSA を有効にするには、ROSA service に移動し、Enable OpenShift を選択します。
  3. AWS CLI をインストールし、設定します。

    1. AWS コマンドラインインターフェースのドキュメントを参照し、オペレーティングシステムの AWS CLI をインストールし、 設定します。

      .aws/credentials ファイルで正しい aws_access_key_id および aws_secret_access_key を指定します。AWS ドキュメントで AWS 設定の基本について参照してください。

    2. デフォルトの AWS リージョンを設定します。

      注記

      環境変数を使用してデフォルトの AWS リージョンを設定することが推奨されます。

      ROSA は以下の優先順位でリージョンを評価します。

      1. --region フラグを指定して rosa コマンドを実行する際に指定されるリージョン。
      2. AWS_DEFAULT_REGION 環境変数に設定されるリージョン。AWS ドキュメントの「Environment variables to configure the AWS CLI」を参照してください。
      3. AWS 設定ファイルで設定されるデフォルトのリージョン。AWS ドキュメントの「Quick configuration with aws configure」を参照してください。
    3. オプション: AWS の名前付きプロファイルを使用して AWS CLI 設定および認証情報を設定します。rosa は、以下の優先順位で AWS の名前付きプロファイルを評価します。

      1. rosa コマンドを --profile フラグを指定して実行する場合に指定されるプロファイル。
      2. AWS_PROFILE 環境変数に設定されるプロファイル。AWS ドキュメントの「Named profiles」を参照してください。
    4. 以下のコマンドを実行して AWS API をクエリーし、AWS CLI がインストールされ、正しく設定されていることを確認します。

      $ aws sts get-caller-identity

      出力例

      ---------------------------------------------------------------------------------
      |                                GetCallerIdentity                              |
      +-------------------------------------------------------------------------------+
      |+-----------------------------------+-----------------------+-----------------+|
      ||      Account        |                Arn              |       UserID        ||
      |+-----------------------------------+-----------------------+-----------------+|
      ||  <account_name>     |  arn:aws:iam<string>:user:name  |      <userID>       ||
      |+-----------------------------------+-----------------------+-----------------+|

      これらの手順を完了したら、ROSA をインストールします。

9.4.2. 次のステップ

9.4.3. その他のリソース

9.5. ROSA CLI のインストール

AWS アカウントを設定したら、ROSA CLI (rosa) をインストールして設定します。

ヒント

AWS Security Token Service (STS) は、セキュリティーが強化されているため、Red Hat OpenShift Service on AWS (ROSA) にクラスターをインストールして操作するのに推奨される認証情報モードです。

9.5.1. ROSA CLI のインストールと設定

ROSA CLI (rosa) をインストールして設定します。OpenShift CLI (oc) をインストールし、ROSA CLI を使用して、必要な AWS リソースクォータが利用可能かどうかを確認することもできます。

前提条件

  • AWS の前提条件および ROSA ポリシーを確認し、完了している。
  • Red Hat アカウント がない場合は作成している。次に、確認リンクについてのメールを確認する。ROSA をインストールするには認証情報が必要。
  • AWS アカウントを設定し、AWS アカウントに ROSA サービスを有効にしている。

手順

  1. Red Hat OpenShift Service on AWS コマンドラインインターフェイス (CLI) の rosa をインストールします。

    1. お使いのオペレーティングシステム用の rosa CLI の最新リリースをダウンロードします。
    2. オプション: rosa にダウンロードした実行可能ファイルの名前を変更します。ここでは、rosa を使用して実行可能ファイルを参照します。
    3. オプション: rosa をパスに追加します。

      $ mv rosa /usr/local/bin/rosa

    4. 以下のコマンドを実行して、インストールを確認します。

      $ rosa

      出力例

      Command line tool for ROSA.
      
      Usage:
        rosa [command]
      
      Available Commands:
        completion  Generates bash completion scripts
        create      Create a resource from stdin
        delete      Delete a specific resource
        describe    Show details of a specific resource
        edit        Edit a specific resource
        help        Help about any command
        init        Applies templates to support Managed OpenShift on AWS clusters
        list        List all resources of a specific type
        login       Log in to your Red Hat account
        logout      Log out
        logs        Show logs of a specific resource
        verify      Verify resources are configured correctly for cluster install
        version     Prints the version of the tool
      
      Flags:
            --debug     Enable debug mode.
        -h, --help      help for rosa
        -v, --v Level   log level for V logs
      
      Use "rosa [command] --help" for more information about a command.

    5. オプション: rosa CLI のコマンド補完スクリプトを生成します。以下の例では、Linux マシン用の Bash 補完スクリプトを生成します。

      $ rosa completion bash | sudo tee /etc/bash_completion.d/rosa
    6. オプション: 既存のターミナルから rosa コマンドの補完を可能にします。次の例では、Linux マシン上の既存のターミナルで rosa の Bash 補完を有効にします。

      $ source /etc/bash_completion.d/rosa
  2. 以下のコマンドを実行して、AWS アカウントに必要なパーミッションがあることを確認します。

    $ rosa verify permissions

    出力例

    I: Validating SCP policies...
    I: AWS SCP policies ok

    注記

    このコマンドは、AWS Security Token Service(STS)を使用しない ROSA クラスターに対してのみパーミッションを検証します。

  3. rosa で Red Hat アカウントにログインします。

    1. 以下のコマンドを入力します。

      $ rosa login
    2. <my_offline_access_token> をトークンに置き換えます。

      出力例

      To login to your Red Hat account, get an offline access token at https://console.redhat.com/openshift/token/rosa
      ? Copy the token and paste it here: <my-offline-access-token>

      出力例

      I: Logged in as 'rh-rosa-user' on 'https://api.openshift.com'

  4. AWS アカウントに Red Hat OpenShift Service on AWS クラスターにデプロイするために必要なクォータがあることを確認します。

    $ rosa verify quota --region=us-west-2

    出力例

    I: Validating AWS quota...
    I: AWS quota ok

    注記

    AWS クォータはリージョンによって異なる場合があります。エラーが発生した場合は、別のリージョンを試してください。

    クォータを増やす必要がある場合は、AWS コンソールに移動し、失敗したサービスについてクォータの増加を要求します。

    パーミッションとクォータの両方のチェックにパスしたら、次のステップに進みます。

  5. クラスターデプロイメント用の AWS アカウントの準備

    1. 以下のコマンドを実行して、Red Hat および AWS の認証情報が正しく設定されていることを確認します。AWS アカウント ID、デフォルトのリージョンおよび ARN が予想される内容と一致していることを確認します。現時点では、OCM で始まる行を安全に無視できます。

      $ rosa whoami

      出力例

      AWS Account ID:               000000000000
      AWS Default Region:           us-east-2
      AWS ARN:                      arn:aws:iam::000000000000:user/hello
      OCM API:                      https://api.openshift.com
      OCM Account ID:               1DzGIdIhqEWyt8UUXQhSoWaaaaa
      OCM Account Name:             Your Name
      OCM Account Username:         you@domain.com
      OCM Account Email:            you@domain.com
      OCM Organization ID:          1HopHfA2hcmhup5gCr2uH5aaaaa
      OCM Organization Name:        Red Hat
      OCM Organization External ID: 0000000

    2. AWS アカウントを初期化します。この手順では、クラスターのデプロイメントおよび管理用に AWS アカウントを準備するために CloudFormation テンプレートを実行します。このステップには通常、完了までに 1 - 2 分の時間がかかります。

      $ rosa init

      出力例

      I: Logged in as 'rh-rosa-user' on 'https://api.openshift.com'
      I: Validating AWS credentials...
      I: AWS credentials are valid!
      I: Validating SCP policies...
      I: AWS SCP policies ok
      I: Validating AWS quota...
      I: AWS quota ok
      I: Ensuring cluster administrator user 'osdCcsAdmin'...
      I: Admin user 'osdCcsAdmin' created successfully!
      I: Verifying whether OpenShift command-line tool is available...
      E: OpenShift command-line tool is not installed.
      Run 'rosa download oc' to download the latest version, then add it to your PATH.

  6. rosa CLI から OpenShift CLI (oc) をインストールします。

    1. 以下のコマンドを入力して、最新バージョンの oc CLI をダウンロードします。

      $ rosa download oc
    2. oc CLI をダウンロードした後に、これを展開し、パスに追加します。
    3. 以下のコマンドを実行して、oc CLI が正常にインストールされていることを確認します。

      $ rosa verify oc

ROSA のインストール後に、クラスターを作成する準備が整います。

9.5.2. 次のステップ

9.5.3. 関連情報

9.6. AWS STS を使用せずに ROSA クラスターの作成

環境を設定して Red Hat OpenShift Service on AWS (ROSA) をインストールした後に、クラスターを作成します。

本書では、ROSA クラスターを設定する方法を説明します。または、AWS PrivateLink を使用して ROSA クラスターを作成できます。

ヒント

AWS Security Token Service (STS) は、セキュリティーが強化されているため、Red Hat OpenShift Service on AWS (ROSA) にクラスターをインストールして操作するのに推奨される認証情報モードです。

9.6.1. クラスターの作成

rosa CLI を使用して Red Hat OpenShift Service on AWS クラスターを作成できます。

前提条件

Red Hat OpenShift Service on AWS がインストールされている。

注記

現時点で、AWS 共有 VPC は ROSA インストールではサポートされていません。

手順

  1. デフォルト設定を使用するか、または対話モードでカスタム設定を指定してクラスターを作成できます。クラスターの作成時に他のオプションを表示するには、rosa create cluster --help を実行します。

    クラスターの作成には最長で 40 分かかる場合があります。

    注記

    実稼働環境のワークロードには、複数のアベイラビリティーゾーン (AZ) の使用が推奨されます。デフォルトは単一のアベイラビリティーゾーンです。このオプションを手動で設定する方法の例について --help を使用するか、またはこの設定についてのプロンプトを出す対話モードを使用します。

    • デフォルトのクラスター設定でクラスターを作成するには、以下を実行します。

      $ rosa create cluster --cluster-name=<cluster_name>

      出力例

      I: Creating cluster with identifier '1de87g7c30g75qechgh7l5b2bha6r04e' and name 'rh-rosa-test-cluster1'
      I: To view list of clusters and their status, run `rosa list clusters`
      I: Cluster 'rh-rosa-test-cluster1' has been created.
      I: Once the cluster is 'Ready' you will need to add an Identity Provider and define the list of cluster administrators. See `rosa create idp --help` and `rosa create user --help` for more information.
      I: To determine when your cluster is Ready, run `rosa describe cluster rh-rosa-test-cluster1`.

    • 対話式プロンプトを使用してクラスターを作成するには、以下を実行します。

      $ rosa create cluster --interactive
    • ネットワーク IP 範囲を設定するには、以下のデフォルト範囲を使用できます。手動モードを使用する場合の詳細は、rosa create cluster --help | grep cidr を使用します。対話モードでは、設定の入力を求めるプロンプトが出されます。

      • ノード CIDR: 10.0.0.0/16
      • サービス CIDR: 172.30.0.0/16
      • Pod CIDR: 10.128.0.0/14
  2. 以下のコマンドを実行して Pod のステータスを確認します。クラスターの作成時に、出力の State フィールドは pending から インストール に移行し、最終的に 準備 に移行します。

    $ rosa describe cluster --cluster=<cluster_name>

    出力例

    Name: rh-rosa-test-cluster1
    OpenShift Version: 4.6.8
    DNS: *.example.com
    ID: uniqueidnumber
    External ID: uniqueexternalidnumber
    AWS Account: 123456789101
    API URL: https://api.rh-rosa-test-cluster1.example.org:6443
    Console URL: https://console-openshift-console.apps.rh-rosa-test-cluster1.example.or
    Nodes: Master: 3, Infra: 2, Compute: 2
    Region: us-west-2
    Multi-AZ: false
    State: ready
    Channel Group: stable
    Private: No
    Created: Jan 15 2021 16:30:55 UTC
    Details Page: https://console.redhat.com/examplename/details/idnumber

    注記

    インストールが失敗した場合や、40 分後に State フィールドが ready に変わらない場合は、インストールのトラブルシューティングに関するドキュメントで詳細を確認してください。

  3. OpenShift インストーラーログを監視して、クラスター作成の進捗を追跡します。

    $ rosa logs install --cluster=<cluster_name> --watch

9.6.2. 次のステップ

アイデンティティープロバイダーの設定

9.6.3. 関連情報

9.7. ROSA クラスターへのアクセスの削除

rosa コマンドラインを使用して Red Hat OpenShift Service on AWS (ROSA) クラスターへのアクセスを削除します。

ヒント

AWS Security Token Service (STS) は、セキュリティーが強化されているため、Red Hat OpenShift Service on AWS (ROSA) にクラスターをインストールして操作するのに推奨される認証情報モードです。

9.7.1. rosa CLI を使用した dedicated-admin アクセスの取り消し

dedicated-admin ユーザーのアクセス権を取り消すことができるのは、自分がクラスターを作成したユーザー、組織管理者ユーザー、またはスーパー管理者ユーザーの場合です。

前提条件

  • アイデンティティープロバイダー (IDP) をクラスターに追加している。
  • 取り消す権限を持つユーザーの IDP ユーザー名がある。
  • クラスターにログインしている。

手順

  1. ユーザーの dedicated-admin アクセスを取り消すには、次のコマンドを入力してください。

    $ rosa revoke user dedicated-admin --user=<idp_user_name> --cluster=<cluster_name>
  2. 以下のコマンドを実行して、ユーザーに dedicated-admin アクセスがなくなったことを確認します。出力には、取り消したユーザーが表示されません。

    $ oc get groups dedicated-admins

9.7.2. rosa CLI を使用した cluster-admin アクセス権の取り消し

クラスターを作成したユーザーのみが、cluster-admin ユーザーのアクセスを取り消すことができます。

前提条件

  • アイデンティティープロバイダー (IDP) をクラスターに追加している。
  • 取り消す権限を持つユーザーの IDP ユーザー名がある。
  • クラスターにログインしている。

手順

  1. ユーザーの cluster-admin アクセスを取り消すには、次のコマンドを入力してください。

    $ rosa revoke user cluster-admins --user=myusername --cluster=mycluster
  2. 次のコマンドを入力して、そのユーザーが cluster-admin アクセス権を失ったことを確認します。出力には、取り消したユーザーが表示されません。

    $ oc get groups cluster-admins

9.8. ROSA クラスターの削除

rosa コマンドラインを使用して Red Hat OpenShift Service on AWS (ROSA) クラスターを削除します。

ヒント

AWS Security Token Service (STS) は、セキュリティーが強化されているため、Red Hat OpenShift Service on AWS (ROSA) にクラスターをインストールして操作するのに推奨される認証情報モードです。

9.8.1. 前提条件

  • Red Hat OpenShift Service on AWS が VPC を作成した場合は、クラスターを正常に削除する前に、クラスターから次のアイテムを削除する必要があります。

    • VPN 構成や VPC ピアリング接続などのネットワーク構成
    • VPC に追加された追加サービス

これらの構成とサービスが残っている場合、クラスターは適切に削除されません。

9.8.2. ROSA クラスターとクラスター固有の IAM リソースの削除

ROSA CLI (rosa) または Red Hat OpenShift Cluster Manager を使用して、AWS Security Token Service (STS) クラスターを備えた Red Hat OpenShift Service on AWS (ROSA) を削除できます。

クラスターを削除した後、ROSA CLI (rosa) を使用して、AWS アカウントのクラスター固有の Identity and Access Management (IAM) リソースをクリーンアップできます。クラスター固有のリソースには、Operator ロールと OpenID Connect (OIDC) プロバイダーが含まれます。

重要

IAM リソースは、クラスターの削除およびクリーンアップのプロセスで使用されるため、クラスターの削除は、IAM リソースを削除する前に完了する必要があります。

アドオンがインストールされている場合、クラスターの削除前にアドオンをアンインストールするため、削除により多くの時間がかかります。所要時間は、アドオンの数とサイズによって異なります。

前提条件

  • ROSA クラスターをインストールしました。
  • インストールホストに、最新の ROSA CLI (rosa) をインストールして設定している。

手順

  1. クラスター ID、クラスター固有 Operator ロールの Amazon Resource Names (ARN)、および OIDC プロバイダーのエンドポイント URL を取得します。

    $ rosa describe cluster --cluster=<cluster_name> 1
    1
    <cluster_name> は、クラスター名に置き換えます。

    出力例

    Name:                       mycluster
    ID:                         1s3v4x39lhs8sm49m90mi0822o34544a 1
    ...
    Operator IAM Roles: 2
     - arn:aws:iam::<aws_account_id>:role/mycluster-x4q9-openshift-machine-api-aws-cloud-credentials
     - arn:aws:iam::<aws_account_id>:role/mycluster-x4q9-openshift-cloud-credential-operator-cloud-crede
     - arn:aws:iam::<aws_account_id>:role/mycluster-x4q9-openshift-image-registry-installer-cloud-creden
     - arn:aws:iam::<aws_account_id>:role/mycluster-x4q9-openshift-ingress-operator-cloud-credentials
     - arn:aws:iam::<aws_account_id>:role/mycluster-x4q9-openshift-cluster-csi-drivers-ebs-cloud-credent
     - arn:aws:iam::<aws_account_id>:role/mycluster-x4q9-openshift-cloud-network-config-controller-cloud
    State:                      ready
    Private:                    No
    Created:                    May 13 2022 11:26:15 UTC
    Details Page:               https://console.redhat.com/openshift/details/s/296kyEFwzoy1CREQicFRdZybrc0
    OIDC Endpoint URL:          https://rh-oidc.s3.us-east-1.amazonaws.com/1s5v4k39lhm8sm59m90mi0822o31844a 3

    1
    クラスター ID を一覧表示します。
    2
    クラスター固有の Operator ロールの ARN を指定します。たとえば、サンプル出力では、Machine Config Operator に必要なロールの ARN は arn:aws:iam::<aws_account_id>:role/mycluster-x4q9-openshift-machine-api-aws-cloud-credentials です。
    3
    クラスター固有の OIDC プロバイダーのエンドポイント URL を指定します。
    重要

    クラスターが削除された後、ROSA CLI (rosa) を使用してクラスター固有の STS リソースを削除するには、クラスター ID が必要です。

  2. クラスターを削除します。

    • Red Hat OpenShift Cluster Manager を使用してクラスターを削除するには:

      1. OpenShift Cluster Manager に移動します。
      2. クラスターの横にあるオプションメニューをクリックし kebabDelete cluster を選択します。
      3. プロンプトでクラスターの名前を入力し、Delete をクリックします。
    • ROSA CLI (rosa) を使用してクラスターを削除するには:

      1. 以下のコマンドを実行してクラスターを削除し、ログを監視し、<my-cluster> はクラスターの名前または ID に置き換えます。

        $ rosa delete cluster --cluster=<cluster_name> --watch
        重要

        Operator ロールと OIDC プロバイダーを削除する前に、クラスターの削除が完了するのを待つ必要があります。クラスター固有の Operator ロールは、OpenShift Operator によって作成されるリソースをクリーンアップするために必要です。Operator は、OIDC プロバイダーを利用して認証を行います。

  3. クラスター Operator が認証に使用する OIDC プロバイダーを削除します。

    $ rosa delete oidc-provider -c <cluster_id> --mode auto 1
    1
    <cluster_id> をクラスターの ID に置き換えてください。
    注記

    -y オプションを使用すると、プロンプトに対して自動的に「はい」と答えることができます。

  4. クラスター固有の Operator IAM ロールを削除します。

    $ rosa delete operator-roles -c <cluster_id> --mode auto 1
    1
    <cluster_id> をクラスターの ID に置き換えてください。

9.9. クラスターおよびユーザーを作成するためのコマンドのクイックリファレンス

ヒント

AWS Security Token Service (STS) は、セキュリティーが強化されているため、Red Hat OpenShift Service on AWS (ROSA) にクラスターをインストールして操作するのに推奨される認証情報モードです。

9.9.1. コマンドクイックリファレンスの一覧

最初のクラスターおよびユーザーがすでに作成されている場合、この一覧は追加のクラスターおよびユーザーの作成時のコマンドクイックリファレンスの一覧として機能します。

## Configures your AWS account and ensures everything is setup correctly
$ rosa init

## Starts the cluster creation process (~30-40minutes)
$ rosa create cluster --cluster-name=<cluster_name>

## Connect your IDP to your cluster
$ rosa create idp --cluster=<cluster_name> --interactive

## Promotes a user from your IDP to dedicated-admin level
$ rosa grant user dedicated-admin --user=<idp_user_name> --cluster=<cluster_name>

## Checks if your install is ready (look for State: Ready),
## and provides your Console URL to login to the web console.
$ rosa describe cluster --cluster=<cluster_name>

9.9.2. 関連情報