ROSA について
AWS アーキテクチャーでの Red Hat OpenShift サービスの概要
概要
第1章 ROSA の理解
Red Hat OpenShift Service on AWS (ROSA)、Red Hat OpenShift Cluster Manager およびコマンドラインインターフェイス (CLI) ツールを使用した ROSA との対話、消費のしやすさ、および Amazon Web Services (AWS) サービスとの統合を理解します。
1.1. ROSA について
ROSA は、フルマネージドのターンキーアプリケーションプラットフォームであり、アプリケーションを構築してデプロイすることにより、お客様に価値を提供することに集中できます。Red Hat Site Reliability Engineering (SRE) のエキスパートが基盤となるプラットフォームを管理するため、インフラストラクチャー管理の複雑さを心配する必要はありません。ROSA は、幅広い AWS コンピュート、データベース、分析、機械学習、ネットワーク、モバイル、およびその他のサービスとのシームレスな統合を提供し、差別化されたエクスペリエンスの構築とお客様への提供をさらに加速します。
AWS アカウントから直接サービスに登録します。クラスターの作成後に、OpenShift Web コンソールまたは Red Hat OpenShift Cluster Manager でクラスターを操作できます。ROSA サービスは、OpenShift API およびコマンドラインインターフェイス (CLI) ツールも使用します。これらのツールは、標準化された OpenShift エクスペリエンスを提供し、既存のスキルおよびツールを使用できます。
OpenShift Container Platform との連携に必要な新規機能のリリースおよび共有される共通ソースを含む OpenShift の更新を受け取れます。ROSA では、バージョンの整合性を確保するために、Red Hat OpenShift Dedicated および OpenShift Container Platform と同じバージョンの OpenShift をサポートします。
ROSA のインストールの詳細は、Red Hat Openshift Service on AWS (ROSA) のインストールのインタラクティブな説明 を参照してください。
1.2. 認証情報モード
AWS Security Token Service (STS) は、セキュリティーが強化されているため、Red Hat OpenShift Service on AWS (ROSA) にクラスターをインストールして操作するのに推奨される認証情報モードです。
ROSA クラスターでサポートされている認証情報モードは 2 つあります。1 つは推奨される AWS Security Token Service (STS) を使用し、もう 1 つは Identity Access Management (IAM) ロールを使用します。
1.2.1. STS を使用する ROSA
AWS STS は、IAM または統合ユーザーに短期間の認証情報を提供するグローバル Web サービスです。STS を使用した ROSA は、ROSA クラスターに推奨される認証情報モードです。AWS STS と ROSA を使用して、コンポーネント固有の IAM ロールに一時的な制限付き特権の認証情報を割り当てることができます。サービスを使用すると、クラスターコンポーネントはセキュアなクラウドリソース管理プラクティスを使用して AWS API 呼び出しを実行できます。
ROSA CLI (rosa
) を使用して、STS を使用する ROSA クラスターに必要な IAM ロール、ポリシー、および ID リソースを作成できます。
AWS STS は、クラウドサービスのリソース管理における最小権限と安全なプラクティスの原則に準拠しています。ROSA CLI は、固有のタスクに割り当てられた STS 認証情報を管理し、OpenShift 機能の一部として AWS リソースに対してアクションを実行します。STS を使用する際の制限の 1 つは、ROSA クラスターごとにロールを作成する必要があることです。
STS 認証情報モードは、次の理由でより安全です。
- 事前に作成した明示的で限定された一連のロールとポリシーをサポートし、要求されたすべてのパーミッションと使用されたすべてのロールを追跡します。
- サービスは、設定された権限に制限されています。
- サービスを実行すると、1 時間で有効期限が切れる認証情報を取得するため、認証情報をローテーションしたり取り消したりする必要はありません。有効期限により、認証情報の漏洩や再利用のリスクも軽減されます。
アカウント全体およびクラスターごとのロールのリストは、STS を使用する ROSA クラスターの IAM リソースについて に記載されています。
1.2.2. STS なしの ROSA
このモードでは、アカウント内に AdministratorAccess
を持つ事前に作成された IAM ユーザーを使用します。このユーザーは、必要に応じて他のロールとリソースを作成するための適切な権限を持っています。このアカウントを使用して、サービスはクラスターに必要なすべてのリソースを作成します。
1.3. 課金と課金設定
ROSA は AWS アカウントに直接請求されます。ROSA の価格設定は、消費量に応じて、年間契約や 3 年契約など、より割引率の高い契約が可能です。ROSA の総コストは、次の 2 つの要素で構成されます。
- ROSA サービス料
- AWS インフラストラクチャー料金
詳細は、AWS pricing page をご覧ください。
1.4. スタートガイド
クラスターのデプロイを開始するには、AWS アカウントが前提条件を満たしていること、Red Hat アカウントの準備ができていること、および Red Hat OpenShift Service on AWS の使用を開始する で概説されている手順に従うことを確認してください。
関連情報
第2章 ROSA アーキテクチャー
2.1. アーキテクチャーの概念
Red Hat OpenShift Service on AWS アーキテクチャーで使用される OpenShift およびコンテナーの基本概念を説明します。
2.1.1. OpenShift
OpenShift は、エンタープライズワークロードを実行するための信頼できる環境を提供する Kubernetes コンテナープラットフォームです。これは、ビルトインソフトウェアで Kubernetes プラットフォームを拡張し、アプリケーションのライフサイクルの開発、操作、およびセキュリティーを強化します。OpenShift を使用すると、複数のハイブリッドクラウドプロバイダーおよび環境全体でワークロードを一貫した方法でデプロイできます。
2.1.2. Kubernetes
Red Hat OpenShift Service on AWS (ROSA) は、エンタープライズ Kubernetes プラットフォームである Red Hat OpenShift を使用します。Kubernetes は、コンテナー化されたワークロードおよびサービスを複数のホスト間で管理するためのオープンソースプラットフォームであり、手動の介入を最小限に抑えるか、手動の介入なしにコンテナー化されたアプリケーションをのデプロイ、自動化、監視、スケーリングを行う管理ツールを提供します。Kubernetes の詳細は、Kubernetes ドキュメント を参照してください。
- クラスターおよびノード
Kubernetes クラスターはノードを使用して、クラスター上で管理されるアプリケーションの復元力とスケーラビリティーを確保します。ノードは、クラスターのリソースを実行する物理または仮想コンピューティングマシンです。Kubernetes は、クラスター操作をサポートするために、ノードをコントロールプレーンノードとワーカーノードに編成します。
コントロールプレーンノードは、クラスター内のすべてのリソースを集中的に制御および監視します。コンテナー化されたアプリケーションのリソースをデプロイすると、Kubernetes コントロールプレーンは、デプロイメント要件とクラスター内の利用可能な容量を考慮して、それらのリソースをデプロイするワーカーノードを選択します。
ワーカーノードはサービスを実行してコントロールプレーンノードと通信し、プロジェクト Pod で作成されたアプリケーションを実行するリクエストを受け取ります。
- マシンプール
- アプリケーションの弾力性を確保するためにアベイラビリティーゾーン全体に分散できるワーカーノードのセットの抽象的なグループ。
- Namespace
-
Kubernetes namespace は、クラスターを複数のチームと共有する場合などに、アプリケーションをデプロイし、アクセスを制限できる複数の領域にクラスターリソースを分割する方法です。たとえば、設定されるシステムリソースは、
kube-system
などの別の namespace に保持されます。Kubernetes リソースの作成時に namespace を指定しない場合、リソースはdefault
namespace に自動的に作成されます。 - Pod
- クラスターにデプロイされるコンテナー化アプリケーションはすべて、Pod と呼ばれる Kubernetes リソースによってデプロイされ、実行され、管理されます。Pod は、Kubernetes クラスターの小規模なデプロイ可能な単位を表し、単一の単位として処理する必要のあるコンテナーをグループ化するために使用されます。ほとんどの場合、各コンテナーは独自の Pod にデプロイされます。ただし、アプリケーションではコンテナーおよび他のヘルパーコンテナーを 1 つの Pod にデプロイして、それらのコンテナーを同じプライベート IP アドレスを使用して処理できるようにする必要がある場合があります。
- アプリケーション
- アプリケーションは、アプリケーションの完全なアプリケーションまたはアプリケーションのコンポーネントを指すことがあります。アプリケーションのコンポーネントを別の Pod にデプロイすることも、別のコンピュートノードにデプロイできます。
- サービス
- サービスは、Pod のセットをグループ化し、各 Pod の実際のプライベート IP アドレスを公開せずにこれらの Pod へのネットワーク接続を提供する Kubernetes リソースです。サービスを使用して、クラスター内またはパブリックインターネットでアプリケーションを利用できるようにすることができます。
- デプロイメント
デプロイメントは、サービス、永続ストレージまたはアノテーションなどのアプリケーションの実行に必要な他のリソースまたは機能についての情報を指定できる Kubernetes リソースです。設定 YAML ファイルでデプロイメントを設定してから、これをクラスターに適用します。Kubernetes メインリソースを設定し、利用可能な容量を持つコンピュートノードの Pod にコンテナーをデプロイします。
ローリング更新時に追加する Pod の数や、同時に利用できない Pod 数など、アプリケーションの更新ストラテジーを定義します。ローリング更新の実行時に、デプロイメントは更新が機能しているかどうかを確認し、障害の検出時にロールアウトを停止します。
デプロイメントは、Pod を管理するのに使用できるワークロードコントローラーの 1 つのタイプです。
2.1.3. コンテナー
コンテナーは、アプリケーションコード、設定、および依存関係を単一のユニットにパッケージ化する標準的な方法を提供します。コンテナーは、コンピュートホストで分離されたプロセスとして実行し、ホストオペレーティングシステムとそのハードウェアリソースを共有します。コンテナーは環境をまたがって移動でき、変更せずに実行できます。仮想マシンとは異なり、コンテナーはデバイス、そのオペレーティングシステム、および基礎となるハードウェアの仮想化を行いません。アプリケーションコード、ランタイム、システムツール、ライブラリーおよび設定のみがコンテナー内でパッケージ化されます。この方法により、コンテナーは仮想マシンと比較してより軽量で移植可能となり、より効率的になります。
OCI 準拠のコンテナーイメージは、既存の Linux コンテナーテクノロジー (LXC) 上にビルドされ、ソフトウェアをアプリケーションの実行に必要なすべての要素を含む標準化された単位にパッケージ化する方法に関するテンプレートを定義します。Red Hat OpenShift Service on AWS (ROSA) は CRI-O をコンテナーランタイムとして使用し、コンテナーをクラスターにデプロイします。
ROSA の Kubernetes でアプリケーションを実行するには、最初にコンテナーレジストリーに保存するコンテナーイメージを作成してアプリケーションをコンテナー化する必要があります。
- イメージ
- コンテナーイメージは、実行するすべてのコンテナーのベースです。コンテナーイメージは、イメージをビルドする方法を定義し、アプリケーション、アプリケーション設定、およびその依存関係などの追加するアーティファクトをビルドするテキストファイルの Dockerfile です。イメージは常に他のイメージからビルドされるため、迅速に設定できます。
- レジストリー
- イメージレジストリーは、コンテナーイメージを保存し、取得し、共有する場所です。レジストリーに保存されているイメージには、公開されている (パブリックレジストリー) か、小規模なユーザーのグループ (プライベートレジストリー) がアクセスできます。ROSA は、最初のコンテナー化されたアプリケーションを作成する際に使用できるパブリックイメージを提供します。エンタープライズアプリケーションの場合は、プライベートレジストリーを使用して、権限のないユーザーがイメージを使用できないようにできます。
2.2. アーキテクチャーモデル
ROSA には 2 つのインストール製品があります。このアーキテクチャーは、次のネットワーク設定タイプをサポートします。
- パブリックネットワーク
- プライベートネットワーク
- AWS PrivateLink (ROSA Classic のみ)
2.2.1. パブリックおよびプライベートネットワークの ROSA アーキテクチャー
ROSA は、パブリックネットワークまたはプライベートネットワークのいずれかを使用してインストールできます。クラスター作成のプロセス中または作成後にプライベートクラスターおよびプライベートネットワーク接続を設定します。Red Hat は、パブリックネットワークを介したアクセスが限定されたクラスターを管理します。詳細は、ROSA サービス定義 を参照してください。
図2.1 パブリックおよびプライベートネットワークにデプロイされた ROSA Classic
Hosted Control Plane (HCP) を備えた Red Hat OpenShift Service on AWS (ROSA) を使用している場合は、パブリックネットワークおよびプライベートネットワーク上にもクラスターを作成できます。以下の図は、パブリックネットワークとプライベートネットワークの両方のアーキテクチャーを示しています。
図2.2 パブリックネットワーク上にデプロイされた HCP を備えた ROSA
図2.3 プライベートネットワーク上にデプロイされた HCP を備えた ROSA
または、プライベートサブネットでのみホストされる AWS PrivateLink を使用して ROSA Classic クラスターをインストールできます。
2.2.2. AWS PrivateLink アーキテクチャー
AWS PrivateLink クラスターを作成する Red Hat マネージドインフラストラクチャーは、プライベートサブネットでホストされています。Red Hat とお客様によって提供されるインフラストラクチャー間の接続は、AWS PrivateLink VPC エンドポイント経由で作成されます。
AWS PrivateLink は既存の VPC でのみサポートされます。
次の図は、PrivateLink クラスターのネットワーク接続を示しています。
図2.4 プライベートサブネットにデプロイされたマルチ AZ AWS PrivateLink クラスター
2.2.2.1. AWS リファレンスアーキテクチャー
AWS は、AWS PrivateLink を使用する設定の設定方法を計画する際に、お客様に役立つリファレンスアーキテクチャーを複数提供します。以下に 3 つの例を示します。
パブリックサブネット は、インターネットゲートウェイを介してインターネットに直接接続します。プライベートサブネット は、ネットワークアドレス変換 (NAT) ゲートウェイを介してインターネットに接続します。
プライベートサブネットおよび AWS Site-to-Site VPN アクセスを持つ VPC
この設定により、ネットワークをインターネットに公開することなく、ネットワークをクラウドに拡張できます。
Internet Protocol Security (IPsec) VPN トンネルを介してネットワークとの通信を有効にするために、この設定には、単一のプライベートサブネットと仮想プライベートゲートウェイを持つ仮想プライベートクラウド (VPC) が含まれます。インターネットを介した通信は、インターネットゲートウェイを使用しません。
詳細は、AWS ドキュメントの VPC with a private subnet only and AWS Site-to-Site VPN access を参照してください。
パブリックおよびプライベートサブネット (NAT) を持つ VPC
この設定により、ネットワークを分離して、インターネットからパブリックサブネットに到達できるようにし、かつプライベートサブネットには到達できないようにすることができます。
パブリックサブネットのみが送信トラフィックをインターネットに直接送信できます。プライベートサブネットは、パブリックサブネットにあるネットワークアドレス変換 (NAT) ゲートウェイを使用してインターネットにアクセスできます。これにより、データベースサーバーが NAT ゲートウェイを使用してソフトウェアの更新用にインターネットに接続できますが、インターネットからデータベースサーバーへ直接接続することはできません。
詳細は、AWS ドキュメントの VPC with public and private subnets (NAT) を参照してください。
パブリックサブネットとプライベートサブネット、および AWS Site-to-Site VPN アクセスを持つ VPC
この設定により、ネットワークをクラウドに拡張し、VPC からインターネットに直接アクセスすることができます。
スケーラブルな Web フロントエンドを備えた多層アプリケーションをパブリックサブネットで実行し、IPsec AWS Site-to-Site VPN 接続によってネットワークに接続されているプライベートサブネットにデータを格納できます。
詳細は、AWS ドキュメントの VPC with public and private subnets and AWS Site-to-Site VPN access を参照してください。
2.2.3. Local Zones を使用する ROSA アーキテクチャー
ROSA は、顧客がレイテンシーの影響を受けやすいアプリケーションのワークロードを VPC 内に配置できる大都市集中型のアベイラビリティーゾーンである AWS Local Zones の使用をサポートします。Local Zones は AWS リージョンを拡張したもので、デフォルトでは有効になっていません。Local Zones が有効になっており、設定されている場合、トラフィックは Local Zones に拡張され、高い柔軟性と低レイテンシーを得ることができます。詳細は、Local Zones でマシンプールを設定する を参照してください。
次の図は、トラフィックが Local Zones にルーティングされない ROSA クラスターを示しています。
図2.5 トラフィックが Local Zones にルーティングされない ROSA クラスター
次の図は、トラフィックが Local Zones にルーティングされる ROSA クラスターを示しています。
図2.6 トラフィックが Local Zones にルーティングされる ROSA クラスター
第3章 ポリシーおよびサービス定義
3.1. Red Hat OpenShift Service on AWS のサポート
可用性と障害を回避することは、どのアプリケーションプラットフォームでも非常に重要な要素です。Red Hat OpenShift Service on AWS (ROSA) は複数のレベルで障害に対する保護を提供しますが、お客様がデプロイするアプリケーションは高可用性を確保するために適切に設定される必要があります。クラウドプロバイダーで発生する可能性のある停止状態に対応するために、複数のアベイラビリティーゾーンにクラスターをデプロイしたり、フェイルオーバーメカニズムで複数のクラスターを維持したりするなどの追加のオプションを選択できます。
3.1.1. 潜在的な障害点
Red Hat OpenShift Service on AWS (ROSA) は、ダウンタイムに対してワークロードを保護するために多くの機能およびオプションを提供しますが、アプリケーションはこれらの機能を利用できるように適切に設計される必要があります。
ROSA は、Red Hat Site Reliability Engineering (SRE) によるサポートと、複数のアベイラビリティゾーンクラスターをデプロイする方法をさらに備えており、多くの一般的な Kubernetes の問題からの保護を強化できますが、それでもコンテナーやインフラストラクチャーに障害が発生する可能性は多数あります。潜在的な障害点を把握することで、リスクを想定し、アプリケーションとクラスターの両方が特定のレベルで必要に応じて回復性を持つように設計できます。
停止状態は、インフラストラクチャーおよびクラスターコンポーネントの複数の異なるレベルで生じる可能性があります。
3.1.1.1. コンテナーまたは Pod の障害
設計上、Pod は短期間存在することが意図されています。アプリケーション Pod の複数のインスタンスが実行されている場合は、個別の Pod またはコンテナーの問題から保護できるようにサービスを適切にスケーリングします。OpenShift ノードスケジューラーは、回復性をさらに強化するために、これらのワークロードが異なるワーカーノードに分散するようにします。
Pod の障害に対応する場合は、ストレージがアプリケーションに割り当てられる方法も理解することが重要になります。単一 Pod に割り当てられる単一の永続ボリュームは、Pod のスケーリングを完全に活用できませんが、複製されるデータベース、データベースサービス、または共有ストレージはこれを活用できます。
アップグレードなどの計画メンテナンス中にアプリケーションが中断されるのを防ぐには、Pod の Disruption Budget (停止状態の予算) を定義することが重要です。これらは Kubernetes API の一部であり、他のオブジェクトタイプと同様に oc
コマンドで管理できます。この設定により、メンテナンスのためのノードのドレイン (解放) などの操作時に Pod への安全面の各種の制約を指定できます。
3.1.1.2. ワーカーノードの障害
ワーカーノードは、アプリケーション Pod が含まれる仮想マシンです。デフォルトで、ROSA クラスターには単一アベイラビリティーゾーンのクラスター用のワーカーノードが 2 つ以上含まれます。ワーカーノードに障害が発生した場合、Pod は、既存ノードに関する問題が解決するか、ノードが置き換えられるまで、十分な容量がある限り、機能しているワーカーノードに移行します。ワーカーノードを追加することは、単一ノードの停止状態に対する保護策を強化することを意味し、ノードに障害が発生した場合に再スケジュールされる Pod の適切なクラスター容量を確保できます。
ノードの障害に対応する場合は、ストレージへの影響を把握することも重要になります。EFS ボリュームはノードの障害による影響を受けません。ただし、EBS ボリュームは、障害が発生するノードに接続されている場合はアクセスできません。
3.1.1.3. クラスターの障害
シングル AZ ROSA クラスターには、プライベートサブネット内の同じアベイラビリティゾーン (AZ) に少なくとも 3 つのコントロールプレーンと 2 つのインフラストラクチャーノードがあります。
マルチ AZ ROSA クラスターには、選択したクラスターのタイプに応じて、少なくとも 3 つのコントロールプレーンノードと 3 つのインフラストラクチャーノードがあり、高可用性のために事前設定されています。コントロールプレーンおよびインフラストラクチャーノードはワーカーノードと同じ耐障害性があり、この場合は Red Hat によって完全に管理される利点を活用できます。
コントロールプレーンが完全に停止する場合、OpenShift API は機能せず、既存のワーカーノード Pod は影響を受けません。ただし、Pod またはノードが同時に停止している場合は、コントロールプレーンのリカバリーが新規 Pod またはノードを追加される前、またはスケジュールする前に必要になります。
インフラストラクチャーノードで実行されるすべてのサービスは、高可用性を持ち、インフラストラクチャーノード間に分散されるように Red Hat によって設定されます。インフラストラクチャーが完全に停止すると、これらのサービスはこれらのノードが回復するまで利用できなくなります。
3.1.1.4. ゾーンの障害
AWS のゾーン障害は、すべての仮想コンポーネント (ワーカーノード、ブロックまたは共有ストレージ、単一のアベイラビリティーゾーンに固有のロードバランサーなど) に影響を及ぼします。ゾーンの障害から保護するために、ROSA は複数のアベイラビリティーゾーンクラスターとして知られる 3 つのアベイラビリティーゾーンに分散するクラスターに関するオプションを提供します。既存のステートレスワークロードは、十分な容量がある限り、停止時に影響を受けないゾーンに再分散されます。
3.1.1.5. ストレージの障害
ステートフルなアプリケーションをデプロイしている場合、ストレージは重要なコンポーネントであり、高可用性を検討する際に考慮に入れる必要があります。単一ブロックストレージ PV は、Pod レベルでも停止状態になった状態では実行できません。ストレージの可用性を維持する最適な方法として、複製されたストレージソリューション、停止による影響を受けない共有ストレージ、またはクラスターから独立したデータベースサービスを使用できます。
3.2. Red Hat OpenShift Service on AWS におけるロールの概要
以下では、Red Hat OpenShift Service on AWS (ROSA) マネージドサービスにおける Red Hat、Amazon Web Services (AWS)、およびお客様のそれぞれの責任を説明します。
3.2.1. Red Hat OpenShift Service on AWS の責任共有
Red Hat と Amazon Web Services (AWS) が Red Hat OpenShift Service on AWS のサービスを管理している間、お客様には一定の責任があります。Red Hat OpenShift Service on AWS サービスは、リモートでアクセスされ、パブリッククラウドリソースでホストされ、お客様が所有する AWS アカウントで作成され、Red Hat が所有する基礎となるプラットフォームおよびデータセキュリティーを持ちます。
cluster-admin
ロールがユーザーに追加される場合は、Red Hat Enterprise Agreement Appendix 4 (Online Subscription Services) の責任および除外事項を参照してください。
リソース | インシデントおよびオペレーション管理 | 変更管理 | アクセスとアイデンティティーの承認 | セキュリティーおよび規制コンプライアンス | 障害復旧 |
---|---|---|---|---|---|
お客様データ | お客様 | お客様 | お客様 | お客様 | お客様 |
お客様のアプリケーション | お客様 | お客様 | お客様 | お客様 | お客様 |
開発者サービス | お客様 | お客様 | お客様 | お客様 | お客様 |
プラットフォームモニタリング | Red Hat | Red Hat | Red Hat | Red Hat | Red Hat |
ロギング | Red Hat | Red Hat とお客様 | Red Hat とお客様 | Red Hat とお客様 | Red Hat |
アプリケーションのネットワーク | Red Hat とお客様 | Red Hat とお客様 | Red Hat とお客様 | Red Hat | Red Hat |
クラスターネットワーク | Red Hat | Red Hat とお客様 | Red Hat とお客様 | Red Hat | Red Hat |
仮想ネットワーク管理 | Red Hat とお客様 | Red Hat とお客様 | Red Hat とお客様 | Red Hat とお客様 | Red Hat とお客様 |
仮想コンピューティング管理 (コントロールプレーン、インフラストラクチャー、およびワーカーノード) | Red Hat | Red Hat | Red Hat | Red Hat | Red Hat |
クラスターのバージョン | Red Hat | Red Hat とお客様 | Red Hat | Red Hat | Red Hat |
容量の管理 | Red Hat | Red Hat とお客様 | Red Hat | Red Hat | Red Hat |
仮想ストレージ管理 | Red Hat | Red Hat | Red Hat | Red Hat | Red Hat |
AWS ソフトウェア (パブリック AWS サービス) | AWS | AWS | AWS | AWS | AWS |
ハードウェア/AWS グローバルインフラストラクチャー | AWS | AWS | AWS | AWS | AWS |
3.2.2. 領域ごとの責任共有のタスク
Red Hat、AWS、および顧客はすべて、Red Hat OpenShift Service on AWS (ROSA) クラスターの監視、メンテナンス、および全体的な健全性に対して責任を共有します。このドキュメントでは、以下の表に示すように、リストされた各リソースの責任の概要を説明します。
3.2.3. インシデントおよびオペレーション管理
Red Hat は、デフォルトのプラットフォームネットワーキングに必要なサービスコンポーネントを監督する責任があります。AWS は、AWS クラウドで提供されるすべてのサービスを実行するハードウェアインフラストラクチャーを保護する責任があります。お客様は、お客様のアプリケーションデータ、およびお客様がクラスターネットワークまたは仮想ネットワークに設定した可能性のあるカスタムネットワークに関するインシデントおよびオペレーション管理を行います。
リソース | サービスの責任 | お客様の責任 |
---|---|---|
アプリケーションのネットワーク | Red Hat
|
|
仮想ネットワーク管理 | Red Hat
|
|
仮想ストレージ管理 | Red Hat
|
|
プラットフォームモニタリング | Red Hat
| |
インシデント管理 | Red Hat
|
|
インフラストラクチャーとデータの回復力 | Red Hat
|
|
クラスター容量 | Red Hat
| |
AWS ソフトウェア (パブリック AWS サービス) | AWS
|
|
ハードウェア/AWS グローバルインフラストラクチャー | AWS
|
|
3.2.3.1. プラットフォームモニタリング
プラットフォーム監査ログは、一元化された SIEM (security information and event monitoring) システムに安全に転送されます。これにより、SRE チームに対して設定されたアラートがトリガーされる場合は手動によるレビューの対象となります。監査ログは SIEM システムに 1 年間保持されます。指定されたクラスターの監査ログは、クラスターの削除時に削除されません。
3.2.3.2. インシデント管理
インシデントは、1 つ以上の Red Hat サービスの低下や停止をもたらすイベントです。インシデントは、お客様または CEE (Customer Experience and Engagement) のメンバーがサポートケースを通して報告されるか、一元化されたモニタリングおよびアラートシステムから直接提出されるか、 SRE チームのメンバーから直接提出される場合があります。
サービスおよびお客様への影響に応じて、インシデントは 重大度 に基づいて分類されます。
新たなインシデントを管理する際に、Red Hat では以下の一般的なワークフローを使用します。
- SRE の最初に応答するメンバーには新たなインシデントについてのアラートが送られ、最初の調査が開始されます。
- 初回の調査後、インシデントには復旧作業を調整するインシデントのリード (担当者) が割り当てられます。
- インシデントのリードは、関連する通知やサポートケースの更新など、リカバリーに関するすべての通信および調整を管理します。
- インシデントの復旧が行われます。
- インシデントが文書化され、Root Cause Analysis (根本原因分析 (RCA)) がインシデント発生後 5 営業日以内に実行されます。
- RCA のドラフト文書は、インシデント発生後 7 日以内にお客様に共有されます。
3.2.3.3. 通知
プラットフォーム通知は、メールを使用して設定されます。一部のお客様への通知はアカウントの対応 Red Hat アカウントチーム (テクニカルアカウントマネージャーを含む) にも送信されます。
以下のアクティビティーで通知をトリガーできます。
- プラットフォームのインシデント
- パフォーマンスの低下
- クラスター容量に関する警告
- 重大な脆弱性および解決
- アップグレードのスケジュール
3.2.3.4. クラスター容量
クラスターアップグレードの容量に与える影響は、アップグレードのテストプロセスの一部として評価され、容量がクラスターへの新たな追加内容の影響を受けないようにします。クラスターのアップグレード時にワーカーノードが追加され、クラスターの容量全体がアップグレードプロセス時に維持されるようにします。
Red Hat SRE チームによる容量評価は、使用状況のしきい値が一定期間超過した後のクラスターからのアラートへの対応として行われます。このアラートにより、通知がお客様に出されます。
3.2.4. 変更管理
このセクションでは、クラスターおよび設定変更、パッチ、およびリリースの管理方法に関するポリシーを説明します。
Red Hat は、お客様が制御するクラスターインフラストラクチャーおよびサービスへの変更を有効にし、コントロールプレーンノード、インフラストラクチャーノードおよびサービス、ならびにワーカーノードのバージョンを維持します。AWS は、AWS クラウドで提供されるすべてのサービスを実行するハードウェアインフラストラクチャーを保護する責任があります。お客様は、インフラストラクチャーの変更要求を開始し、クラスターでの任意のサービスおよびネットワーク設定のインストールおよび維持、ならびにお客様データおよびお客様のアプリケーションに対するすべての変更を行います。
3.2.4.1. お客様が開始する変更
クラスターデプロイメント、ワーカーノードのスケーリング、またはクラスターの削除などのセルフサービス機能を使用して変更を開始できます。
変更履歴は、OpenShift Cluster Manager の 概要タブ の クラスター履歴 セクションにキャプチャーされ、表示できます。変更履歴には、以下の変更のログが含まれますが、これに限定されません。
- アイデンティティープロバイダーの追加または削除
-
dedicated-admins
グループへの、またはそのグループからのユーザーの追加または削除 - クラスターコンピュートノードのスケーリング
- クラスターロードバランサーのスケーリング
- クラスター永続ストレージのスケーリング
- クラスターのアップグレード
以下のコンポーネントの OpenShift Cluster Manager での変更を回避することで、メンテナンスの除外を実装できます。
- クラスターの削除
- ID プロバイダーの追加、変更、または削除
- 昇格されたグループからのユーザーの追加、変更、または削除
- アドオンのインストールまたは削除
- クラスターネットワーク設定の変更
- マシンプールの追加、変更、または削除
- ユーザーワークロードの監視の有効化または無効化
- アップグレードの開始
メンテナンスの除外を適用するには、マシンプールの自動スケーリングまたは自動アップグレードポリシーが無効になっていることを確認してください。メンテナンスの除外が解除されたら、必要に応じてマシンプールの自動スケーリングまたは自動アップグレードポリシーを有効にします。
3.2.4.2. Red Hat が開始する変更
Red Hat Site Reliability Engineering (SRE) は、GitOps ワークフローと完全に自動化された CI/CD パイプラインを使用して、Red Hat OpenShift Service on AWS のインフラストラクチャー、コード、および設定を管理します。このプロセスにより、Red Hat は、お客様に悪影響を与えることなく、継続的にサービスの改善を安全に導入できます。
提案されるすべての変更により、チェック時にすぐに一連の自動検証が実行されます。変更は、自動統合テストが実行されるステージング環境にデプロイされます。最後に、変更は実稼働環境にデプロイされます。各ステップは完全に自動化されます。
認可された SRE レビュー担当者は、各ステップに進む前にこれを承認する必要があります。変更を提案した個人がレビュー担当者になることはできません。すべての変更および承認は、GitOps ワークフローの一部として完全に監査可能です。
一部の変更は、機能フラグを使用して指定されたクラスターまたはお客様に対する新機能の可用性を制御することで、段階的にリリースされます。
3.2.4.3. パッチ管理
OpenShift Container Platform ソフトウェアおよび基礎となるイミュータブルな Red Hat CoreOS (RHCOS) オペレーティングシステムイメージには、通常の z-stream アップグレードのバグおよび脆弱性のパッチが適用されます。OpenShift Container Platform ドキュメントの RHCOS アーキテクチャー を参照してください。
3.2.4.4. リリース管理
Red Hat はクラスターを自動的にアップグレードしません。OpenShift Cluster Manager Web コンソールを使用して、クラスターの更新を定期的に (定期的なアップグレード) または 1 回だけ (個別にアップグレード) 行うようにスケジュールできます。クラスターが重大な影響を与える CVE の影響を受ける場合にのみ、Red Hat はクラスターを新しい z-stream バージョンに強制的にアップグレードする可能性があります。
必要な権限は y-stream リリース間で変更される可能性があるため、アップグレードを実行する前にポリシー更新が必要になる場合があります。したがって、STS を使用する ROSA クラスターで定期的なアップグレードをスケジュールすることはできません。
お客様は OpenShift Cluster Manager Web コンソールで、すべてのクラスターアップグレードイベントの履歴を確認できます。リリースの詳細は、ライフサイクルポリシー を参照してください。
リソース | サービスの責任 | お客様の責任 |
---|---|---|
ロギング | Red Hat
|
|
アプリケーションのネットワーク | Red Hat
|
|
クラスターネットワーク | Red Hat
|
|
仮想ネットワーク管理 | Red Hat
|
|
仮想コンピューティング管理 | Red Hat
|
|
クラスターのバージョン | Red Hat
|
|
容量の管理 | Red Hat
|
|
仮想ストレージ管理 | Red Hat
|
|
AWS ソフトウェア (パブリック AWS サービス) | AWS Compute: ROSA コントロールプレーン、インフラストラクチャー、ワーカーノードに使用される Amazon EC2 サービスを提供します。 Storage: ROSA がクラスターにローカルノードストレージと永続ボリュームストレージをプロビジョニングできるようにするために使用される Amazon EBS を提供します。 Storage: ROSA サービスの組み込みイメージレジストリーに Amazon S3 を提供します。 Networking: ROSA 仮想ネットワーキングインフラストラクチャーのニーズを満たすために、次の AWS Cloud サービスを提供します。
Networking: 次の AWS サービスを提供します。これは、オプションで ROSA と統合できます。
|
|
ハードウェア/AWS グローバルインフラストラクチャー | AWS
|
|
3.2.5. セキュリティーおよび規制コンプライアンス
次の表は、セキュリティーと規制遵守に関する責任の概要を示しています。
リソース | サービスの責任 | お客様の責任 |
---|---|---|
ロギング | Red Hat
|
|
仮想ネットワーク管理 | Red Hat
|
|
仮想ストレージ管理 | Red Hat
|
|
仮想コンピューティング管理 | Red Hat
|
|
AWS ソフトウェア (パブリック AWS サービス) | AWS Compute: ROSA コントロールプレーン、インフラストラクチャー、ワーカーノードに使用される安全な Amazon EC2。詳細は、Amazon EC2 ユーザーガイドの Amazon EC2 のインフラストラクチャーセキュリティー を参照してください。 Storage: ROSA コントロールプレーン、インフラストラクチャー、ワーカーノードボリューム、および Kubernetes 永続ボリュームに使用されるセキュアな Amazon Elastic Block Store (EBS)。詳細は、Amazon EC2 ユーザーガイドの Amazon EC2 でのデータ保護 を参照してください。 Storage: ROSA がコントロールプレーン、インフラストラクチャー、ワーカーノードのボリューム、および永続ボリュームを暗号化するために使用する AWS KMS を提供します。詳細は、Amazon EC2 ユーザーガイドの Amazon EBS 暗号化 を参照してください。 Storage: セキュアな Amazon S3。ROSA サービスの組み込みコンテナーイメージレジストリーに使用されます。詳細は、S3 ユーザーガイドの Amazon S3 セキュリティー を参照してください。 Networking: Amazon VPC に組み込まれたネットワークファイアウォール、プライベートまたは専用ネットワーク接続、AWS の安全な施設間の AWS グローバルおよび地域ネットワーク上のすべてのトラフィックの自動暗号化など、プライバシーを強化し、AWS グローバルインフラストラクチャー上のネットワークアクセスを制御するためのセキュリティー機能とサービスを提供します。詳細は、AWS セキュリティーの概要ホワイトペーパーの AWS Shared Responsibility Model と Infrastructure security を参照してください。 |
|
ハードウェア/AWS グローバルインフラストラクチャー | AWS
|
|
関連情報
- お客様や責任共有の詳細は、ROSA のセキュリティー に関する文書を参照してください。
3.2.6. 障害復旧
障害復旧には、データおよび設定のバックアップ、障害復旧環境へのデータおよび設定の複製、および障害イベント発生時のフェイルオーバーが含まれます。
Red Hat OpenShift Service on AWS (ROSA) は、Pod、ワーカーノード、インフラストラクチャーノード、コントロールプレーンノード、およびアベイラビリティーゾーンレベルで発生する障害について障害復旧を行います。
すべての障害復旧では、必要な可用性レベルを確保するために、単一ゾーンのデプロイメントまたは複数ゾーンのデプロイメントなど、高可用性アプリケーション、ストレージ、およびクラスターアーキテクチャーのデプロイにベストプラクティスを採用する必要があります。
単一ゾーンクラスターは、アベイラビリティーゾーンまたはリージョンの停止時に障害を防止したり、リカバリーを行ったりしません。お客様によってメンテナンスされるフェイルオーバーが設定される複数の単一ゾーンクラスターは、ゾーンまたはリージョンレベルで停止に対応できます。
1 つの複数ゾーンクラスターは、リージョンが完全に停止した場合に障害を防止したり、リカバリーを行ったりしません。お客様によってメンテナンスされるフェイルオーバーが設定される複数の複数ゾーンクラスターは、リージョンレベルで停止に対応できます。
リソース | サービスの責任 | お客様の責任 |
---|---|---|
仮想ネットワーク管理 | Red Hat
|
|
仮想ストレージ管理 | Red Hat
|
|
仮想コンピューティング管理 | Red Hat
|
|
AWS ソフトウェア (パブリック AWS サービス) | AWS Compute: Amazon EBS スナップショットや Amazon EC2 Auto Scaling などのデータ復元力をサポートする Amazon EC2 機能を提供します。詳細は、EC2 ユーザーガイドの Amazon EC2 の復元力 を参照してください。 Storage: ROSA サービスと顧客が、Amazon EBS ボリュームのスナップショットを通じてクラスター上の Amazon EBS ボリュームをバックアップできる機能を提供します。 Storage: データの復元力をサポートする Amazon S3 の機能は、Resilience in Amazon S3 を参照してください。 Networking: データ復元力をサポートする Amazon VPC 機能の詳細は、Amazon VPC ユーザーガイドの Resilience in Amazon Virtual Private Cloud を参照してください。 |
|
ハードウェア/AWS グローバルインフラストラクチャー | AWS
|
|
関連情報
3.2.7. データおよびアプリケーションに関する追加のお客様の責任
お客様は、Red Hat OpenShift Service on AWS にデプロイするアプリケーション、ワークロード、およびデータに責任を負います。ただし、Red Hat と AWS は、お客様がプラットフォーム上のデータとアプリケーションを管理できるようにするさまざまなツールを提供しています。
リソース | Red Hat と AWS | お客様の責任 |
---|---|---|
お客様データ | Red Hat
AWS
|
|
お客様のアプリケーション | Red Hat
AWS
|
|
3.2.8. 関連情報
- Red Hat Site Reliability Engineering (SRE) チームによるアクセスの詳細は、アイデンティティーおよびアクセス管理 を参照してください。
3.3. Red Hat OpenShift Service on AWS のサービス定義
このドキュメントでは、Red Hat OpenShift Service on AWS (ROSA) マネージドサービスのサービス定義を説明します。
3.3.1. アカウント管理
このセクションでは、Red Hat OpenShift Service on AWS アカウント管理のサービス定義を説明します。
3.3.1.1. 請求
Red Hat OpenShift Service on AWS の請求は、サービス (ロードバランサー、ストレージ、EC2 インスタンス、他のコンポーネントなど)、および OpenShift サービスの Red Hat サブスクリプションで使用される AWS コンポーネントの使用状況に基づいて Amazon Web Services (AWS) で行われます。
追加の Red Hat ソフトウェアは別途購入する必要があります。
3.3.1.2. クラスターのセルフサービス
お客様はクラスターをセルフサービスで利用できます。これには以下が含まれますが、これらに限定されません。
- クラスターの作成
- クラスターの削除
- アイデンティティープロバイダーの追加または削除
- 権限が昇格したグループからのユーザーの追加または削除
- クラスターのプライバシーの設定
- マシンプールの追加または削除、および自動スケーリングの設定
- アップグレードポリシーの定義
これらのセルフサービスタスクは、Red Hat OpenShift Service on AWS (ROSA) CLI (rosa
) を使用して実行できます。
3.3.1.3. インスタンスタイプ
アベイラビリティゾーンが 1 つのクラスターには、1 つのアベイラビリティゾーンにデプロイされた 3 つ以上のコントロールプレーンノード、2 つ以上のインフラストラクチャーノード、および 2 つ以上のワーカーノードが必要です。
複数のアベイラビリティゾーンクラスターには、少なくとも 3 つのコントロールプレーンノード、3 つのインフラストラクチャーノード、および 3 つのワーカーノードが必要です。追加のノードを購入する場合は、ノードの適切な配分を維持できるように、3 の倍数単位で購入する必要があります。
すべての Red Hat OpenShift Service on AWS クラスターは、最大 180 ワーカーノードをサポートします。
コントロールプレーンおよびインフラストラクチャーノードは Red Hat によりデプロイされ、管理されます。クラウドプロバイダーコンソールを使用して基礎となるインフラストラクチャーをシャットダウンすることはサポートされておらず、データが失われる可能性があります。etcd および API 関連のワークロードを処理する 3 つ以上のコントロールプレーンノードが使用されます。メトリック、ルーティング、Web コンソール、および他のワークロードを処理するインフラストラクチャーノードが少なくとも 2 つあります。コントロールノードとインフラストラクチャーノードでワークロードを実行しないでください。実行する予定のワークロードはすべて、ワーカーノードにデプロイする必要があります。ワーカーノードにデプロイする必要がある Red Hat ワークロードの詳細は、以下の Red Hat Operator サポートセクションを参照してください。
約 1 vCPU コアおよび 1 GiB のメモリーが各ワーカーノードで予約され、割り当て可能なリソースから削除されます。このリソースの予約は、基礎となるプラットフォームに必要なプロセスを実行するのに必要です。これらのプロセスには、udev、kubelet、コンテナーランタイムなどのシステムデーモンが含まれます。予約されるリソースは、カーネル予約も占めます。
監査ログの集計、メトリックコレクション、DNS、イメージレジストリー、SDN などの OpenShift Container Platform コアシステムは、追加の割り当て可能なリソースを使用し、クラスターの安定性および保守性を確保できる可能性があります。消費される追加リソースは、使用方法によって異なる場合があります。
詳細は、Kubernetes のドキュメント を参照してください。
Red Hat OpenShift Service on AWS 4.11 の時点で、Pod ごとのデフォルトの PID 制限は 4096
です。この PID 制限を有効する場合は、Red Hat OpenShift Service on AWS クラスターをこのバージョン以降にアップグレードする必要があります。以前のバージョンで実行されている Red Hat OpenShift Service on AWS クラスターでは、デフォルトの PID 制限である 1024
が使用されます。
ROSA CLI を使用すると、Red Hat OpenShift Service on AWS クラスターの Pod ごとの PID 制限を設定できます。詳細は、「PID 制限の設定」を参照してください。
3.3.1.4. AWS インスタンスタイプ
Red Hat OpenShift Service on AWS は、次のワーカーノードインスタンスのタイプとサイズを提供します。
例3.1 一般的用途
- m5.metal (96† vCPU、384 GiB)
- m5.xlarge (4 vCPU、16 GiB)
- m5.2xlarge (8 vCPU、32 GiB)
- m5.4xlarge (16 vCPU、64 GiB)
- m5.8xlarge (32 vCPU、128 GiB)
- m5.12xlarge (48 vCPU、192 GiB)
- m5.16xlarge (64 vCPU、256 GiB)
- m5.24xlarge (96 vCPU、384 GiB)
- m5a.xlarge (4 vCPU、16 GiB)
- m5a.2xlarge (8 vCPU、32 GiB)
- m5a.4xlarge (16 vCPU、64 GiB)
- m5a.8xlarge (32 vCPU、128 GiB)
- m5a.12xlarge (48 vCPU、192 GiB)
- m5a.16xlarge (64 vCPU、256 GiB)
- m5a.24xlarge (96 vCPU、384 GiB)
- m5ad.xlarge (4 vCPU、16 GiB)
- m5ad.2xlarge (8 vCPU、32 GiB)
- m5ad.4xlarge (16 vCPU、64 GiB)
- m5ad.8xlarge (32 vCPU、128 GiB)
- m5ad.12xlarge (48 vCPU、192 GiB)
- m5ad.16xlarge (64 vCPU、256 GiB)
- m5ad.24xlarge (96 vCPU、384 GiB)
- m5d.metal (96† vCPU、384 GiB)
- m5d.xlarge (4 vCPU、16 GiB)
- m5d.2xlarge (8 vCPU、32 GiB)
- m5d.4xlarge (16 vCPU、64 GiB)
- m5d.8xlarge (32 vCPU、128 GiB)
- m5d.12xlarge (48 vCPU、192 GiB)
- m5d.16xlarge (64 vCPU、256 GiB)
- m5d.24xlarge (96 vCPU、384 GiB)
- m5n.metal (96 vCPU、384 GiB)
- m5n.xlarge (4 vCPU、16 GiB)
- m5n.2xlarge (8 vCPU、32 GiB)
- m5n.4xlarge (16 vCPU、64 GiB)
- m5n.8xlarge (32 vCPU、128 GiB)
- m5n.12xlarge (48 vCPU、192 GiB)
- m5n.16xlarge (64 vCPU、256 GiB)
- m5n.24xlarge (96 vCPU、384 GiB)
- m5dn.metal (96 vCPU、384 GiB)
- m5dn.xlarge (4 vCPU、16 GiB)
- m5dn.2xlarge (8 vCPU、32 GiB)
- m5dn.4xlarge (16 vCPU、64 GiB)
- m5dn.8xlarge (32 vCPU、128 GiB)
- m5dn.12xlarge (48 vCPU、192 GiB)
- m5dn.16xlarge (64 vCPU、256 GiB)
- m5dn.24xlarge (96 vCPU、384 GiB)
- m5zn.metal (48 vCPU、192 GiB)
- m5zn.xlarge (4 vCPU、16 GiB)
- m5zn.2xlarge (8 vCPU、32 GiB)
- m5zn.3xlarge (12 vCPU、48 GiB)
- m5zn.6xlarge (24 vCPU、96 GiB)
- m5zn.12xlarge (48 vCPU、192 GiB)
- m6a.xlarge (4 vCPU、16 GiB)
- m6a.2xlarge (8 vCPU、32 GiB)
- m6a.4xlarge (16 vCPU、64 GiB)
- m6a.8xlarge (32 vCPU、128 GiB)
- m6a.12xlarge (48 vCPU、192 GiB)
- m6a.16xlarge (64 vCPU、256 GiB)
- m6a.24xlarge (96 vCPU、384 GiB)
- m6a.32xlarge (128 vCPU、512 GiB)
- m6a.48xlarge (192 vCPU、768 GiB)
- m6i.metal (128 vCPU、512 GiB)
- m6i.xlarge (4 vCPU、16 GiB)
- m6i.2xlarge (8 vCPU、32 GiB)
- m6i.4xlarge (16 vCPU、64 GiB)
- m6i.8xlarge (32 vCPU、128 GiB)
- m6i.12xlarge (48 vCPU、192 GiB)
- m6i.16xlarge (64 vCPU、256 GiB)
- m6i.24xlarge (96 vCPU、384 GiB)
- m6i.32xlarge (128 vCPU、512 GiB)
- m6id.xlarge (4 vCPU、16 GiB)
- m6id.2xlarge (8 vCPU、32 GiB)
- m6id.4xlarge (16 vCPU、64 GiB)
- m6id.8xlarge (32 vCPU、128 GiB)
- m6id.12xlarge (48 vCPU、192 GiB)
- m6id.16xlarge (64 vCPU、256 GiB)
- m6id.24xlarge (96 vCPU、384 GiB)
- m6id.32xlarge (128 vCPU、512 GiB)
- m7i.xlarge (4 vCPU、16 GiB)
- m7i.2xlarge (8 vCPU、32 GiB)
- m7i.4xlarge (16 vCPU、64 GiB)
- m7i.8xlarge (32 vCPU、128 GiB)
- m7i.12xlarge (48 vCPU、192 GiB)
- m7i.16xlarge (64 vCPU、256 GiB)
- m7i.24xlarge (96 vCPU、384 GiB)
- m7i.48xlarge (192 vCPU、768 GiB)
- m7i.metal-24xl (96 vCPU、384 GiB)
- m7i.metal-48xl (192 vCPU、768 GiB)
- m7i-flex.xlarge (4 vCPU、16 GiB)
- m7i-flex.2xlarge (8 vCPU、32 GiB)
- m7i-flex.4xlarge (16 vCPU、64 GiB)
- m7i-flex.8xlarge (32 vCPU、128 GiB)
- m7a.xlarge (4 vCPU、16 GiB)
- m7a.2xlarge (8 vCPU、32 GiB)
- m7a.4xlarge (16 vCPU、64 GiB)
- m7a.8xlarge (32 vCPU、128 GiB)
- m7a.12xlarge (48 vCPU、192 GiB)
- m7a.16xlarge (64 vCPU、256 GiB)
- m7a.24xlarge (96 vCPU、384 GiB)
- m7a.32xlarge (128 vCPU、512 GiB)
- m7a.48xlarge (192 vCPU、768 GiB)
- m7a.metal-48xl (192 vCPU、768 GiB)
† これらのインスタンスタイプは、48 個の物理コアで 96 個の論理プロセッサーを提供します。これらは、2 つの物理 Intel ソケットを備えた単一サーバー上で実行します。
例3.2 バースト可能な汎用目的
- t3.xlarge (4 vCPU、16 GiB)
- t3.2xlarge (8 vCPU、32 GiB)
- t3a.xlarge (4 vCPU、16 GiB)
- t3a.2xlarge (8 vCPU、32 GiB)
例3.3 メモリー集約型
- x1.16xlarge (64 vCPU、976 GiB)
- x1.32xlarge (128 vCPU、1952 GiB)
- x1e.xlarge (4 vCPU、122 GiB)
- x1e.2xlarge (8 vCPU、244 GiB)
- x1e.4xlarge (16 vCPU、488 GiB)
- x1e.8xlarge (32 vCPU、976 GiB)
- x1e.16xlarge (64 vCPU、1,952 GiB)
- x1e.32xlarge (128 vCPU、3,904 GiB)
- x2idn.16xlarge (64 vCPU、1024 GiB)
- x2idn.24xlarge (96 vCPU、1536 GiB)
- x2idn.32xlarge (128 vCPU、2048 GiB)
- x2iedn.xlarge (4 vCPU、128 GiB)
- x2iedn.2xlarge (8 vCPU、256 GiB)
- x2iedn.4xlarge (16 vCPU、512 GiB)
- x2iedn.8xlarge (32 vCPU、1024 GiB)
- x2iedn.16xlarge (64 vCPU、2048 GiB)
- x2iedn.24xlarge (96 vCPU、3072 GiB)
- x2iedn.32xlarge (128 vCPU、4096 GiB)
- x2iezn.2xlarge (8 vCPU、256 GiB)
- x2iezn.4xlarge (16vCPU、512 GiB)
- x2iezn.6xlarge (24vCPU、768 GiB)
- x2iezn.8xlarge (32vCPU、1,024 GiB)
- x2iezn.12xlarge (48vCPU、1,536 GiB)
- x2idn.metal (128vCPU、2,048 GiB)
- x2iedn.metal (128vCPU、4,096 GiB)
- x2iezn.metal (48 vCPU、1,536 GiB)
例3.4 最適化されたメモリー
- r4.xlarge (4 vCPU、30.5 GiB)
- r4.2xlarge (8 vCPU、61 GiB)
- r4.4xlarge (16 vCPU、122 GiB)
- r4.8xlarge (32 vCPU、244 GiB)
- r4.16xlarge (64 vCPU、488 GiB)
- r5.metal (96† vCPU、768 GiB)
- r5.xlarge (4 vCPU、32 GiB)
- r5.2xlarge (8 vCPU、64 GiB)
- r5.4xlarge (16 vCPU、128 GiB)
- r5.8xlarge (32 vCPU、256 GiB)
- r5.12xlarge (48 vCPU、384 GiB)
- r5.16xlarge (64 vCPU、512 GiB)
- r5.24xlarge (96 vCPU、768 GiB)
- r5a.xlarge (4 vCPU、32 GiB)
- r5a.2xlarge (8 vCPU、64 GiB)
- r5a.4xlarge (16 vCPU、128 GiB)
- r5a.8xlarge (32 vCPU、256 GiB)
- r5a.12xlarge (48 vCPU、384 GiB)
- r5a.16xlarge (64 vCPU、512 GiB)
- r5a.24xlarge (96 vCPU、768 GiB)
- r5ad.xlarge (4 vCPU、32 GiB)
- r5ad.2xlarge (8 vCPU、64 GiB)
- r5ad.4xlarge (16 vCPU、128 GiB)
- r5ad.8xlarge (32 vCPU、256 GiB)
- r5ad.12xlarge(48 vCPU、384 GiB)
- r5ad.16xlarge (64 vCPU、512 GiB)
- r5ad.24xlarge (96 vCPU、768 GiB)
- r5d.metal (96† vCPU、768 GiB)
- r5d.xlarge (4 vCPU、32 GiB)
- r5d.2xlarge (8 vCPU、64 GiB)
- r5d.4xlarge (16 vCPU、128 GiB)
- r5d.8xlarge (32 vCPU、256 GiB)
- r5d.12xlarge (48 vCPU、384 GiB)
- r5d.16xlarge (64 vCPU、512 GiB)
- r5d.24xlarge (96 vCPU、768 GiB)
- r5n.metal (96 vCPU、768 GiB)
- r5n.xlarge (4 vCPU、32 GiB)
- r5n.2xlarge (8 vCPU、64 GiB)
- r5n.4xlarge (16 vCPU、128 GiB)
- r5n.8xlarge (32 vCPU、256 GiB)
- r5n.12xlarge (48 vCPU、384 GiB)
- r5n.16xlarge (64 vCPU、512 GiB)
- r5n.24xlarge (96 vCPU、768 GiB)
- r5dn.metal (96 vCPU、768 GiB)
- r5dn.xlarge (4 vCPU、32 GiB)
- r5dn.2xlarge (8 vCPU、64 GiB)
- r5dn.4xlarge (16 vCPU、128 GiB)
- r5dn.8xlarge (32 vCPU、256 GiB)
- r5dn.12xlarge(48 vCPU、384 GiB)
- r5dn.16xlarge (64 vCPU、512 GiB)
- r5dn.24xlarge (96 vCPU、768 GiB)
- r6a.xlarge (4 vCPU、32 GiB)
- r6a.2xlarge (8 vCPU、64 GiB)
- r6a.4xlarge (16 vCPU、128 GiB)
- r6a.8xlarge (32 vCPU、256 GiB)
- r6a.12xlarge (48 vCPU、384 GiB)
- r6a.16xlarge (64 vCPU、512 GiB)
- r6a.24xlarge (96 vCPU、768 GiB)
- r6a.32xlarge (128 vCPU、1,024 GiB)
- r6a.48xlarge (192 vCPU、1,536 GiB)
- r6i.metal (128 vCPU、1,024 GiB)
- r6i.xlarge (4 vCPU、32 GiB)
- r6i.2xlarge (8 vCPU、64 GiB)
- r6i.4xlarge (16 vCPU、128 GiB)
- r6i.8xlarge (32 vCPU、256 GiB)
- r6i.12xlarge (48 vCPU、384 GiB)
- r6i.16xlarge (64 vCPU、512 GiB)
- r6i.24xlarge (96 vCPU、768 GiB)
- r6i.32xlarge (128 vCPU、1,024 GiB)
- r6id.xlarge (4 vCPU、32 GiB)
- r6id.2xlarge (8 vCPU、64 GiB)
- r6id.4xlarge (16 vCPU、128 GiB)
- r6id.8xlarge (32 vCPU、256 GiB)
- r6id.12xlarge (48 vCPU、384 GiB)
- r6id.16xlarge (64 vCPU、512 GiB)
- r6id.24xlarge (96 vCPU、768 GiB)
- r6id.32xlarge (128 vCPU、1,024 GiB)
- z1d.metal (48 vCPU、384 GiB)
- z1d.xlarge (4 vCPU、32 GiB)
- z1d.2xlarge (8 vCPU、64 GiB)
- z1d.3xlarge (12 vCPU、96 GiB)
- z1d.6xlarge (24 vCPU、192 GiB)
- z1d.12xlarge (48 vCPU、384 GiB)
- r7iz.xlarge (4 vCPU、32 GiB)
- r7iz.2xlarge (8 vCPU、64 GiB)
- r7iz.4xlarge (16 vCPU、128 GiB)
- r7iz.8xlarge (32 vCPU、256 GiB)
- r7iz.12xlarge (48 vCPU、384 GiB)
- r7iz.16xlarge (64 vCPU、512 GiB)
- r7iz.32xlarge (128 vCPU、1024 GiB)
- r7iz.metal-16xl (64 vCPU、512 GiB)
- r7iz.metal-32xl (128 vCPU、1024 GiB)
† これらのインスタンスタイプは、48 個の物理コアで 96 個の論理プロセッサーを提供します。これらは、2 つの物理 Intel ソケットを備えた単一サーバー上で実行します。
これらのインスタンスタイプは、24 個の物理コアで 48 個の論理プロセッサーを提供します。
例3.5 高速コンピューティング
- p3.2xlarge (8 vCPU、61 GiB)
- p3.8xlarge (32 vCPU、244 GiB)
- p3.16xlarge (64 vCPU、488 GiB)
- p3dn.24xlarge (96 vCPU、768 GiB)
- p4d.24xlarge (96 vCPU、1,152 GiB)
- p4de.24xlarge (96 vCPU、1,152 GiB)
- p5.48xlarge (192 vCPU、2,048 GiB)
- g4dn.xlarge (4 vCPU、16 GiB)
- g4dn.2xlarge (8 vCPU、32 GiB)
- g4dn.4xlarge (16 vCPU、64 GiB)
- g4dn.8xlarge (32 vCPU、128 GiB)
- g4dn.12xlarge (48 vCPU、192 GiB)
- g4dn.16xlarge (64 vCPU、256 GiB)
- g4dn.metal (96 vCPU、384 GiB)
- g5.xlarge (4 vCPU、16 GiB)
- g5.2xlarge (8 vCPU、32 GiB)
- g5.4xlarge (16 vCPU、64 GiB)
- g5.8xlarge (32 vCPU、128 GiB)
- g5.16xlarge (64 vCPU、256 GiB)
- g5.12xlarge (48 vCPU、192 GiB)
- g5.24xlarge (96 vCPU、384 GiB)
- g5.48xlarge (192 vCPU、768 GiB)
- dl1.24xlarge (96 vCPU、768 GiB)†
† Intel 固有で Nvidia で対応していません。
GPU インスタンスタイプソフトウェアスタックのサポートは AWS によって提供されます。AWS サービスクォータが必要な GPU インスタンスタイプに対応できることを確認します。
例3.6 最適化されたコンピュート
- c5.metal (96 vCPU、192 GiB)
- c5.xlarge (4 vCPU、8 GiB)
- c5.2xlarge (8 vCPU、16 GiB)
- c5.4xlarge (16 vCPU、32 GiB)
- c5.9xlarge (36 vCPU、72 GiB)
- c5.12xlarge (48 vCPU、96 GiB)
- c5.18xlarge (72 vCPU、144 GiB)
- c5.24xlarge (96 vCPU、192 GiB)
- c5d.metal (96 vCPU、192 GiB)
- c5d.xlarge (4 vCPU、8 GiB)
- c5d.2xlarge (8 vCPU、16 GiB)
- c5d.4xlarge (16 vCPU、32 GiB)
- c5d.9xlarge (36 vCPU、72 GiB)
- c5d.12xlarge (48 vCPU、96 GiB)
- c5d.18xlarge(72 vCPU、144 GiB)
- c5d.24xlarge (96 vCPU、192 GiB)
- c5a.xlarge (4 vCPU、8 GiB)
- c5a.2xlarge (8 vCPU、16 GiB)
- c5a.4xlarge (16 vCPU、32 GiB)
- c5a.8xlarge (32 vCPU、64 GiB)
- c5a.12xlarge (48 vCPU、96 GiB)
- c5a.16xlarge (64 vCPU、128 GiB)
- c5a.24xlarge (96 vCPU、192 GiB)
- c5ad.xlarge (4 vCPU、8 GiB)
- c5ad.2xlarge (8 vCPU、16 GiB)
- c5ad.4xlarge (16 vCPU、32 GiB)
- c5ad.8xlarge (32 vCPU、64 GiB)
- c5ad.12xlarge (48 vCPU、96 GiB)
- c5ad.16xlarge (64 vCPU、128 GiB)
- c5ad.24xlarge (96 vCPU、192 GiB)
- c5n.metal (72 vCPU、192 GiB)
- c5n.xlarge (4 vCPU、10.5 GiB)
- c5n.2xlarge (8 vCPU、21 GiB)
- c5n.4xlarge (16 vCPU、42 GiB)
- c5n.9xlarge (36 vCPU、96 GiB)
- c5n.18xlarge (72 vCPU、192 GiB)
- c6a.xlarge (4 vCPU、8 GiB)
- c6a.2xlarge (8 vCPU、16 GiB)
- c6a.4xlarge (16 vCPU、32 GiB)
- c6a.8xlarge (32 vCPU、64 GiB)
- c6a.12xlarge (48 vCPU、96 GiB)
- c6a.16xlarge (64 vCPU、128 GiB)
- c6a.24xlarge (96 vCPU、192 GiB)
- c6a.32xlarge (128 vCPU、256 GiB)
- c6a.48xlarge (192 vCPU、384 GiB)
- c6i.metal (128 vCPU、256 GiB)
- c6i.xlarge (4 vCPU、8 GiB)
- c6i.2xlarge (8 vCPU、16 GiB)
- c6i.4xlarge (16 vCPU、32 GiB)
- c6i.8xlarge (32 vCPU、64 GiB)
- c6i.12xlarge (48 vCPU、96 GiB)
- c6i.16xlarge (64 vCPU、128 GiB)
- c6i.24xlarge (96 vCPU、192 GiB)
- c6i.32xlarge (128 vCPU、256 GiB)
- c6id.xlarge (4 vCPU、8 GiB)
- c6id.2xlarge (8 vCPU、16 GiB)
- c6id.4xlarge (16 vCPU、32 GiB)
- c6id.8xlarge (32 vCPU、64 GiB)
- c6id.12xlarge (48 vCPU、96 GiB)
- c6id.16xlarge (64 vCPU、128 GiB)
- c6id.24xlarge (96 vCPU、192 GiB)
- c6id.32xlarge (128 vCPU、256 GiB)
例3.7 最適化されたストレージ
- i3.metal (72† vCPU、512 GiB)
- i3.xlarge (4 vCPU、30.5 GiB)
- i3.2xlarge (8 vCPU、61 GiB)
- i3.4xlarge (16 vCPU、122 GiB)
- i3.8xlarge (32 vCPU、244 GiB)
- i3.16xlarge (64 vCPU、488 GiB)
- i3en.metal (96 vCPU、768 GiB)
- i3en.xlarge (4 vCPU、32 GiB)
- i3en.2xlarge (8 vCPU、64 GiB)
- i3en.3xlarge (12 vCPU、96 GiB)
- i3en.6xlarge (24 vCPU、192 GiB)
- i3en.12xlarge (48 vCPU、384 GiB)
- i3en.24xlarge (96 vCPU、768 GiB)
- i4i.xlarge (4 vCPU、32 GiB)
- i4i.2xlarge (8 vCPU、64 GiB)
- i4i.4xlarge (16 vCPU、128 GiB)
- i4i.8xlarge (32 vCPU、256 GiB)
- i4i.12xlarge (48 vCPU、384 GiB)
- i4i.16xlarge (64 vCPU、512 GiB)
- i4i.24xlarge (96 vCPU、768 GiB)
- i4i.32xlarge (128 vCPU、1024 GiB)
- i4i.metal (128 vCPU、1024 GiB)
† このインスタンスタイプは、36 個の物理コアで 72 個の論理プロセッサーを提供します。
仮想インスタンスタイプは、.metal インスタンスタイプよりも速く初期化されます。
例3.8 高メモリー
- u-3tb1.56xlarge (224 vCPU、3,072 GiB)
- u-6tb1.56xlarge (224 vCPU、6,144 GiB)
- u-6tb1.112xlarge (448 vCPU、6,144 GiB)
- u-6tb1.metal (448 vCPU、6,144 GiB)
- u-9tb1.112xlarge (448 vCPU、9,216 GiB)
- u-9tb1.metal (448 vCPU、9,216 GiB)
- u-12tb1.112xlarge (448 vCPU、12,288 GiB)
- u-12tb1.metal (448 vCPU、12,288 GiB)
- u-18tb1.metal (448 vCPU、18,432 GiB)
- u-24tb1.metal (448 vCPU、24,576 GiB)
関連情報
3.3.1.5. リージョンおよびアベイラビリティーゾーン
現在、以下の AWS リージョンが Red Hat OpenShift 4 で利用可能であり、Red Hat OpenShift Service on AWS でサポートされています。
OpenShift 4 のサポートの有無にかかわらず、中国リージョンはサポートされません。
GovCloud (US) リージョンの場合は、Access request for Red Hat OpenShift Service on AWS (ROSA) FedRAMP を送信する必要があります。
GovCloud (US) リージョンは、ROSA Classic クラスターでのみサポートされます。
例3.9 AWS リージョン
- us-east-1 (N. Virginia)
- us-east-2 (Ohio)
- us-west-1 (N. California)
- us-west-2 (Oregon)
- af-south-1 (Cape Town、AWS オプトインが必要)
- ap-east-1 (Hong Kong、AWS オプトインが必要)
- ap-south-2 (Hyderabad、AWS オプトインが必要)
- ap-southeast-3 (Jakarta、AWS オプトインが必要)
- ap-southeast-4 (Melbourne、AWS オプトインが必要)
- ap-south-1 (Mumbai)
- ap-northeast-3 (Osaka)
- ap-northeast-2 (Seoul)
- ap-southeast-1 (Singapore)
- ap-southeast-2 (Sydney)
- ap-northeast-1 (Tokyo)
- ca-central-1 (Central Canada)
- eu-central-1 (Frankfurt)
- eu-west-1 (Ireland)
- eu-west-2 (London)
- eu-south-1 (Milan、AWS オプトインが必要)
- eu-west-3 (Paris)
- me-south-1 (Bahrain、AWS オプトインが必要)
- me-central-1 (UAE、AWS オプトインが必要)
- sa-east-1 (São Paulo)
- us-gov-east-1 (AWS GovCloud - 米国東部)
- us-gov-west-1 (AWS GovCloud - 米国西部)
複数のアベイラビリティーゾーンのクラスターは、少なくとも 3 つのアベイラビリティーゾーンのあるリージョンにのみデプロイできます。詳細は、AWS ドキュメントの Regions and Availability Zones セクションを参照してください。
新規 Red Hat OpenShift Service on AWS クラスターはそれぞれ、インストーラーで作成された Virtual Private Cloud (VPC)、または既存の Virtual Private Cloud (VPC) 内にインストールされます。オプションとして、単一アベイラビリティーゾーン (Single-AZ) または複数アベイラビリティーゾーン (Multi-AZ) にデプロイすることができます。これにより、クラスターレベルのネットワークおよびリソースの分離が行われ、VPN 接続や VPC ピアリングなどのクラウドプロバイダーの VPC 設定が有効になります。永続ボリューム (PV) は Amazon Elastic Block Storage (Amazon EBS) によってサポートされ、それらがプロビジョニングされるアベイラビリティーゾーンに固有のものとして機能します。永続ボリューム要求 (PVC) は、Pod がスケジュールできなくなる状況を防ぐために、関連付けられた Pod リソースが特定のアベイラビリティーゾーンに割り当てられるまでボリュームにバインドされません。アベイラビリティーゾーン固有のリソースは、同じアベイラビリティーゾーン内のリソースでのみ利用できます。
リージョンおよびアベイラビリティーゾーンの単一または複数の選択は、クラスターのデプロイ後に変更できません。
3.3.1.6. Local Zones
Red Hat OpenShift Service on AWS は、顧客がレイテンシーの影響を受けやすいアプリケーションのワークロードを配置できる大都市集中型のアベイラビリティーゾーンである AWS Local Zones の使用をサポートします。Local Zones は、独自のインターネット接続を持つ AWS リージョンの拡張です。AWS Local Zones の詳細は、AWS ドキュメント How Local Zones work を参照してください。
AWS Local Zones を有効にして Local Zone をマシンプールに追加する手順は、マシンプール用のローカルゾーンの設定 を参照してください。
3.3.1.7. Service Level Agreement (SLA)
サービス自体の SLA は、Red Hat Enterprise Agreement Appendix 4 (Online Subscription Services) で定義されています。
3.3.1.8. 限定サポートステータス
クラスターが 限定サポート ステータスに移行すると、Red Hat はクラスターをプロアクティブに監視しなくなり、SLA は適用されなくなり、SLA に対して要求されたクレジットは拒否されます。製品サポートがなくなったという意味ではありません。場合によっては、違反要因を修正すると、クラスターが完全にサポートされた状態に戻ることがあります。ただし、それ以外の場合は、クラスターを削除して再作成する必要があります。
クラスターは、次のシナリオなど、さまざまな理由で限定サポートステータスに移行する場合があります。
- サポート終了日までにクラスターをサポートされるバージョンにアップグレードしない場合
Red Hat は、サポート終了日以降のバージョンについて、ランタイムまたは SLA を保証しません。継続的なサポートを受けるには、サポートが終了する前に、クラスターを、サポートされているバージョンにアップグレードしてください。有効期限が切れる前にクラスターをアップグレードしない場合、クラスターは、サポートされているバージョンにアップグレードされるまで、限定サポートステータスに移行します。
Red Hat は、サポートされていないバージョンからサポートされているバージョンにアップグレードするための商業的に合理的なサポートを提供します。ただし、サポートされるアップグレードパスが利用できなくなった場合は、新規クラスターを作成し、ワークロードを移行することが必要になることがあります。
- ネイティブの Red Hat OpenShift Service on AWS コンポーネント、または Red Hat がインストールおよび管理するその他のコンポーネントを削除または置き換える場合
- クラスター管理者パーミッションを使用した場合、Red Hat は、インフラストラクチャーサービス、サービスの可用性、またはデータ損失に影響を与えるアクションを含む、ユーザーまたは認可されたユーザーのアクションに対して責任を負いません。Red Hat がそのようなアクションを検出した場合、クラスターは限定サポートステータスに移行する可能性があります。Red Hat はステータスの変更を通知します。アクションを元に戻すか、サポートケースを作成して、クラスターの削除と再作成が必要になる可能性のある修復手順を検討する必要があります。
クラスターが限定サポートステータスに移行する可能性のある特定のアクションについて質問がある場合、またはさらに支援が必要な場合は、サポートチケットを作成します。
3.3.1.9. サポート
Red Hat OpenShift Service on AWS には Red Hat Premium サポートが含まれており、このサポートは Red Hat カスタマーポータル を使用して利用できます。
サポートの応答時間については、Red Hat OpenShift Service on AWS の SLA を参照してください。
AWS サポートは、AWS との既存のサポート契約に基づきます。
3.3.2. ロギング
Red Hat OpenShift Service on AWS は、Amazon (AWS) CloudWatch へのオプションの統合ログ転送を提供します。
3.3.2.1. クラスター監査ロギング
クラスター監査ログは、インテグレーションが有効になっている場合に AWS CloudWatch 経由で利用できます。インテグレーションが有効でない場合は、サポートケースを作成して監査ログをリクエストできます。
3.3.2.2. アプリケーションロギング
STDOUT
に送信されるアプリケーションログは Fluentd によって収集され、クラスターロギングスタックで AWS CloudWatch に転送されます (インストールされている場合)。
3.3.3. モニタリング
このセクションでは、Red Hat OpenShift Service on AWS モニタリングのサービス定義を説明します。
3.3.3.1. クラスターメトリック
Red Hat OpenShift Service on AWS クラスターには、CPU、メモリー、ネットワークベースのメトリクスを含むクラスターモニタリングの統合された Prometheus スタックが同梱されます。これは Web コンソールからアクセスできます。また、これらのメトリックは Red Hat OpenShift Service on AWS ユーザーによって提供される CPU またはメモリーメトリックをベースとする Horizontal Pod Autoscaling を許可します。
3.3.3.2. クラスターステータスの通知
Red Hat は、OpenShift Cluster Manager で利用可能なクラスターダッシュボードと、クラスターの初回デプロイで使用した連絡先、およびお客様が指定する追加の連絡先のメールアドレスに送信されるメール通知を使用して、Red Hat OpenShift Service on AWS クラスターの正常性およびステータスについて通信します。
3.3.4. ネットワーク
このセクションでは、Red Hat OpenShift Service on AWS ネットワークのサービス定義を説明します。
3.3.4.1. アプリケーションのカスタムドメイン
ルートにカスタムホスト名を使用するには、正規名 (CNAME) レコードを作成して DNS プロバイダーを更新する必要があります。CNAME レコードでは、OpenShift の正規ルーターのホスト名をカスタムドメインにマップする必要があります。OpenShift の正規ルーターのホスト名は、ルートの作成後に Route Details ページに表示されます。または、ワイルドカード CNAME レコードを 1 度作成して、指定のホスト名のすべてのサブドメインをクラスターのルーターにルーティングできます。
Red Hat OpenShift Service on AWS 4.14 以降、Custom Domain Operator は非推奨になりました。Red Hat OpenShift Service on AWS 4.14 以降で Ingress を管理するには、Ingress Operator を使用します。Red Hat OpenShift Service on AWS 4.13 以前のバージョンでは機能に変更はありません。
3.3.4.2. ドメイン検証証明書
Red Hat OpenShift Service on AWS には、クラスターの内部サービスと外部サービスの両方に必要な TLS セキュリティー証明書が含まれます。外部ルートの場合は、各クラスターに提供され、インストールされる 2 つの別個の TLS ワイルドカード証明書があります。1 つは Web コンソールおよびルートのデフォルトホスト名用であり、もう 1 つは API エンドポイント用です。Let's Encrypt は証明書に使用される認証局です。内部の API エンドポイント などのクラスター内のルートでは、クラスターの組み込み認証局によって署名された TLS 証明書を使用し、TLS 証明書を信頼するためにすべての Pod で CA バンドルが利用可能である必要があります。
3.3.4.3. ビルドのカスタム認証局
Red Hat OpenShift Service on AWS は、イメージレジストリーからイメージをプルする際にビルドによって信頼されるカスタム認証局の使用をサポートします。
3.3.4.4. ロードバランサー
Red Hat OpenShift Service on AWS は、最大 5 つの異なるロードバランサーを使用します。
- クラスターの内部にあり、内部のクラスター通信のトラフィックのバランスを取るために使用される内部コントロールプレーンのロードバランサー。
- OpenShift および Kubernetes API へのアクセスに使用される外部コントロールプレーンのロードバランサー。このロードバランサーは OpenShift Cluster Manager で無効にできます。このロードバランサーが無効にされている場合、Red Hat は API DNS を内部コントロールプレーンのロードバランサーを参照するように再設定します。
- Red Hat によるクラスター管理用に予約される Red Hat の外部コントロールプレーンのロードバランサー。アクセスは厳密に制御され、ホワイトリストに登録されている bastion ホストからのみ通信が可能です。
-
デフォルトのアプリケーションロードバランサーであるデフォルトの外部ルーター/ingress ロードバランサー (URL の
apps
で示される)。デフォルトのロードバランサーを OpenShift Cluster Manager で設定して、インターネット上で一般にアクセス可能にしたり、既存のプライベート接続でプライベートにのみアクセス可能にしたりできます。ロギング UI、メトリック API、レジストリーなどのクラスターサービスを含む、クラスターのすべてのアプリケーションルートは、このデフォルトのルーターロードバランサーで公開されます。 -
オプション: セカンダリーアプリケーションロードバランサーであるセカンダリールーター/ingress ロードバランサー (URL の
apps2
で示される)。セカンダリーロードバランサーを OpenShift Cluster Manager で設定して、インターネット上で一般にアクセス可能にしたり、既存のプライベート接続でプライベートにのみアクセス可能にしたりできます。Label match
がこのルーターロードバランサーに設定されている場合は、このラベルに一致するアプリケーションルートのみがこのルーターロードバランサーで公開されます。それ以外の場合は、すべてのアプリケーションルートがこのルーターロードバランサーで公開されます。 - オプション: サービスのロードバランサー。サービスの非 HTTP/SNI トラフィックおよび非標準ポートを有効にします。これらのロードバランサーを Red Hat OpenShift Service on AWS で実行されているサービスにマップし、HTTP/SNI 以外のトラフィックや標準以外のポートの使用などの高度な ingress 機能を有効にできます。各 AWS アカウントには、各クラスター内で使用できる Classic Load Balancer の数を制限 するクォータがあります。
3.3.4.5. クラスター ingress
プロジェクト管理者は、IP 許可リストによる ingress の制御など、さまざまな目的でルートアノテーションを追加できます。
Ingress ポリシーは、ovs-networkpolicy
プラグインを使用する NetworkPolicy
オブジェクトを使用して変更することもできます。これにより、同じクラスターの Pod 間や同じ namespace にある Pod 間など、Ingress ネットワークポリシーを Pod レベルで完全に制御できます。
すべてのクラスター ingress トラフィックは定義されたロードバランサーを通過します。すべてのノードへの直接のアクセスは、クラウド設定によりブロックされます。
3.3.4.6. クラスター egress
EgressNetworkPolicy
オブジェクトでの Pod egress トラフィックの制御は、Red Hat OpenShift Service on AWS での送信トラフィックを防ぐか、これを制限するために使用できます。
コントロールプレーンおよびインフラストラクチャーノードからの公開される送信トラフィックは、クラスターイメージのセキュリティーおよびクラスターのモニタリングを維持するために必要です。これには、0.0.0.0/0
ルートがインターネットゲートウェイにのみ属している必要があります。プライベート接続でこの範囲のルートをルーティングすることはできません。
OpenShift 4 クラスターは NAT ゲートウェイを使用して、クラスターからの公開される送信トラフィックのパブリック静的 IP を表示します。クラスターがデプロイされるそれぞれのアベイラビリティーゾーンは個別の NAT ゲートウェイを受信するため、最大 3 つの固有の静的 IP アドレスがクラスターの egress トラフィックについて存在する可能性があります。クラスター内に留まるトラフィックや、パブリックインターネットに送信されないトラフィックは NAT ゲートウェイを通過せず、トラフィックの送信元となるノードに属するソース IP アドレスを持ちます。ノード IP アドレスは動的であるため、お客様はプライベートリソースへのアクセス時に個々の IP アドレスをホワイトリストに入れることはできません。
お客様はクラスター上で Pod を実行し、外部サービスをクエリーすることで、パブリック静的 IP アドレスを判別できます。以下に例を示します。
$ oc run ip-lookup --image=busybox -i -t --restart=Never --rm -- /bin/sh -c "/bin/nslookup -type=a myip.opendns.com resolver1.opendns.com | grep -E 'Address: [0-9.]+'"
3.3.4.7. クラウドネットワーク設定
Red Hat OpenShift Service on AWS では、次のような AWS 管理のテクノロジーを使用してプライベートネットワーク接続を設定できます。
- VPN 接続
- VPC ピアリング
- Transit Gateway
- Direct Connect
Red Hat のサイト信頼性エンジニアリング (SRE) チームは、プライベートネットワーク接続を監視しません。これらの接続の監視は、お客様の責任で行われます。
3.3.4.8. DNS 転送
プライベートクラウドネットワーク設定を持つ Red Hat OpenShift Service on AWS クラスターの場合、お客様はそのプライベート接続で利用可能な内部 DNS サーバーを指定でき、明示的に提供されるドメインについてこれをクエリーする必要があります。
3.3.4.9. ネットワークの検証
Red Hat OpenShift Service on AWS クラスターを既存の Virtual Private Cloud (VPC) にデプロイするとき、またはクラスターに新しいサブネットを持つ追加のマシンプールを作成するときに、ネットワーク検証チェックが自動的に実行します。このチェックによりネットワーク設定が検証され、エラーが強調表示されるため、デプロイメント前に設定の問題を解決できます。
ネットワーク検証チェックを手動で実行して、既存のクラスターの設定を検証することもできます。
関連情報
- ネットワーク検証チェックの詳細は、ネットワーク検証 を参照してください。
3.3.5. ストレージ
このセクションでは、Red Hat OpenShift Service on AWS ストレージのサービス定義を説明します。
3.3.5.1. 保存時に暗号化される (Encrypted-at-rest) OS およびノードストレージ
コントロールプレーン、インフラストラクチャー、およびワーカーノードは、保存時に暗号化された Amazon Elastic Block Store (Amazon EBS) ストレージを使用します。
3.3.5.2. 暗号化された保存時の PV
PV に使用される EBS ボリュームはデフォルトで保存時に暗号化されます。
3.3.5.3. ブロックストレージ (RWO)
永続ボリューム (PV) は、Read-Write-Once の Amazon Elastic Block Store (Amazon EBS) によってサポートされています。
PV は一度に 1 つのノードにのみ割り当てられ、それらがプロビジョニングされるアベイラビリティーゾーンに固有のものです。ただし、PV はそのアベイラビリティーゾーンの任意のノードに割り当てることができます。
各クラウドプロバイダーには、1 つのノードに割り当てることのできる PV の数について独自の制限があります。詳細は、AWS インスタンスタイプの制限 を参照してください。
3.3.5.4. 共有ストレージ (RWX)
AWS CSI ドライバーは、Red Hat OpenShift Service on AWS の RWX サポートを提供するのに使用できます。コミュニティー Operator は、設定を簡素化するために提供されます。詳細は、Amazon Elastic File Storage Setup for OpenShift Dedicated and Red Hat OpenShift Service on AWS を参照してください。
3.3.6. プラットフォーム
このセクションでは、Red Hat OpenShift Service on AWS (ROSA) プラットフォームのサービス定義を説明します。
3.3.6.1. クラスターバックアップポリシー
Red Hat は、デフォルト構成である STS を使用する ROSA クラスターのバックアップ方法を提供していません。お客様がアプリケーションとアプリケーションデータのバックアップ計画を立てることが重要です。以下の表は、IAM ユーザー認証情報を使用して作成されたクラスターにのみ適用されます。
アプリケーションおよびアプリケーションデータのバックアップは Red Hat OpenShift Service on AWS サービスの一部として行われません。次の表に、クラスターバックアップポリシーの概要を示します。
コンポーネント | スナップショットの頻度 | 保持期間 | 注記 |
---|---|---|---|
完全なオブジェクトストアのバックアップ | 毎日 | 7 日 | これは、etcd などのすべての Kubernetes オブジェクトの完全バックアップです。このバックアップスケジュールでは、永続ボリューム (PV) がバックアップされていません。 |
週次 | 30 日 | ||
完全なオブジェクトストアのバックアップ | 毎時 | 24 時間 | これは、etcd などのすべての Kubernetes オブジェクトの完全バックアップです。このバックアップスケジュールでは、PV はバックアップされません。 |
ノードのルートボリューム | なし | 該当なし | ノードは短期的なものと見なされます。ノードのルートボリュームには、何も保存できません。 |
3.3.6.2. 自動スケーリング
ノードの自動スケーリングは Red Hat OpenShift Service on AWS で利用できます。オートスケーラーオプションを設定して、クラスター内のマシンの数を自動的にスケーリングできます。
3.3.6.3. デーモンセット
Red Hat OpenShift Service on AWS でデーモンセットを作成し、実行できます。デーモンセットをワーカーノードでのみの実行に制限するには、以下の nodeSelector
を使用します。
... spec: nodeSelector: role: worker ...
3.3.6.4. 複数のアベイラビリティーゾーン
複数アベイラビリティーゾーンのクラスターでは、コントロールプレーンノードは複数のアベイラビリティーゾーンに分散され、各アベイラビリティーゾーンに 1 つ以上のワーカーノードが必要になります。
3.3.6.5. ノードラベル
カスタムノードラベルはノードの作成時に Red Hat によって作成され、現時点では Red Hat OpenShift Service on AWS クラスターで変更することはできません。ただし、カスタムラベルは新規マシンプールの作成時にサポートされます。
3.3.6.6. OpenShift のバージョン
Red Hat OpenShift Service on AWS はサービスとして実行され、最新の OpenShift Container Platform バージョンで最新の状態に維持されます。最新バージョンへのアップグレードのスケジューリング機能を利用できます。
3.3.6.7. アップグレード
アップグレードは、ROSA CLI、rosa
、または OpenShift Cluster Manager を使用してスケジュールできます。
アップグレードポリシーおよび手順の詳細は、Red Hat OpenShift Service on AWS のライフサイクル を参照してください。
3.3.6.8. Windows Containers
現時点では、Windows コンテナーに対する Red Hat OpenShift のサポートは Red Hat OpenShift Service on AWS では利用できません。
3.3.6.9. コンテナーエンジン
Red Hat OpenShift Service on AWS は OpenShift 4 で実行し、唯一の利用可能なコンテナーエンジンとして CRI-O を使用します。
3.3.6.10. オペレーティングシステム
Red Hat OpenShift Service on AWS は OpenShift 4 で実行され、すべてのコントロールプレーンおよびワーカーノードのオペレーティングシステムとして Red Hat CoreOS を使用します。
3.3.6.11. Red Hat Operator のサポート
通常、Red Hat ワークロードは、Operator Hub を通じて利用できる Red Hat 提供の Operator を指します。Red Hat ワークロードは Red Hat SRE チームによって管理されないため、ワーカーノードにデプロイする必要があります。これらの Operator は、追加の Red Hat サブスクリプションが必要になる場合があり、追加のクラウドインフラストラクチャーコストが発生する場合があります。これらの Red Hat 提供の Operator の例は次のとおりです。
- Red Hat Quay
- Red Hat Advanced Cluster Management
- Red Hat Advanced Cluster Security
- Red Hat OpenShift Service Mesh
- OpenShift Serverless
- Red Hat OpenShift Logging
- Red Hat OpenShift Pipelines
3.3.6.12. Kubernetes Operator のサポート
OperatorHub marketplace にリスト表示されるすべての Operator はインストールに利用できるはずです。これらの Operator はお客様のワークロードと見なされるため、Red Hat SRE の監視の対象外です。
3.3.7. セキュリティー
このセクションでは、Red Hat OpenShift Service on AWS セキュリティーのサービス定義を説明します。
3.3.7.1. 認証プロバイダー
クラスターの認証は、OpenShift Cluster Manager またはクラスター作成プロセスを使用するか、ROSA CLI rosa
を使用して設定できます。ROSA はアイデンティティープロバイダーではないため、クラスターへのアクセスすべてが統合ソリューションの一部としてお客様によって管理される必要があります。同時にプロビジョニングされる複数のアイデンティティープロバイダーの使用がサポートされます。以下のアイデンティティープロバイダーがサポートされます。
- GitHub または GitHub Enterprise
- GitLab
- LDAP
- OpenID Connect
- htpasswd
3.3.7.2. 特権付きコンテナー
特権付きコンテナーは、cluster-admin
ロールを持つユーザーが利用できます。特権付きコンテナーを cluster-admin
として使用する場合、これは Red Hat Enterprise Agreement Appendix 4 (Online Subscription Services) の責任および除外事項に基づいて使用されます。
3.3.7.3. お客様管理者ユーザー
Red Hat OpenShift Service on AWS は、通常のユーザーに加えて、dedicated-admin
と呼ばれる ROSA 固有のグループへのアクセスを提供します。dedicated-admin
グループのメンバーであるクラスターのすべてのユーザーは、以下を実行できます。
- クラスターでお客様が作成したすべてのプロジェクトへの管理者アクセス権を持ちます。
- クラスターのリソースクォータと制限を管理できます。
-
NetworkPolicy
オブジェクトを追加および管理できます。 - スケジューラー情報を含む、クラスター内の特定のノードおよび PV に関する情報を表示できます。
-
クラスター上の予約された
dedicated-admin
プロジェクトにアクセスできます。これにより、昇格された権限を持つサービスアカウントの作成が可能になり、クラスター上のプロジェクトのデフォルトの制限とクォータを更新できるようになります。 -
OperatorHub から Operator をインストールし、すべての
*.operators.coreos.com
API グループのすべての動詞を実行できます。
3.3.7.4. クラスター管理ロール
Red Hat OpenShift Service on AWS の管理者には、組織のクラスターについて cluster-admin
ロールへのデフォルトアクセスがあります。cluster-admin
ロールを持つアカウントにログインしている場合、ユーザーのパーミッションは、特権付きセキュリティーコンテキストを実行するために拡大します。
3.3.7.5. プロジェクトのセルフサービス
デフォルトで、すべてのユーザーはプロジェクトを作成し、更新し、削除できます。これは、dedicated-admin
グループのメンバーが認証されたユーザーから self-provisioner
ロールを削除すると制限されます。
$ oc adm policy remove-cluster-role-from-group self-provisioner system:authenticated:oauth
以下を適用すると、制限を元に戻すことができます。
$ oc adm policy add-cluster-role-to-group self-provisioner system:authenticated:oauth
3.3.7.6. 規制コンプライアンス
最新のコンプライアンス情報は、「Red Hat OpenShift Service on AWS のプロセスおよびセキュリティーについて」を参照してください。
3.3.7.7. ネットワークセキュリティー
Red Hat OpenShift Service on AWS では、AWS は AWS Shield と呼ばれる標準の DDoS 保護をすべてのロードバランサーで提供します。これにより、Red Hat OpenShift Service on AWS に使用されるすべてのパブリック向けロードバランサーで最も一般的に使用されるレベル 3 および 4 攻撃に対し、95% の保護が提供されます。応答を受信するために haproxy
ルーターに送信される HTTP 要求に 10 秒のタイムアウトが追加されるか、追加の保護を提供するために接続が切断されます。
3.3.7.8. etcd 暗号化
Red Hat OpenShift Service on AWS では、コントロールプレーンストレージがデフォルトで保存時に暗号化されます。これには etcd ボリュームの暗号化も含まれます。このストレージレベルの暗号化は、クラウドプロバイダーのストレージ層を介して提供されます。
etcd 暗号化を有効にして、キーではなく etcd のキーの値を暗号化することもできます。etcd 暗号化を有効にすると、以下の Kubernetes API サーバーおよび OpenShift API サーバーリソースが暗号化されます。
- シークレット
- 設定マップ
- ルート
- OAuth アクセストークン
- OAuth 認証トークン
etcd 暗号化機能はデフォルトで有効にされず、これはクラスターのインストール時にのみ有効にできます。etcd 暗号化が有効にされている場合でも、コントロールプレーンノードにアクセスできるユーザーまたは cluster-admin
権限を持つユーザーは、etcd キーの値にアクセスできます。
etcd のキー値の etcd 暗号化を有効にすると、約 20% のパフォーマンスのオーバーヘッドが発生します。このオーバーヘッドは、etcd ボリュームを暗号化するデフォルトのコントロールプレーンのストレージ暗号化に加えて、この 2 つ目の暗号化レイヤーの導入により生じます。Red Hat は、お客様のユースケースで特に etcd 暗号化が必要な場合にのみ有効にすることを推奨します。
3.3.8. 関連情報
- 最新のコンプライアンス情報は、Red Hat OpenShift Service on AWS のプロセスおよびセキュリティーについて を参照してください。
- ROSA のライフサイクル を参照してください。
3.4. Red Hat OpenShift Service on AWS 更新ライフサイクル
3.4.1. 概要
Red Hat は、Red Hat OpenShift Service on AWS の製品ライフサイクルを公開しています。これにより、お客様およびパートナー様は、プラットフォーム上で実行されるアプリケーションの計画、デプロイ、サポートを効果的に行えます。Red Hat は、可能な限りの透明性を実現するためにこのライフサイクルを公開していますが、問題が発生した場合はこれらのポリシーに例外を設ける場合もあります。
Red Hat OpenShift Service on AWS は Red Hat OpenShift のマネージドインスタンスであり、独立したリリーススケジュールを維持します。マネージドオファリングについての詳細は、Red Hat OpenShift Service on AWS のサービス定義を参照してください。特定バージョンのセキュリティーアドバイザリーおよびバグ修正アドバイザリーは、Red Hat OpenShift Container Platform のライフサイクルポリシーに基づいて利用可能となり、Red Hat OpenShift Service on AWS のメンテナンススケジュールに基づいて提供されます。
3.4.2. 定義
表3.1 バージョン参照
バージョンの形式 | メジャー | マイナー | パッチ | major.minor.patch |
---|---|---|---|---|
x | y | z | x.y.z | |
例 | 4 | 5 | 21 | 4.5.21 |
- メジャーリリースまたは X リリース
メジャーリリース または X リリース (X.y.z) としてのみ言及されます。
例
- "メジャーリリース 5" → 5.y.z
- "メジャーリリース 4" → 4.y.z
- "メジャーリリース 3" → 3.y.z
- マイナーリリースまたは Y リリース
マイナーリリース または Y リリース (x.Y.z) としてのみ言及されます。
例
- "マイナーリリース 4" → 4.4.z
- "マイナーリリース 5" → 4.5.z
- "マイナーリリース 6" → 4.6.z
- パッチリリースまたは Z リリース
パッチリリース または Z リリース (x.y.Z) としてのみ言及されます。
例
- "マイナーリリース 5 のパッチリリース 14" → 4.5.14
- "マイナーリリース 5 のパッチリリース 25" → 4.5.25
- "マイナーリリース 6 のパッチリリース 26" → 4.6.26
3.4.3. メジャーバージョン (X.y.z)
Red Hat OpenShift Service on AWS のメジャーバージョン (バージョン 4 など) は、後続のメジャーバージョンのリリースまたは製品の終了後 1 年間サポートされます。
例
- Red Hat OpenShift Service on AWS についてバージョン 5 が 1 月 1 日に利用可能になる場合、バージョン 4 は 12 月 31 日までの 12 カ月間、マネージドクラスターで実行を継続できます。その後、クラスターはアップグレード、またはバージョン 5 に移行する必要があります。
3.4.4. マイナーバージョン (x.Y.z)
4.8 OpenShift Container Platform マイナーバージョン以降、Red Hat は、特定のマイナーバージョンが一般公開されてから 16 か月間以上、すべてのマイナーバージョンをサポートします。パッチバージョンは、サポート期間の影響を受けません。
サポート期間が終了する 60 日前、30 日前、および 15 日前に、お客様に通知されます。サポート期間が終了する前に、サポート対象の最も古いマイナーバージョンの最新のパッチバージョンにクラスターをアップグレードする必要があります。アップグレードしないと、クラスターが "限定サポート" ステータスになります。
例
- 現時点で、お客様のクラスターは 4.13.8 で実行しているとします。4.13 マイナーバージョンは、2023 年 5 月 17 日に一般提供されました。
- 2024 年 7 月 19 日、8 月 16 日、および 9 月 2 日に、クラスターがサポート対象のマイナーバージョンにまだアップグレードされていない場合、2024 年 9 月 17 日にクラスターが "限定サポート" ステータスになることがお客様に通知されます。
- クラスターは、2024 年 9 月 17 日までに 4.14 以降にアップグレードする必要があります。
- アップグレードが実行されていない場合、クラスターに "限定サポート" ステータスのフラグが設定されます。
3.4.5. パッチバージョン (x.y.Z)
マイナーバージョンがサポートされる期間中、とくに指定がない限り、Red Hat はすべての OpenShift Container Platform パッチバージョンをサポートします。
プラットフォームのセキュリティーおよび安定性の理由から、あるパッチリリースが非推奨になる可能性があります。この場合は、そのリリースのインストールができなくなり、そのリリースからの強制的なアップグレードが必要となります。
例
- 4.7.6 に重要な CVE が含まれることが確認されるとします。
- CVE の影響を受けるすべてのリリースは、サポートされるパッチリリースのリストから削除されます。さらに、4.7.6 を実行するクラスターは、自動アップグレードのスケジュールが 48 時間以内に行われます。
3.4.6. 限定サポートステータス
クラスターが 限定サポート ステータスに移行すると、Red Hat はクラスターをプロアクティブに監視しなくなり、SLA は適用されなくなり、SLA に対して要求されたクレジットは拒否されます。製品サポートがなくなったという意味ではありません。場合によっては、違反要因を修正すると、クラスターが完全にサポートされた状態に戻ることがあります。ただし、それ以外の場合は、クラスターを削除して再作成する必要があります。
クラスターは、次のシナリオなど、さまざまな理由で限定サポートステータスに移行する場合があります。
- サポート終了日までにクラスターをサポートされるバージョンにアップグレードしない場合
Red Hat は、サポート終了日以降のバージョンについて、ランタイムまたは SLA を保証しません。継続的なサポートを受けるには、サポートが終了する前に、クラスターを、サポートされているバージョンにアップグレードしてください。有効期限が切れる前にクラスターをアップグレードしない場合、クラスターは、サポートされているバージョンにアップグレードされるまで、限定サポートステータスに移行します。
Red Hat は、サポートされていないバージョンからサポートされているバージョンにアップグレードするための商業的に合理的なサポートを提供します。ただし、サポートされるアップグレードパスが利用できなくなった場合は、新規クラスターを作成し、ワークロードを移行することが必要になることがあります。
- ネイティブの Red Hat OpenShift Service on AWS コンポーネント、または Red Hat がインストールおよび管理するその他のコンポーネントを削除または置き換える場合
- クラスター管理者パーミッションを使用した場合、Red Hat は、インフラストラクチャーサービス、サービスの可用性、またはデータ損失に影響を与えるアクションを含む、ユーザーまたは認可されたユーザーのアクションに対して責任を負いません。Red Hat がそのようなアクションを検出した場合、クラスターは限定サポートステータスに移行する可能性があります。Red Hat はステータスの変更を通知します。アクションを元に戻すか、サポートケースを作成して、クラスターの削除と再作成が必要になる可能性のある修復手順を検討する必要があります。
クラスターが限定サポートステータスに移行する可能性のある特定のアクションについて質問がある場合、またはさらに支援が必要な場合は、サポートチケットを作成します。
3.4.7. サポート対象バージョンの例外ポリシー
Red Hat は、事前通知なしに新規または既存のバージョンを追加または削除したり、実稼働環境に影響を与える重要なバグまたはセキュリティーの問題があることが確認された今後のマイナーリリースバージョンを遅延させる権利を留保します。
3.4.8. インストールポリシー
Red Hat では、最新のサポートリリースのインストールを推奨していますが、Red Hat OpenShift Service on AWS は前述のポリシーに記載されているサポート対象のリリースのインストールをサポートします。
3.4.9. 必須アップグレード
Critical (重大) または Important (重要) の CVE、または Red Hat が特定するその他のバグが、クラスターのセキュリティーまたは安定性に大幅に影響を与える場合、お客様は 2 営業日 以内にサポート対象の次のパッチリリースにアップグレードする必要があります。
極端な状況下では、環境に対する CVE の重要性に関する Red Hat の評価に基づいて、Red Hat はお客様に対して、2 営業日 以内にクラスターを最新の安全なパッチリリースに更新するようスケジュールするか手動で更新するように通知します。2 営業日 が経過しても、更新が実行されない場合、Red Hat は潜在的なセキュリティー違反や不安定性を軽減するために、クラスターを最新の安全なパッチリリースに自動的に更新します。Red Hat は、サポートケース を通じてお客様からリクエストがあった場合、当社の判断で自動更新を一時的に延期することがあります。
3.4.10. ライフサイクルの日付
バージョン | 一般公開 | ライフサイクルの終了日 |
---|---|---|
4.15 | 2024 年 2 月 27 日 | 2025 年 6 月 30 日 |
4.14 | 2023 年 10 月 31 日: | 2025 年 2 月 28 日 |
4.13 | 2023 年 5 月 17 日 | 2024 年 9 月 17 日 |
4.12 | 2023 年 1 月 17 日 | 2024 年 5 月 17 日 |
4.11 | 2022 年 8 月 10 日 | 2023 年 12 月 10 日 |
4.10 | 2022 年 3 月 10 日 | 2023 年 9 月 10 日 |
4.9 | 2021 年 10 月 18 日 | 2022 年 12 月 18 日 |
4.8 | 2021 年 7 月 27 日 | 2022 年 9 月 27 日 |
3.5. Hosted Control Plane (HCP) を備えた Red Hat OpenShift Service on AWS (ROSA) のサービス定義
このドキュメントでは、Hosted Control Plane (HCP) を備えた Red Hat OpenShift Service on AWS (ROSA) のマネージドサービスのサービス定義を説明します。
3.5.1. アカウント管理
このセクションでは、Red Hat OpenShift Service on AWS アカウント管理のサービス定義を説明します。
3.5.1.1. 請求
Red Hat OpenShift Service on AWS の請求は、サービス (ロードバランサー、ストレージ、EC2 インスタンス、他のコンポーネントなど)、および OpenShift サービスの Red Hat サブスクリプションで使用される AWS コンポーネントの使用状況に基づいて Amazon Web Services (AWS) で行われます。
追加の Red Hat ソフトウェアは別途購入する必要があります。
3.5.1.2. クラスターのセルフサービス
お客様はクラスターをセルフサービスで利用できます。これには以下が含まれますが、これらに限定されません。
- クラスターの作成
- クラスターの削除
- アイデンティティープロバイダーの追加または削除
- 権限が昇格したグループからのユーザーの追加または削除
- クラスターのプライバシーの設定
- マシンプールの追加または削除、および自動スケーリングの設定
- アップグレードポリシーの定義
これらのセルフサービスタスクは、Red Hat OpenShift Service on AWS (ROSA) CLI (rosa
) を使用して実行できます。
3.5.1.3. インスタンスタイプ
HCP を備えたすべての ROSA クラスターには、少なくとも 2 つのワーカーノードが必要です。HCP を備えたすべての ROSA クラスターには、最大 51 個のワーカーノードをサポートします。クラウドプロバイダーコンソールを使用して基礎となるインフラストラクチャーをシャットダウンすることはサポートされておらず、データが失われる可能性があります。
約 1 vCPU コアおよび 1 GiB のメモリーが各ワーカーノードで予約され、割り当て可能なリソースから削除されます。このリソースの予約は、基礎となるプラットフォームに必要なプロセスを実行するのに必要です。これらのプロセスには、udev、kubelet、コンテナーランタイムなどのシステムデーモンが含まれます。予約されるリソースは、カーネル予約も占めます。
監査ログの集計、メトリックコレクション、DNS、イメージレジストリー、SDN などの OpenShift Container Platform コアシステムは、追加の割り当て可能なリソースを使用し、クラスターの安定性および保守性を確保できる可能性があります。消費される追加リソースは、使用方法によって異なる場合があります。
詳細は、Kubernetes のドキュメント を参照してください。
Red Hat OpenShift Service on AWS 4.11 の時点で、Pod ごとのデフォルトの PID 制限は 4096
です。この PID 制限を有効する場合は、Red Hat OpenShift Service on AWS クラスターをこのバージョン以降にアップグレードする必要があります。以前のバージョンで実行されている Red Hat OpenShift Service on AWS クラスターでは、デフォルトの PID 制限である 1024
が使用されます。
ROSA CLI を使用すると、Red Hat OpenShift Service on AWS クラスターの Pod ごとの PID 制限を設定できます。詳細は、「PID 制限の設定」を参照してください。
3.5.1.4. AWS インスタンスタイプ
Red Hat OpenShift Service on AWS は、次のワーカーノードインスタンスのタイプとサイズを提供します。
例3.10 一般的用途
- m5.metal (96† vCPU、384 GiB)
- m5.xlarge (4 vCPU、16 GiB)
- m5.2xlarge (8 vCPU、32 GiB)
- m5.4xlarge (16 vCPU、64 GiB)
- m5.8xlarge (32 vCPU、128 GiB)
- m5.12xlarge (48 vCPU、192 GiB)
- m5.16xlarge (64 vCPU、256 GiB)
- m5.24xlarge (96 vCPU、384 GiB)
- m5a.xlarge (4 vCPU、16 GiB)
- m5a.2xlarge (8 vCPU、32 GiB)
- m5a.4xlarge (16 vCPU、64 GiB)
- m5a.8xlarge (32 vCPU、128 GiB)
- m5a.12xlarge (48 vCPU、192 GiB)
- m5a.16xlarge (64 vCPU、256 GiB)
- m5a.24xlarge (96 vCPU、384 GiB)
- m5ad.xlarge (4 vCPU、16 GiB)
- m5ad.2xlarge (8 vCPU、32 GiB)
- m5ad.4xlarge (16 vCPU、64 GiB)
- m5ad.8xlarge (32 vCPU、128 GiB)
- m5ad.12xlarge (48 vCPU、192 GiB)
- m5ad.16xlarge (64 vCPU、256 GiB)
- m5ad.24xlarge (96 vCPU、384 GiB)
- m5d.metal (96† vCPU、384 GiB)
- m5d.xlarge (4 vCPU、16 GiB)
- m5d.2xlarge (8 vCPU、32 GiB)
- m5d.4xlarge (16 vCPU、64 GiB)
- m5d.8xlarge (32 vCPU、128 GiB)
- m5d.12xlarge (48 vCPU、192 GiB)
- m5d.16xlarge (64 vCPU、256 GiB)
- m5d.24xlarge (96 vCPU、384 GiB)
- m5n.metal (96 vCPU、384 GiB)
- m5n.xlarge (4 vCPU、16 GiB)
- m5n.2xlarge (8 vCPU、32 GiB)
- m5n.4xlarge (16 vCPU、64 GiB)
- m5n.8xlarge (32 vCPU、128 GiB)
- m5n.12xlarge (48 vCPU、192 GiB)
- m5n.16xlarge (64 vCPU、256 GiB)
- m5n.24xlarge (96 vCPU、384 GiB)
- m5dn.metal (96 vCPU、384 GiB)
- m5dn.xlarge (4 vCPU、16 GiB)
- m5dn.2xlarge (8 vCPU、32 GiB)
- m5dn.4xlarge (16 vCPU、64 GiB)
- m5dn.8xlarge (32 vCPU、128 GiB)
- m5dn.12xlarge (48 vCPU、192 GiB)
- m5dn.16xlarge (64 vCPU、256 GiB)
- m5dn.24xlarge (96 vCPU、384 GiB)
- m5zn.metal (48 vCPU、192 GiB)
- m5zn.xlarge (4 vCPU、16 GiB)
- m5zn.2xlarge (8 vCPU、32 GiB)
- m5zn.3xlarge (12 vCPU、48 GiB)
- m5zn.6xlarge (24 vCPU、96 GiB)
- m5zn.12xlarge (48 vCPU、192 GiB)
- m6a.xlarge (4 vCPU、16 GiB)
- m6a.2xlarge (8 vCPU、32 GiB)
- m6a.4xlarge (16 vCPU、64 GiB)
- m6a.8xlarge (32 vCPU、128 GiB)
- m6a.12xlarge (48 vCPU、192 GiB)
- m6a.16xlarge (64 vCPU、256 GiB)
- m6a.24xlarge (96 vCPU、384 GiB)
- m6a.32xlarge (128 vCPU、512 GiB)
- m6a.48xlarge (192 vCPU、768 GiB)
- m6i.metal (128 vCPU、512 GiB)
- m6i.xlarge (4 vCPU、16 GiB)
- m6i.2xlarge (8 vCPU、32 GiB)
- m6i.4xlarge (16 vCPU、64 GiB)
- m6i.8xlarge (32 vCPU、128 GiB)
- m6i.12xlarge (48 vCPU、192 GiB)
- m6i.16xlarge (64 vCPU、256 GiB)
- m6i.24xlarge (96 vCPU、384 GiB)
- m6i.32xlarge (128 vCPU、512 GiB)
- m6id.xlarge (4 vCPU、16 GiB)
- m6id.2xlarge (8 vCPU、32 GiB)
- m6id.4xlarge (16 vCPU、64 GiB)
- m6id.8xlarge (32 vCPU、128 GiB)
- m6id.12xlarge (48 vCPU、192 GiB)
- m6id.16xlarge (64 vCPU、256 GiB)
- m6id.24xlarge (96 vCPU、384 GiB)
- m6id.32xlarge (128 vCPU、512 GiB)
- m7i.xlarge (4 vCPU、16 GiB)
- m7i.2xlarge (8 vCPU、32 GiB)
- m7i.4xlarge (16 vCPU、64 GiB)
- m7i.8xlarge (32 vCPU、128 GiB)
- m7i.12xlarge (48 vCPU、192 GiB)
- m7i.16xlarge (64 vCPU、256 GiB)
- m7i.24xlarge (96 vCPU、384 GiB)
- m7i.48xlarge (192 vCPU、768 GiB)
- m7i.metal-24xl (96 vCPU、384 GiB)
- m7i.metal-48xl (192 vCPU、768 GiB)
- m7i-flex.xlarge (4 vCPU、16 GiB)
- m7i-flex.2xlarge (8 vCPU、32 GiB)
- m7i-flex.4xlarge (16 vCPU、64 GiB)
- m7i-flex.8xlarge (32 vCPU、128 GiB)
- m7a.xlarge (4 vCPU、16 GiB)
- m7a.2xlarge (8 vCPU、32 GiB)
- m7a.4xlarge (16 vCPU、64 GiB)
- m7a.8xlarge (32 vCPU、128 GiB)
- m7a.12xlarge (48 vCPU、192 GiB)
- m7a.16xlarge (64 vCPU、256 GiB)
- m7a.24xlarge (96 vCPU、384 GiB)
- m7a.32xlarge (128 vCPU、512 GiB)
- m7a.48xlarge (192 vCPU、768 GiB)
- m7a.metal-48xl (192 vCPU、768 GiB)
† これらのインスタンスタイプは、48 個の物理コアで 96 個の論理プロセッサーを提供します。これらは、2 つの物理 Intel ソケットを備えた単一サーバー上で実行します。
例3.11 バースト可能な汎用目的
- t3.xlarge (4 vCPU、16 GiB)
- t3.2xlarge (8 vCPU、32 GiB)
- t3a.xlarge (4 vCPU、16 GiB)
- t3a.2xlarge (8 vCPU、32 GiB)
例3.12 メモリー集約型
- x1.16xlarge (64 vCPU、976 GiB)
- x1.32xlarge (128 vCPU、1952 GiB)
- x1e.xlarge (4 vCPU、122 GiB)
- x1e.2xlarge (8 vCPU、244 GiB)
- x1e.4xlarge (16 vCPU、488 GiB)
- x1e.8xlarge (32 vCPU、976 GiB)
- x1e.16xlarge (64 vCPU、1,952 GiB)
- x1e.32xlarge (128 vCPU、3,904 GiB)
- x2idn.16xlarge (64 vCPU、1024 GiB)
- x2idn.24xlarge (96 vCPU、1536 GiB)
- x2idn.32xlarge (128 vCPU、2048 GiB)
- x2iedn.xlarge (4 vCPU、128 GiB)
- x2iedn.2xlarge (8 vCPU、256 GiB)
- x2iedn.4xlarge (16 vCPU、512 GiB)
- x2iedn.8xlarge (32 vCPU、1024 GiB)
- x2iedn.16xlarge (64 vCPU、2048 GiB)
- x2iedn.24xlarge (96 vCPU、3072 GiB)
- x2iedn.32xlarge (128 vCPU、4096 GiB)
- x2iezn.2xlarge (8 vCPU、256 GiB)
- x2iezn.4xlarge (16vCPU、512 GiB)
- x2iezn.6xlarge (24vCPU、768 GiB)
- x2iezn.8xlarge (32vCPU、1,024 GiB)
- x2iezn.12xlarge (48vCPU、1,536 GiB)
- x2idn.metal (128vCPU、2,048 GiB)
- x2iedn.metal (128vCPU、4,096 GiB)
- x2iezn.metal (48 vCPU、1,536 GiB)
例3.13 最適化されたメモリー
- r4.xlarge (4 vCPU、30.5 GiB)
- r4.2xlarge (8 vCPU、61 GiB)
- r4.4xlarge (16 vCPU、122 GiB)
- r4.8xlarge (32 vCPU、244 GiB)
- r4.16xlarge (64 vCPU、488 GiB)
- r5.metal (96† vCPU、768 GiB)
- r5.xlarge (4 vCPU、32 GiB)
- r5.2xlarge (8 vCPU、64 GiB)
- r5.4xlarge (16 vCPU、128 GiB)
- r5.8xlarge (32 vCPU、256 GiB)
- r5.12xlarge (48 vCPU、384 GiB)
- r5.16xlarge (64 vCPU、512 GiB)
- r5.24xlarge (96 vCPU、768 GiB)
- r5a.xlarge (4 vCPU、32 GiB)
- r5a.2xlarge (8 vCPU、64 GiB)
- r5a.4xlarge (16 vCPU、128 GiB)
- r5a.8xlarge (32 vCPU、256 GiB)
- r5a.12xlarge (48 vCPU、384 GiB)
- r5a.16xlarge (64 vCPU、512 GiB)
- r5a.24xlarge (96 vCPU、768 GiB)
- r5ad.xlarge (4 vCPU、32 GiB)
- r5ad.2xlarge (8 vCPU、64 GiB)
- r5ad.4xlarge (16 vCPU、128 GiB)
- r5ad.8xlarge (32 vCPU、256 GiB)
- r5ad.12xlarge(48 vCPU、384 GiB)
- r5ad.16xlarge (64 vCPU、512 GiB)
- r5ad.24xlarge (96 vCPU、768 GiB)
- r5d.metal (96† vCPU、768 GiB)
- r5d.xlarge (4 vCPU、32 GiB)
- r5d.2xlarge (8 vCPU、64 GiB)
- r5d.4xlarge (16 vCPU、128 GiB)
- r5d.8xlarge (32 vCPU、256 GiB)
- r5d.12xlarge (48 vCPU、384 GiB)
- r5d.16xlarge (64 vCPU、512 GiB)
- r5d.24xlarge (96 vCPU、768 GiB)
- r5n.metal (96 vCPU、768 GiB)
- r5n.xlarge (4 vCPU、32 GiB)
- r5n.2xlarge (8 vCPU、64 GiB)
- r5n.4xlarge (16 vCPU、128 GiB)
- r5n.8xlarge (32 vCPU、256 GiB)
- r5n.12xlarge (48 vCPU、384 GiB)
- r5n.16xlarge (64 vCPU、512 GiB)
- r5n.24xlarge (96 vCPU、768 GiB)
- r5dn.metal (96 vCPU、768 GiB)
- r5dn.xlarge (4 vCPU、32 GiB)
- r5dn.2xlarge (8 vCPU、64 GiB)
- r5dn.4xlarge (16 vCPU、128 GiB)
- r5dn.8xlarge (32 vCPU、256 GiB)
- r5dn.12xlarge(48 vCPU、384 GiB)
- r5dn.16xlarge (64 vCPU、512 GiB)
- r5dn.24xlarge (96 vCPU、768 GiB)
- r6a.xlarge (4 vCPU、32 GiB)
- r6a.2xlarge (8 vCPU、64 GiB)
- r6a.4xlarge (16 vCPU、128 GiB)
- r6a.8xlarge (32 vCPU、256 GiB)
- r6a.12xlarge (48 vCPU、384 GiB)
- r6a.16xlarge (64 vCPU、512 GiB)
- r6a.24xlarge (96 vCPU、768 GiB)
- r6a.32xlarge (128 vCPU、1,024 GiB)
- r6a.48xlarge (192 vCPU、1,536 GiB)
- r6i.metal (128 vCPU、1,024 GiB)
- r6i.xlarge (4 vCPU、32 GiB)
- r6i.2xlarge (8 vCPU、64 GiB)
- r6i.4xlarge (16 vCPU、128 GiB)
- r6i.8xlarge (32 vCPU、256 GiB)
- r6i.12xlarge (48 vCPU、384 GiB)
- r6i.16xlarge (64 vCPU、512 GiB)
- r6i.24xlarge (96 vCPU、768 GiB)
- r6i.32xlarge (128 vCPU、1,024 GiB)
- r6id.xlarge (4 vCPU、32 GiB)
- r6id.2xlarge (8 vCPU、64 GiB)
- r6id.4xlarge (16 vCPU、128 GiB)
- r6id.8xlarge (32 vCPU、256 GiB)
- r6id.12xlarge (48 vCPU、384 GiB)
- r6id.16xlarge (64 vCPU、512 GiB)
- r6id.24xlarge (96 vCPU、768 GiB)
- r6id.32xlarge (128 vCPU、1,024 GiB)
- z1d.metal (48 vCPU、384 GiB)
- z1d.xlarge (4 vCPU、32 GiB)
- z1d.2xlarge (8 vCPU、64 GiB)
- z1d.3xlarge (12 vCPU、96 GiB)
- z1d.6xlarge (24 vCPU、192 GiB)
- z1d.12xlarge (48 vCPU、384 GiB)
- r7iz.xlarge (4 vCPU、32 GiB)
- r7iz.2xlarge (8 vCPU、64 GiB)
- r7iz.4xlarge (16 vCPU、128 GiB)
- r7iz.8xlarge (32 vCPU、256 GiB)
- r7iz.12xlarge (48 vCPU、384 GiB)
- r7iz.16xlarge (64 vCPU、512 GiB)
- r7iz.32xlarge (128 vCPU、1024 GiB)
- r7iz.metal-16xl (64 vCPU、512 GiB)
- r7iz.metal-32xl (128 vCPU、1024 GiB)
† これらのインスタンスタイプは、48 個の物理コアで 96 個の論理プロセッサーを提供します。これらは、2 つの物理 Intel ソケットを備えた単一サーバー上で実行します。
これらのインスタンスタイプは、24 個の物理コアで 48 個の論理プロセッサーを提供します。
例3.14 高速コンピューティング
- p3.2xlarge (8 vCPU、61 GiB)
- p3.8xlarge (32 vCPU、244 GiB)
- p3.16xlarge (64 vCPU、488 GiB)
- p3dn.24xlarge (96 vCPU、768 GiB)
- p4d.24xlarge (96 vCPU、1,152 GiB)
- p4de.24xlarge (96 vCPU、1,152 GiB)
- p5.48xlarge (192 vCPU、2,048 GiB)
- g4dn.xlarge (4 vCPU、16 GiB)
- g4dn.2xlarge (8 vCPU、32 GiB)
- g4dn.4xlarge (16 vCPU、64 GiB)
- g4dn.8xlarge (32 vCPU、128 GiB)
- g4dn.12xlarge (48 vCPU、192 GiB)
- g4dn.16xlarge (64 vCPU、256 GiB)
- g4dn.metal (96 vCPU、384 GiB)
- g5.xlarge (4 vCPU、16 GiB)
- g5.2xlarge (8 vCPU、32 GiB)
- g5.4xlarge (16 vCPU、64 GiB)
- g5.8xlarge (32 vCPU、128 GiB)
- g5.16xlarge (64 vCPU、256 GiB)
- g5.12xlarge (48 vCPU、192 GiB)
- g5.24xlarge (96 vCPU、384 GiB)
- g5.48xlarge (192 vCPU、768 GiB)
- dl1.24xlarge (96 vCPU、768 GiB)†
† Intel 固有で Nvidia で対応していません。
GPU インスタンスタイプソフトウェアスタックのサポートは AWS によって提供されます。AWS サービスクォータが必要な GPU インスタンスタイプに対応できることを確認します。
例3.15 最適化されたコンピュート
- c5.metal (96 vCPU、192 GiB)
- c5.xlarge (4 vCPU、8 GiB)
- c5.2xlarge (8 vCPU、16 GiB)
- c5.4xlarge (16 vCPU、32 GiB)
- c5.9xlarge (36 vCPU、72 GiB)
- c5.12xlarge (48 vCPU、96 GiB)
- c5.18xlarge (72 vCPU、144 GiB)
- c5.24xlarge (96 vCPU、192 GiB)
- c5d.metal (96 vCPU、192 GiB)
- c5d.xlarge (4 vCPU、8 GiB)
- c5d.2xlarge (8 vCPU、16 GiB)
- c5d.4xlarge (16 vCPU、32 GiB)
- c5d.9xlarge (36 vCPU、72 GiB)
- c5d.12xlarge (48 vCPU、96 GiB)
- c5d.18xlarge(72 vCPU、144 GiB)
- c5d.24xlarge (96 vCPU、192 GiB)
- c5a.xlarge (4 vCPU、8 GiB)
- c5a.2xlarge (8 vCPU、16 GiB)
- c5a.4xlarge (16 vCPU、32 GiB)
- c5a.8xlarge (32 vCPU、64 GiB)
- c5a.12xlarge (48 vCPU、96 GiB)
- c5a.16xlarge (64 vCPU、128 GiB)
- c5a.24xlarge (96 vCPU、192 GiB)
- c5ad.xlarge (4 vCPU、8 GiB)
- c5ad.2xlarge (8 vCPU、16 GiB)
- c5ad.4xlarge (16 vCPU、32 GiB)
- c5ad.8xlarge (32 vCPU、64 GiB)
- c5ad.12xlarge (48 vCPU、96 GiB)
- c5ad.16xlarge (64 vCPU、128 GiB)
- c5ad.24xlarge (96 vCPU、192 GiB)
- c5n.metal (72 vCPU、192 GiB)
- c5n.xlarge (4 vCPU、10.5 GiB)
- c5n.2xlarge (8 vCPU、21 GiB)
- c5n.4xlarge (16 vCPU、42 GiB)
- c5n.9xlarge (36 vCPU、96 GiB)
- c5n.18xlarge (72 vCPU、192 GiB)
- c6a.xlarge (4 vCPU、8 GiB)
- c6a.2xlarge (8 vCPU、16 GiB)
- c6a.4xlarge (16 vCPU、32 GiB)
- c6a.8xlarge (32 vCPU、64 GiB)
- c6a.12xlarge (48 vCPU、96 GiB)
- c6a.16xlarge (64 vCPU、128 GiB)
- c6a.24xlarge (96 vCPU、192 GiB)
- c6a.32xlarge (128 vCPU、256 GiB)
- c6a.48xlarge (192 vCPU、384 GiB)
- c6i.metal (128 vCPU、256 GiB)
- c6i.xlarge (4 vCPU、8 GiB)
- c6i.2xlarge (8 vCPU、16 GiB)
- c6i.4xlarge (16 vCPU、32 GiB)
- c6i.8xlarge (32 vCPU、64 GiB)
- c6i.12xlarge (48 vCPU、96 GiB)
- c6i.16xlarge (64 vCPU、128 GiB)
- c6i.24xlarge (96 vCPU、192 GiB)
- c6i.32xlarge (128 vCPU、256 GiB)
- c6id.xlarge (4 vCPU、8 GiB)
- c6id.2xlarge (8 vCPU、16 GiB)
- c6id.4xlarge (16 vCPU、32 GiB)
- c6id.8xlarge (32 vCPU、64 GiB)
- c6id.12xlarge (48 vCPU、96 GiB)
- c6id.16xlarge (64 vCPU、128 GiB)
- c6id.24xlarge (96 vCPU、192 GiB)
- c6id.32xlarge (128 vCPU、256 GiB)
例3.16 最適化されたストレージ
- i3.metal (72† vCPU、512 GiB)
- i3.xlarge (4 vCPU、30.5 GiB)
- i3.2xlarge (8 vCPU、61 GiB)
- i3.4xlarge (16 vCPU、122 GiB)
- i3.8xlarge (32 vCPU、244 GiB)
- i3.16xlarge (64 vCPU、488 GiB)
- i3en.metal (96 vCPU、768 GiB)
- i3en.xlarge (4 vCPU、32 GiB)
- i3en.2xlarge (8 vCPU、64 GiB)
- i3en.3xlarge (12 vCPU、96 GiB)
- i3en.6xlarge (24 vCPU、192 GiB)
- i3en.12xlarge (48 vCPU、384 GiB)
- i3en.24xlarge (96 vCPU、768 GiB)
- i4i.xlarge (4 vCPU、32 GiB)
- i4i.2xlarge (8 vCPU、64 GiB)
- i4i.4xlarge (16 vCPU、128 GiB)
- i4i.8xlarge (32 vCPU、256 GiB)
- i4i.12xlarge (48 vCPU、384 GiB)
- i4i.16xlarge (64 vCPU、512 GiB)
- i4i.24xlarge (96 vCPU、768 GiB)
- i4i.32xlarge (128 vCPU、1024 GiB)
- i4i.metal (128 vCPU、1024 GiB)
† このインスタンスタイプは、36 個の物理コアで 72 個の論理プロセッサーを提供します。
仮想インスタンスタイプは、.metal インスタンスタイプよりも速く初期化されます。
例3.17 高メモリー
- u-3tb1.56xlarge (224 vCPU、3,072 GiB)
- u-6tb1.56xlarge (224 vCPU、6,144 GiB)
- u-6tb1.112xlarge (448 vCPU、6,144 GiB)
- u-6tb1.metal (448 vCPU、6,144 GiB)
- u-9tb1.112xlarge (448 vCPU、9,216 GiB)
- u-9tb1.metal (448 vCPU、9,216 GiB)
- u-12tb1.112xlarge (448 vCPU、12,288 GiB)
- u-12tb1.metal (448 vCPU、12,288 GiB)
- u-18tb1.metal (448 vCPU、18,432 GiB)
- u-24tb1.metal (448 vCPU、24,576 GiB)
関連情報
3.5.1.5. リージョンおよびアベイラビリティーゾーン
現在、HCP を備えた ROSA では、次の AWS リージョンが利用可能です。
OpenShift 4 のサポートの有無にかかわらず、中国リージョンはサポートされません。
GovCloud (US) リージョンの場合は、Access request for Red Hat OpenShift Service on AWS (ROSA) FedRAMP を送信する必要があります。
GovCloud (US) リージョンは、ROSA Classic クラスターでのみサポートされます。
例3.18 AWS リージョン
- us-east-1 (N. Virginia)
- us-east-2 (Ohio)
- us-west-2 (Oregon)
- af-south-1 (Cape Town、AWS オプトインが必要)
- ap-south-2 (Hyderabad、AWS オプトインが必要)
- ap-southeast-3 (Jakarta、AWS オプトインが必要)
- ap-southeast-4 (Melbourne、AWS オプトインが必要)
- ap-south-1 (Mumbai)
- ap-northeast-2 (Seoul)
- ap-southeast-1 (Singapore)
- ap-southeast-2 (Sydney)
- ap-northeast-1 (Tokyo)
- ca-central-1 (Central Canada)
- eu-central-1 (Frankfurt)
- eu-west-1 (Ireland)
- eu-west-2 (London)
- eu-south-1 (Milan、AWS オプトインが必要)
- me-south-1 (Bahrain、AWS オプトインが必要)
複数のアベイラビリティーゾーンのクラスターは、少なくとも 3 つのアベイラビリティーゾーンのあるリージョンにのみデプロイできます。詳細は、AWS ドキュメントの Regions and Availability Zones セクションを参照してください。
HCP を備えた新しい ROSA クラスターはそれぞれ、単一リージョンの既存の Virtual Private Cloud (VPC) 内にインストールされます。必要に応じて、そのリージョンのアベイラビリティゾーンの合計数までデプロイできます。これにより、クラスターレベルのネットワークおよびリソースの分離が行われ、VPN 接続や VPC ピアリングなどのクラウドプロバイダーの VPC 設定が有効になります。永続ボリューム (PV) は Amazon Elastic Block Storage (Amazon EBS) によってサポートされ、それらがプロビジョニングされるアベイラビリティーゾーンに固有のものとして機能します。永続ボリューム要求 (PVC) は、Pod がスケジュールできなくなる状況を防ぐために、関連付けられた Pod リソースが特定のアベイラビリティーゾーンに割り当てられるまでボリュームにバインドされません。アベイラビリティーゾーン固有のリソースは、同じアベイラビリティーゾーン内のリソースでのみ利用できます。
クラスターのデプロイ後にリージョンを変更することはできません。
3.5.1.6. Local Zones
Hosted Control Plane (HCP) を備えた Red Hat OpenShift Service on AWS (ROSA) では、AWS Local Zones を使用できません。
3.5.1.7. Service Level Agreement (SLA)
サービス自体の SLA は、Red Hat Enterprise Agreement Appendix 4 (Online Subscription Services) で定義されています。
3.5.1.8. 限定サポートステータス
クラスターが 限定サポート ステータスに移行すると、Red Hat はクラスターをプロアクティブに監視しなくなり、SLA は適用されなくなり、SLA に対して要求されたクレジットは拒否されます。製品サポートがなくなったという意味ではありません。場合によっては、違反要因を修正すると、クラスターが完全にサポートされた状態に戻ることがあります。ただし、それ以外の場合は、クラスターを削除して再作成する必要があります。
クラスターは、次のシナリオなど、さまざまな理由で限定サポートステータスに移行する場合があります。
- ネイティブの Red Hat OpenShift Service on AWS コンポーネント、または Red Hat がインストールおよび管理するその他のコンポーネントを削除または置き換える場合
- クラスター管理者パーミッションを使用した場合、Red Hat は、インフラストラクチャーサービス、サービスの可用性、またはデータ損失に影響を与えるアクションを含む、ユーザーまたは認可されたユーザーのアクションに対して責任を負いません。Red Hat がそのようなアクションを検出した場合、クラスターは限定サポートステータスに移行する可能性があります。Red Hat はステータスの変更を通知します。アクションを元に戻すか、サポートケースを作成して、クラスターの削除と再作成が必要になる可能性のある修復手順を検討する必要があります。
クラスターが限定サポートステータスに移行する原因となる特定のアクションについて質問がある場合、またはさらなるサポートが必要な場合は、サポートチケットを作成してください。:!rosa-with-hcp:
3.5.1.9. サポート
Red Hat OpenShift Service on AWS には Red Hat Premium サポートが含まれており、このサポートは Red Hat カスタマーポータル を使用して利用できます。
サポートの応答時間については、Red Hat OpenShift Service on AWS の SLA を参照してください。
AWS サポートは、AWS との既存のサポート契約に基づきます。
3.5.2. ロギング
Red Hat OpenShift Service on AWS は、Amazon (AWS) CloudWatch へのオプションの統合ログ転送を提供します。
3.5.2.1. クラスター監査ロギング
クラスター監査ログは、インテグレーションが有効になっている場合に AWS CloudWatch 経由で利用できます。インテグレーションが有効でない場合は、サポートケースを作成して監査ログをリクエストできます。
3.5.2.2. アプリケーションロギング
STDOUT
に送信されるアプリケーションログは Fluentd によって収集され、クラスターロギングスタックで AWS CloudWatch に転送されます (インストールされている場合)。
3.5.3. モニタリング
このセクションでは、Red Hat OpenShift Service on AWS モニタリングのサービス定義を説明します。
3.5.3.1. クラスターメトリック
Red Hat OpenShift Service on AWS クラスターには、CPU、メモリー、ネットワークベースのメトリクスを含むクラスターモニタリングの統合された Prometheus スタックが同梱されます。これは Web コンソールからアクセスできます。また、これらのメトリックは Red Hat OpenShift Service on AWS ユーザーによって提供される CPU またはメモリーメトリックをベースとする Horizontal Pod Autoscaling を許可します。
3.5.3.2. クラスターステータスの通知
Red Hat は、OpenShift Cluster Manager で利用可能なクラスターダッシュボードと、クラスターの初回デプロイで使用した連絡先、およびお客様が指定する追加の連絡先のメールアドレスに送信されるメール通知を使用して、Red Hat OpenShift Service on AWS クラスターの正常性およびステータスについて通信します。
3.5.4. ネットワーク
このセクションでは、Red Hat OpenShift Service on AWS ネットワークのサービス定義を説明します。
3.5.4.1. アプリケーションのカスタムドメイン
ルートにカスタムホスト名を使用するには、正規名 (CNAME) レコードを作成して DNS プロバイダーを更新する必要があります。CNAME レコードでは、OpenShift の正規ルーターのホスト名をカスタムドメインにマップする必要があります。OpenShift の正規ルーターのホスト名は、ルートの作成後に Route Details ページに表示されます。または、ワイルドカード CNAME レコードを 1 度作成して、指定のホスト名のすべてのサブドメインをクラスターのルーターにルーティングできます。
Red Hat OpenShift Service on AWS 4.14 以降、Custom Domain Operator は非推奨になりました。Red Hat OpenShift Service on AWS 4.14 以降で Ingress を管理するには、Ingress Operator を使用します。Red Hat OpenShift Service on AWS 4.13 以前のバージョンでは機能に変更はありません。
3.5.4.2. ドメイン検証証明書
Red Hat OpenShift Service on AWS には、クラスターの内部サービスと外部サービスの両方に必要な TLS セキュリティー証明書が含まれます。外部ルートの場合は、各クラスターに提供され、インストールされる 2 つの別個の TLS ワイルドカード証明書があります。1 つは Web コンソールおよびルートのデフォルトホスト名用であり、もう 1 つは API エンドポイント用です。Let's Encrypt は証明書に使用される認証局です。内部の API エンドポイント などのクラスター内のルートでは、クラスターの組み込み認証局によって署名された TLS 証明書を使用し、TLS 証明書を信頼するためにすべての Pod で CA バンドルが利用可能である必要があります。
3.5.4.3. ビルドのカスタム認証局
Red Hat OpenShift Service on AWS は、イメージレジストリーからイメージをプルする際にビルドによって信頼されるカスタム認証局の使用をサポートします。
3.5.4.4. ロードバランサー
Hosted Control Plane (HCP) を備えた Red Hat OpenShift Service on AWS (ROSA) は、デフォルトの Ingress コントローラーからのみロードバランサーをデプロイします。お客様は、他のすべてのロードバランサーを、セカンダリー Ingress コントローラーやサービスロードバランサー用に、必要に応じてデプロイできます。
3.5.4.5. クラスター ingress
プロジェクト管理者は、IP 許可リストによる ingress の制御など、さまざまな目的でルートアノテーションを追加できます。
Ingress ポリシーは、ovs-networkpolicy
プラグインを使用する NetworkPolicy
オブジェクトを使用して変更することもできます。これにより、同じクラスターの Pod 間や同じ namespace にある Pod 間など、Ingress ネットワークポリシーを Pod レベルで完全に制御できます。
すべてのクラスター ingress トラフィックは定義されたロードバランサーを通過します。すべてのノードへの直接のアクセスは、クラウド設定によりブロックされます。
3.5.4.6. クラスター egress
EgressNetworkPolicy
オブジェクトでの Pod egress トラフィックの制御は、Hosted Control Plane (HCP) を備えた Red Hat OpenShift Service on AWS での送信トラフィックを防ぐか、これを制限するために使用できます。
3.5.4.7. クラウドネットワーク設定
Red Hat OpenShift Service on AWS では、次のような AWS 管理のテクノロジーを使用してプライベートネットワーク接続を設定できます。
- VPN 接続
- VPC ピアリング
- Transit Gateway
- Direct Connect
Red Hat のサイト信頼性エンジニアリング (SRE) チームは、プライベートネットワーク接続を監視しません。これらの接続の監視は、お客様の責任で行われます。
3.5.4.8. DNS 転送
プライベートクラウドネットワーク設定を持つ Red Hat OpenShift Service on AWS クラスターの場合、お客様はそのプライベート接続で利用可能な内部 DNS サーバーを指定でき、明示的に提供されるドメインについてこれをクエリーする必要があります。
3.5.4.9. ネットワークの検証
Red Hat OpenShift Service on AWS クラスターを既存の Virtual Private Cloud (VPC) にデプロイするとき、またはクラスターに新しいサブネットを持つ追加のマシンプールを作成するときに、ネットワーク検証チェックが自動的に実行します。このチェックによりネットワーク設定が検証され、エラーが強調表示されるため、デプロイメント前に設定の問題を解決できます。
ネットワーク検証チェックを手動で実行して、既存のクラスターの設定を検証することもできます。:!rosa-with-hcp:
関連情報
- ネットワーク検証チェックの詳細は、ネットワーク検証 を参照してください。
3.5.5. ストレージ
このセクションでは、Hosted Control Plane (HCP) を備えた Red Hat OpenShift Service on AWS (ROSA) のストレージのサービス定義に関する情報を提供します。
3.5.5.1. 保存時に暗号化される (Encrypted-at-rest) OS およびノードストレージ
ワーカーノードは、保存時に暗号化される Amazon Elastic Block Store (Amazon EBS) ストレージを使用します。
3.5.5.2. 暗号化された保存時の PV
PV に使用される EBS ボリュームはデフォルトで保存時に暗号化されます。
3.5.5.3. ブロックストレージ (RWO)
永続ボリューム (PV) は、Read-Write-Once の Amazon Elastic Block Store (Amazon EBS) によってサポートされています。
PV は一度に 1 つのノードにのみ割り当てられ、それらがプロビジョニングされるアベイラビリティーゾーンに固有のものです。ただし、PV はそのアベイラビリティーゾーンの任意のノードに割り当てることができます。
各クラウドプロバイダーには、1 つのノードに割り当てることのできる PV の数について独自の制限があります。詳細は、AWS インスタンスタイプの制限 を参照してください。
3.5.5.4. 共有ストレージ (RWX)
AWS CSI ドライバーを使用すると、Hosted Control Plane (HCP) を備えた Red Hat OpenShift Service on AWS (ROSA) に RWX サポートを提供できます。コミュニティー Operator は、設定を簡素化するために提供されます。詳細は、Amazon Elastic File Storage Setup for OpenShift Dedicated and Red Hat OpenShift Service on AWS を参照してください。
3.5.6. プラットフォーム
このセクションでは、Hosted Control Plane (HCP) を備えた Red Hat OpenShift Service on AWS (ROSA) のプラットフォームのサービス定義に関する情報を提供します。
3.5.6.1. クラスターバックアップポリシー
Red Hat は、デフォルト構成である STS を使用する ROSA クラスターのバックアップ方法を提供していません。お客様がアプリケーションとアプリケーションデータのバックアップ計画を立てることが重要です。
アプリケーションおよびアプリケーションデータのバックアップは、Hosted Control Plane (HCP) を備えた Red Hat OpenShift Service on AWS (ROSA) の一部ではありません。
3.5.6.2. 自動スケーリング
Hosted Control Plane (HCP) を備えた Red Hat OpenShift Service on AWS (ROSA) では、ノードの自動スケーリングを利用できます。オートスケーラーオプションを設定して、クラスター内のマシンの数を自動的にスケーリングできます。
3.5.6.3. デーモンセット
Hosted Control Plane (HCP) を備えた Red Hat OpenShift Service on AWS (ROSA) では、デーモンセットを作成して実行できます。
3.5.6.4. 複数のアベイラビリティーゾーン
コントロールプレーンのコンポーネントは、お客様のワーカーノード設定に関係なく、常に複数のアベイラビリティゾーンにデプロイされます。
3.5.6.5. ノードラベル
カスタムノードラベルは、ノードの作成時に Red Hat によって作成され、現時点では、Hosted Control Plane (HCP) を備えた Red Hat OpenShift Service on AWS (ROSA) では変更できません。ただし、カスタムラベルは新規マシンプールの作成時にサポートされます。
3.5.6.6. OpenShift のバージョン
Hosted Control Plane (HCP) を備えた Red Hat OpenShift Service on AWS (ROSA) は、サービスとして実行され、OpenShift Container Platform の最新バージョンで最新の状態に保たれます。最新バージョンへのアップグレードのスケジューリング機能を利用できます。
3.5.6.7. アップグレード
アップグレードは、ROSA CLI、rosa
、または OpenShift Cluster Manager を使用してスケジュールできます。
アップグレードポリシーおよび手順の詳細は、Red Hat OpenShift Service on AWS のライフサイクル を参照してください。
3.5.6.8. Windows Containers
現時点では、Windows コンテナーに対する Red Hat OpenShift のサポートは Red Hat OpenShift Service on AWS では利用できません。
3.5.6.9. コンテナーエンジン
Hosted Control Plane (HCP) を備えた Red Hat OpenShift Service on AWS (ROSA) は、OpenShift 4 で実行し、唯一の利用可能なコンテナーエンジンとして CRI-O を使用します。
3.5.6.10. オペレーティングシステム
Hosted Control Plane (HCP) を備えた Red Hat OpenShift Service on AWS (ROSA) は、OpenShift 4 で実行され、すべてのコントロールプレーンおよびワーカーノードのオペレーティングシステムとして Red Hat CoreOS を使用します。
3.5.6.11. Red Hat Operator のサポート
通常、Red Hat ワークロードは、Operator Hub を通じて利用できる Red Hat 提供の Operator を指します。Red Hat ワークロードは Red Hat SRE チームによって管理されないため、ワーカーノードにデプロイする必要があります。これらの Operator は、追加の Red Hat サブスクリプションが必要になる場合があり、追加のクラウドインフラストラクチャーコストが発生する場合があります。これらの Red Hat 提供の Operator の例は次のとおりです。
- Red Hat Quay
- Red Hat Advanced Cluster Management
- Red Hat Advanced Cluster Security
- Red Hat OpenShift Service Mesh
- OpenShift Serverless
- Red Hat OpenShift Logging
- Red Hat OpenShift Pipelines
3.5.6.12. Kubernetes Operator のサポート
OperatorHub marketplace にリスト表示されるすべての Operator はインストールに利用できるはずです。これらの Operator はお客様のワークロードと見なされるため、Red Hat SRE の監視の対象外です。
3.5.7. セキュリティー
このセクションでは、Hosted Control Plane (HCP) を備えた Red Hat OpenShift Service on AWS (ROSA) のセキュリティーのサービス定義に関する情報を提供します。
3.5.7.1. 認証プロバイダー
クラスターの認証は、OpenShift Cluster Manager またはクラスター作成プロセスを使用するか、ROSA CLI rosa
を使用して設定できます。ROSA はアイデンティティープロバイダーではないため、クラスターへのアクセスすべてが統合ソリューションの一部としてお客様によって管理される必要があります。同時にプロビジョニングされる複数のアイデンティティープロバイダーの使用がサポートされます。以下のアイデンティティープロバイダーがサポートされます。
- GitHub または GitHub Enterprise
- GitLab
- LDAP
- OpenID Connect
- htpasswd
3.5.7.2. 特権付きコンテナー
特権付きコンテナーは、cluster-admin
ロールを持つユーザーが利用できます。特権付きコンテナーを cluster-admin
として使用する場合、これは Red Hat Enterprise Agreement Appendix 4 (Online Subscription Services) の責任および除外事項に基づいて使用されます。
3.5.7.3. お客様管理者ユーザー
Hosted Control Plane (HCP) を備えた Red Hat OpenShift Service on AWS (ROSA) は、通常のユーザーに加えて、dedicated-admin
と呼ばれる HCP 固有のグループを持つ ROSA へのアクセスを提供します。dedicated-admin
グループのメンバーであるクラスターのすべてのユーザーは、以下を実行できます。
- クラスターでお客様が作成したすべてのプロジェクトへの管理者アクセス権を持ちます。
- クラスターのリソースクォータと制限を管理できます。
-
NetworkPolicy
オブジェクトを追加および管理できます。 - スケジューラー情報を含む、クラスター内の特定のノードおよび PV に関する情報を表示できます。
-
クラスター上の予約された
dedicated-admin
プロジェクトにアクセスできます。これにより、昇格された権限を持つサービスアカウントの作成が可能になり、クラスター上のプロジェクトのデフォルトの制限とクォータを更新できるようになります。 -
OperatorHub から Operator をインストールし、すべての
*.operators.coreos.com
API グループのすべての動詞を実行できます。
3.5.7.4. クラスター管理ロール
Hosted Control Plane (HCP) を備えた Red Hat OpenShift Service on AWS (ROSA) の管理者には、組織のクラスターの cluster-admin
ロールへのデフォルトアクセス権があります。cluster-admin
ロールを持つアカウントにログインしている場合、ユーザーのパーミッションは、特権付きセキュリティーコンテキストを実行するために拡大します。
3.5.7.5. プロジェクトのセルフサービス
デフォルトで、すべてのユーザーはプロジェクトを作成し、更新し、削除できます。これは、dedicated-admin
グループのメンバーが認証されたユーザーから self-provisioner
ロールを削除すると制限されます。
$ oc adm policy remove-cluster-role-from-group self-provisioner system:authenticated:oauth
以下を適用すると、制限を元に戻すことができます。
$ oc adm policy add-cluster-role-to-group self-provisioner system:authenticated:oauth
3.5.7.6. 規制コンプライアンス
HCP を備えた ROSA は現在、コンプライアンス認定の取得を進めています。
3.5.7.7. ネットワークセキュリティー
Red Hat OpenShift Service on AWS では、AWS は AWS Shield と呼ばれる標準の DDoS 保護をすべてのロードバランサーで提供します。これにより、Red Hat OpenShift Service on AWS に使用されるすべてのパブリック向けロードバランサーで最も一般的に使用されるレベル 3 および 4 攻撃に対し、95% の保護が提供されます。応答を受信するために haproxy
ルーターに送信される HTTP 要求に 10 秒のタイムアウトが追加されるか、追加の保護を提供するために接続が切断されます。
3.5.7.8. etcd 暗号化
Hosted Control Plane (HCP) を備えた Red Hat OpenShift Service on AWS (ROSA) では、コントロールプレーンストレージがデフォルトで保存時に暗号化されます。これには etcd ボリュームの暗号化も含まれます。このストレージレベルの暗号化は、クラウドプロバイダーのストレージ層を介して提供されます。
etcd データベースはデフォルトで常に暗号化されます。お客様は、etcd データベースを暗号化する目的で、独自のカスタム AWS KMS キーを指定できます。
etcd 暗号化では、次の Kubernetes API サーバーおよび OpenShift API サーバーのリソースが暗号化されます。
- シークレット
- 設定マップ
- ルート
- OAuth アクセストークン
- OAuth 認証トークン
3.5.8. 関連情報
- 最新のコンプライアンス情報は、Red Hat OpenShift Service on AWS のプロセスおよびセキュリティーについて を参照してください。
- ROSA のライフサイクル を参照してください。
3.6. HCP を備えた ROSA の更新ライフサイクル
3.6.1. 概要
Red Hat は、Red Hat OpenShift Service on AWS の製品ライフサイクルを公開しています。これにより、お客様およびパートナー様は、プラットフォーム上で実行されるアプリケーションの計画、デプロイ、サポートを効果的に行えます。Red Hat は、可能な限りの透明性を実現するためにこのライフサイクルを公開していますが、問題が発生した場合はこれらのポリシーに例外を設ける場合もあります。
Red Hat OpenShift Service on AWS は Red Hat OpenShift のマネージドインスタンスであり、独立したリリーススケジュールを維持します。マネージドオファリングについての詳細は、Red Hat OpenShift Service on AWS のサービス定義を参照してください。特定バージョンのセキュリティーアドバイザリーおよびバグ修正アドバイザリーは、Red Hat OpenShift Container Platform のライフサイクルポリシーに基づいて利用可能となり、Red Hat OpenShift Service on AWS のメンテナンススケジュールに基づいて提供されます。
3.6.2. 定義
表3.2 バージョン参照
バージョンの形式 | メジャー | マイナー | パッチ | major.minor.patch |
---|---|---|---|---|
x | y | z | x.y.z | |
例 | 4 | 5 | 21 | 4.5.21 |
- メジャーリリースまたは X リリース
メジャーリリース または X リリース (X.y.z) としてのみ言及されます。
例
- "メジャーリリース 5" → 5.y.z
- "メジャーリリース 4" → 4.y.z
- "メジャーリリース 3" → 3.y.z
- マイナーリリースまたは Y リリース
マイナーリリース または Y リリース (x.Y.z) としてのみ言及されます。
例
- "マイナーリリース 4" → 4.4.z
- "マイナーリリース 5" → 4.5.z
- "マイナーリリース 6" → 4.6.z
- パッチリリースまたは Z リリース
パッチリリース または Z リリース (x.y.Z) としてのみ言及されます。
例
- "マイナーリリース 5 のパッチリリース 14" → 4.5.14
- "マイナーリリース 5 のパッチリリース 25" → 4.5.25
- "マイナーリリース 6 のパッチリリース 26" → 4.6.26
3.6.3. メジャーバージョン (X.y.z)
Red Hat OpenShift Service on AWS のメジャーバージョン (バージョン 4 など) は、後続のメジャーバージョンのリリースまたは製品の終了後 1 年間サポートされます。
例
- Red Hat OpenShift Service on AWS についてバージョン 5 が 1 月 1 日に利用可能になる場合、バージョン 4 は 12 月 31 日までの 12 カ月間、マネージドクラスターで実行を継続できます。その後、クラスターはアップグレード、またはバージョン 5 に移行する必要があります。
3.6.4. マイナーバージョン (x.Y.z)
4.8 OpenShift Container Platform マイナーバージョン以降、Red Hat は、特定のマイナーバージョンが一般公開されてから 16 か月間以上、すべてのマイナーバージョンをサポートします。パッチバージョンは、サポート期間の影響を受けません。
サポート期間が終了する 60 日前、30 日前、および 15 日前に、お客様に通知されます。サポート期間が終了する前に、クラスターをサポート対象の最も古いマイナーバージョンの最新パッチバージョンにクラスターをアップグレードする必要があります。アップグレードしないと、コントロールプレーンが次のサポート対象のマイナーバージョンに Red Hat によって自動的にアップグレードされます。
例
- 現時点で、お客様のクラスターは 4.13.8 で実行しているとします。4.13 マイナーバージョンは、2023 年 5 月 17 日に一般提供されました。
- 2024 年 7 月 19 日、8 月 16 日、および 9 月 2 日に、クラスターがサポート対象のマイナーバージョンにまだアップグレードされていない場合、2024 年 9 月 17 日にクラスターが "限定サポート" ステータスになることがお客様に通知されます。
- クラスターは、2024 年 9 月 17 日までに 4.14 以降にアップグレードする必要があります。
- アップグレードが実行されていない場合、クラスターのコントロールプレーンが自動的に 4.14.26 にアップグレードされます。クラスターのワーカーノードへの自動アップグレードは行われません。
3.6.5. パッチバージョン (x.y.Z)
マイナーバージョンがサポートされる期間中、とくに指定がない限り、Red Hat はすべての OpenShift Container Platform パッチバージョンをサポートします。
プラットフォームのセキュリティーおよび安定性の理由から、あるパッチリリースが非推奨になる可能性があります。この場合は、そのリリースのインストールができなくなり、そのリリースからの強制的なアップグレードが必要となります。
例
- 4.7.6 に重要な CVE が含まれることが確認されるとします。
- CVE の影響を受けるすべてのリリースは、サポートされるパッチリリースのリストから削除されます。さらに、4.7.6 を実行するクラスターは、自動アップグレードのスケジュールが 48 時間以内に行われます。
3.6.6. 限定サポートステータス
クラスターが 限定サポート ステータスに移行すると、Red Hat はクラスターをプロアクティブに監視しなくなり、SLA は適用されなくなり、SLA に対して要求されたクレジットは拒否されます。製品サポートがなくなったという意味ではありません。場合によっては、違反要因を修正すると、クラスターが完全にサポートされた状態に戻ることがあります。ただし、それ以外の場合は、クラスターを削除して再作成する必要があります。
クラスターは、次のシナリオなど、さまざまな理由で限定サポートステータスに移行する場合があります。
- ネイティブの Red Hat OpenShift Service on AWS コンポーネント、または Red Hat がインストールおよび管理するその他のコンポーネントを削除または置き換える場合
- クラスター管理者パーミッションを使用した場合、Red Hat は、インフラストラクチャーサービス、サービスの可用性、またはデータ損失に影響を与えるアクションを含む、ユーザーまたは認可されたユーザーのアクションに対して責任を負いません。Red Hat がそのようなアクションを検出した場合、クラスターは限定サポートステータスに移行する可能性があります。Red Hat はステータスの変更を通知します。アクションを元に戻すか、サポートケースを作成して、クラスターの削除と再作成が必要になる可能性のある修復手順を検討する必要があります。
クラスターが限定サポートステータスに移行する可能性のある特定のアクションについて質問がある場合、またはさらに支援が必要な場合は、サポートチケットを作成します。
3.6.7. サポート対象バージョンの例外ポリシー
Red Hat は、事前通知なしに新規または既存のバージョンを追加または削除したり、実稼働環境に影響を与える重要なバグまたはセキュリティーの問題があることが確認された今後のマイナーリリースバージョンを遅延させる権利を留保します。
3.6.8. インストールポリシー
Red Hat では、最新のサポートリリースのインストールを推奨していますが、Red Hat OpenShift Service on AWS は前述のポリシーに記載されているサポート対象のリリースのインストールをサポートします。
3.6.9. 必須アップグレード
Critical (重大) または Important (重要) の CVE、または Red Hat が特定するその他のバグが、クラスターのセキュリティーまたは安定性に大幅に影響を与える場合、お客様は 2 営業日 以内にサポート対象の次のパッチリリースにアップグレードする必要があります。
極端な状況下では、環境に対する CVE の重要性に関する Red Hat の評価に基づいて、Red Hat はお客様に対して、2 営業日 以内にクラスターを最新の安全なパッチリリースに更新するようスケジュールするか手動で更新するように通知します。2 営業日 が経過しても、更新が実行されない場合、Red Hat は潜在的なセキュリティー違反や不安定性を軽減するために、クラスターのコントロールプレーンを最新の安全なパッチリリースに自動的に更新します。Red Hat は、サポートケース を通じてお客様からリクエストがあった場合、当社の判断で自動更新を一時的に延期することがあります。
3.6.10. ライフサイクルの日付
バージョン | 一般公開 | ライフサイクルの終了日 |
---|---|---|
4.15 | 2024 年 2 月 27 日 | 2025 年 6 月 30 日 |
4.14 | 2023 年 12 月 4 日 | 2025 年 2 月 28 日 |
3.7. Red Hat OpenShift Service on AWS のセキュリティーについて
このドキュメントでは、Red Hat、Amazon Web Services (AWS)、および管理対象の Red Hat OpenShift Service on AWS (ROSA) に対するお客様のセキュリティーに関する責任について詳しく説明します。
頭字語および用語
- AWS - Amazon Web Services
- CEE - Customer Experience and Engagement (Red Hat サポート)
- CI/CD - 継続的インテグレーション/継続的デリバリー
- CVE - 共通脆弱性識別子 (Common Vulnerabilities and Exposures)
- PV - 永続ボリューム
- ROSA - Red Hat OpenShift Service on AWS
- SRE - Red Hat Site Reliability Engineering
- VPC - Virtual Private Cloud
3.7.1. セキュリティーおよび規制コンプライアンス
セキュリティーおよび規制コンプライアンスには、セキュリティー管理の実装やコンプライアンス認定などのタスクが含まれます。
3.7.1.1. データの分類
Red Hat は、データの機密性を判断し、収集、使用、送信、保存、処理中にデータの機密性と整合性に対する固有のリスクを特定するためにデータ分類の標準を定義し、これに従います。お客様が所有するデータは、最高レベルの機密性と処理要件を持つものとして分類されます。
3.7.1.2. データ管理
Red Hat OpenShift Service on AWS (ROSA) は、AWS Key Management Service (KMS) を使用して、暗号化されたデータのキーを安全に管理します。これらのキーは、デフォルトで暗号化されるコントロールプレーン、インフラストラクチャー、およびワーカーデータボリュームに使用されます。お客様のアプリケーションの永続ボリューム (PV) は、キー管理に AWS KMS を使用します。
お客様が ROSA クラスターを削除すると、コントロールプレーンのデータボリュームや、永続ボリューム (PV) などのお客様のアプリケーションデータボリュームを含め、すべてのクラスターのデータが永久に削除されます。
3.7.1.3. 脆弱性管理
Red Hat は業界標準ツールを使用して ROSA の定期的な脆弱性スキャンを実行します。特定される脆弱性は、重大度に基づくタイムラインに応じて修復されるまで追跡されます。コンプライアンス認定監査の過程で、脆弱性スキャンと修復のアクティビティーが文書化され、サードパーティーの評価者による検証が行われます。
3.7.1.4. ネットワークセキュリティー
3.7.1.4.1. ファイアウォールおよび DDoS 保護
各 ROSA クラスターは、AWS セキュリティーグループのファイアウォールルールを使用してセキュアなネットワーク設定で保護されます。ROSA のお客様は、AWS Shield Standard により DDoS 攻撃に対して保護されます。
3.7.1.4.2. プライベートクラスターおよびネットワーク接続
お客様はオプションとして、Web コンソール、API、アプリケーションルーターなどの ROSA クラスターエンドポイントをプライベートに設定し、クラスターのコントロールプレーンおよびアプリケーションがインターネットからアクセスされないようにできます。Red Hat SRE には、IP 許可リストを使用して保護されるインターネットアクセス可能なエンドポイントが必要です。
AWS のお客様は、AWS VPC のピアリング、AWS VPN、AWS Direct Connect などのテクノロジーを使用して、ROSA クラスターへのプライベートネットワーク接続を設定できます。
3.7.1.4.3. クラスターネットワークのアクセス制御
粒度の細かいネットワークアクセス制御ルールは、お客様が NetworkPolicy
オブジェクトおよび OpenShift SDN を使用してプロジェクトごとに設定できます。
3.7.1.5. ペネトレーションテスト
Red Hat は、ROSA に対して定期的なペネトレーションテストを実行します。テストは、業界標準ツールやベストプラクティスを使用して独立した内部チームによって実行されます。
検出される可能性のある問題は、重大度に基づいて優先付けされます。オープンソースプロジェクトに属する問題が確認される場合は、解決に向けてコミュニティーに共有されます。
3.7.1.6. コンプライアンス
Red Hat OpenShift Service on AWS は、セキュリティーおよび管理に関する一般的な業界のベストプラクティスに従います。認定の概要を以下の表に示します。
表3.3 Red Hat OpenShift Service on AWS のセキュリティーおよび管理に関する認定
コンプライアンス | Red Hat OpenShift Service on AWS (ROSA) | ホスト型コントロールプレーン (HCP) を備えた Red Hat OpenShift Service on AWS (ROSA) |
---|---|---|
HIPAA Qualified | はい | いいえ |
ISO 27001 | はい | いいえ |
ISO 27017 | はい | いいえ |
ISO 27018 | はい | いいえ |
PCI DSS | はい | いいえ |
SOC 2 タイプ 2 | はい | いいえ |
SOC 3 | はい | いいえ |
FedRAMP High[1] | はい (GovCloud の要件) | いいえ |
- ROSA on GovCloud の詳細は、FedRAMP Marketplace ROSA Agency および ROSA JAB listings を参照してください。
関連情報
- SRE の常駐に関する詳細は、Red Hat Subprocessor List を参照してください。
- お客様や責任共有の詳細は、ROSA の各種の責任 に関する文書を参照してください。
- ROSA およびそのコンポーネントの詳細は、ROSA サービス定義 を参照してください。
3.8. SRE およびサービスアカウントのアクセス
Red Hat Site Reliability Engineering (SRE) による Red Hat OpenShift Service on AWS (ROSA) クラスターへのアクセスについて、アイデンティティーおよびアクセス管理の観点から説明します。
3.8.1. アイデンティティーおよびアクセス管理
Red Hat SRE チームによるアクセスのほとんどは、自動化された設定管理によりクラスター Operator を使用して行われます。
サブプロセッサー
利用可能なサブプロセスのリストは、Red Hat カスタマーポータルの Red Hat Subprocessor List を参照してください。
3.8.2. SRE クラスターアクセス
SRE による Red Hat OpenShift Service on AWS (ROSA) クラスターへのアクセスは、複数の必要な認証階層を通じて制御され、すべて厳格な企業ポリシーによって管理されます。クラスターにアクセスするすべての認証試行とクラスター内で行われた変更は、それらのアクションを担当する SRE の特定のアカウント ID とともに監査ログに記録されます。これらの監査ログは、SRE によって顧客のクラスターに加えられたすべての変更が、Red Hat のマネージドサービスガイドラインを構成する厳格なポリシーと手順に準拠していることを確認するのに役立ちます。
以下に示す情報は、SRE が顧客のクラスターにアクセスするために実行する必要があるプロセスの概要です。
- SRE は、Red Hat SSO (クラウドサービス) に更新された ID トークンを要求します。このリクエストは認証されます。トークンは 15 分間有効です。トークンの有効期限が切れたら、トークンを再度更新して新しいトークンを受け取ることができます。新規トークンへの更新機能には期限はありません。ただし、新しいトークンに更新する機能は、非アクティブな状態が 30 日間続くと無効になります。
- SRE は Red Hat VPN に接続します。VPN への認証は、Red Hat Corporate Identity and Access Management システム (RH IAM) によって行います。RH IAM を使用すると、SRE は多要素になり、グループおよび既存のオンボーディングおよびオフボーディングプロセスによって組織ごとに内部管理できるようになります。SRE が認証されて接続されると、SRE はクラウドサービスフリート管理プレーンにアクセスできるようになります。クラウドサービスフリート管理プレーンの変更には何層にもわたる承認が必要であり、厳格な企業ポリシーによって維持されます。
- 承認が完了すると、SRE はフリート管理プレーンにログインし、フリート管理プレーンが作成したサービスアカウントトークンを受け取ります。トークンは 15 分間有効です。トークンは無効になると、削除されます。
フリート管理プレーンにアクセスが許可されると、SRE はネットワーク設定に応じてさまざまな方法を使用してクラスターにアクセスします。
- プライベートまたはパブリッククラスターへのアクセス: リクエストは、ポート 6443 で暗号化された HTTP 接続を使用して、特定のネットワークロードバランサー (NLB) 経由で送信されます。
- PrivateLink クラスターへのアクセス: リクエストは Red Hat Transit Gateway に送信され、リージョンごとに Red Hat VPC に接続されます。リクエストを受信する VPC は、ターゲットのプライベートクラスターのリージョンに依存します。VPC 内には、顧客の PrivateLink クラスターへの PrivateLink エンドポイントを含むプライベートサブネットがあります。
SRE は、Web コンソールまたはコマンドラインインターフェイス (CLI) ツールを使用して ROSA クラスターにアクセスします。認証には、パスワードの複雑さおよびアカウントのロックアウトに関する業界標準の要件が適用されるマルチファクター認証 (MFA) が必要です。SRE は、監査可能性を確保するために個人として認証する必要があります。すべての認証試行は、セキュリティー情報およびイベント管理 (SIEM) システムに記録されます。
SRE は、暗号化された HTTP 接続を使用してプライベートクラスターにアクセスします。接続は、IP 許可リストまたはプライベートクラウドプロバイダーのリンクを使用して、セキュアな Red Hat ネットワークからのみ許可されます。
図3.1 SRE による ROSA クラスターへのアクセス
3.8.2.1. ROSA の特権アクセスの制御
SRE は、ROSA および AWS コンポーネントにアクセスする際に最小権限の原則に従います。SRE の手動によるアクセスには、基本的に以下の 4 つのカテゴリーがあります。
- 通常の 2 要素認証を使用するが、権限の昇格のない Red Hat ポータル経由での SRE の管理者アクセス。
- 通常の 2 要素認証を使用するが、権限の昇格のない Red Hat の企業 SSO を使用した SRE の管理者アクセス。
- OpenShift の昇格。これは Red Hat SSO を使用した手動による昇格です。アクセスは 2 時間に制限され、完全に監査対象となり、管理者承認が必要になります。
- AWS アクセスまたは昇格。AWS コンソールまたは CLI アクセスの手動による昇格です。アクセスは 60 分間に制限され、完全に監査されます。
これらのアクセスタイプのそれぞれには、コンポーネントへの異なるレベルのアクセスがあります。
コンポーネント | 通常の SRE 管理者アクセス (Red Hat ポータル) | 通常の SRE 管理者アクセス (Red Hat SSO) | OpenShift の昇格 | クラウドプロバイダーのアクセスまたは昇格 |
---|---|---|---|---|
OpenShift Cluster Manager | R/W | アクセスなし | アクセスなし | アクセスなし |
OpenShift コンソール | アクセスなし | R/W | R/W | アクセスなし |
ノードのオペレーティングシステム | アクセスなし | 昇格した OS およびネットワークのパーミッションのリスト。 | 昇格した OS およびネットワークのパーミッションのリスト。 | アクセスなし |
AWS コンソール | アクセスなし | アクセスはありませんが、これはクラウドプロバイダーのアクセスを要求するために使用されるアカウントです。 | アクセスなし | SRE アイデンティティーを使用したすべてのクラウドプロバイダーのパーミッション。 |
3.8.2.2. SRE による AWS アカウントへのアクセス
Red Hat の担当者は、通常の Red Hat OpenShift Service on AWS 操作では AWS アカウントにアクセスしません。緊急のトラブルシューティングが必要な場合に、SRE にはクラウドインフラストラクチャーアカウントにアクセスするための明確に定義された監査可能な手順があります。
SRE は、AWS Security Token Service (STS) を使用して確保したロールの有効期間の短い AWS アクセストークンを生成します。STS トークンへのアクセスは監査ログに記録され、個別のユーザーまでトレースできます。STS および非 STS クラスターはいずれも、SRE によるアクセスに AWS STS サービスを使用します。STS 以外のクラスターの場合は、BYOCAdminAccess
ロールに AdministratorAccess
IAM ポリシーが割り当てられ、このロールは管理に使用されます。STS クラスターの場合、ManagedOpenShift-Support-Role
には ManagedOpenShift-Support-Access
ポリシーが割り当てられており、このロールは管理に使用されます。
3.8.2.3. AWS アカウントの SRE STS ビュー
SRE が 2 要素認証を使用する VPN を使用している場合、SRE と Red Hat サポートは AWS アカウントで ManagedOpenShift-Support-Role
を引き受けることができます。ManagedOpenShift-Support-Role
には、SRE が AWS リソースを直接トラブルシューティングして管理するために必要なすべての権限が含まれています。ManagedOpenShift-Support-Role
を引き受けると、SRE は AWS Security Token Service (STS) を使用して、顧客のアカウントの AWS Web UI への有効期限付きの一意の URL を生成します。その後、SRE は次のような複数のトラブルシューティングアクションを実行できます。
- CloudTrail ログの表示
- 障害のある EC2 インスタンスのシャットダウン
SRE によって実行されるすべてのアクティビティーは Red Hat IP アドレスから受信され、CloudTrail に記録されるため、すべてのアクティビティーを監査およびレビューできます。このロールは、AWS サービスへのアクセスが必要な場合にのみ使用されます。権限の大部分は読み取り専用です。ただし、一部の権限にはわずかに、インスタンスの再起動や新しいインスタンスのスピンアップなど、より多くのアクセス権があります。SRE によるアクセスは、ManagedOpenShift-Support-Role
に割り当てられているポリシー権限に制限されます。
権限の完全なリストについては、STS を使用する ROSA クラスターの IAM リソース ユーザーガイドの sts_support_permission_policy.json を参照してください。
3.8.2.4. PrivateLink VPC エンドポイントサービスを介した SRE によるアクセス
PrivateLink VPC エンドポイントサービスは、ROSA クラスター作成の一部として作成されます。
PrivateLink ROSA クラスターがある場合、その Kubernetes API サーバーは、デフォルトでは VPC 内からのみアクセスできるロードバランサーを通じて公開されます。Red Hat Site Reliability Engineering (SRE) は、Red Hat が所有する AWS アカウントに VPC エンドポイントが関連付けられている VPC エンドポイントサービスを介して、このロードバランサーに接続できます。このエンドポイントサービスには、ARN にも含まれるクラスターの名前が含まれています。
Allow principals タブに、Red Hat 所有の AWS アカウントがリストされます。この特定のユーザーにより、他のエンティティーが PrivateLink クラスターの Kubernetes API サーバーへの VPC エンドポイント接続を作成できないようになります。
Red Hat SRE が API にアクセスすると、このフリート管理プレーンは VPC エンドポイントサービスを通じて内部 API に接続できます。
3.8.3. Red Hat サポートのアクセス
通常、Red Hat の CEE (Customer Experience and Engagement) チームは、クラスターの各部分への読み取り専用アクセスを持ちます。とくに、CEE にはコアおよび製品の namespace への制限されたアクセスがありますが、お客様の namespace へのアクセスはありません。
ロール | コア namespace | 階層化した製品 namespace | お客様の namespace | AWS アカウント* |
---|---|---|---|---|
OpenShift SRE | 読み取り: All 書き込み: Very 限定的[1] | 読み取り: All 書き込み: None | 読み取り: None[2] 書き込み: None | 読み取り: All [3] 書き込み: All [3] |
CEE | 読み取り: All 書き込み: None | 読み取り: All 書き込み: None | 読み取り: None[2] 書き込み: None | 読み取り: None 書き込み: None |
お客様管理者 | 読み取り: None 書き込み: None | 読み取り: None 書き込み: None | 読み取り: All 書き込み: All | 読み取り: All 書き込み: All |
お客様ユーザー | 読み取り: None 書き込み: None | 読み取り: None 書き込み: None | 読み取り: Limited[4] 書き込み: Limited[4] | 読み取り: None 書き込み: None |
上記以外 | 読み取り: None 書き込み: None | 読み取り: None 書き込み: None | 読み取り: None 書き込み: None | 読み取り: None 書き込み: None |
- デプロイメントの失敗、クラスターのアップグレード、および正しくないワーカーノードの置き換えなどの一般的なユースケースに対応することに限定されます。
- Red Hat は、デフォルトではお客様のデータにアクセスできません。
- SRE は AWS アカウントに、文書化されたインシデントの発生時の例外的なトラブルシューティングのための緊急手順としてアクセスします。
- 顧客管理者によって RBAC で許可される内容と、ユーザーが作成した namespace に限定されます。
3.8.4. お客様のアクセス
お客様のアクセスは、お客様によって作成される namespace、およびお客様管理者ロールによって RBAC を使用して付与されるパーミッションに限定されます。基礎となるインフラストラクチャーまたは製品 namespace へのアクセスは通常、cluster-admin
アクセスなしでは許可されません。お客様のアクセスと認証の詳細は、このドキュメントの認証に関するセクションを参照してください。
3.8.5. アクセスの承認およびレビュー
新規の SRE ユーザーアクセスには、管理者の承認が必要です。分離された SRE アカウントまたは転送された SRE アカウントは、自動化されたプロセスで認可されたユーザーとして削除されます。さらに、SRE は、認可されたユーザーリストの管理者の署名を含む、定期的なアクセスのレビューを実行します。
アクセスとアイデンティティーの認可表には、クラスター、アプリケーション、およびインフラストラクチャーリソースへの承認済みアクセスを管理する責任が含まれます。これには、アクセス制御メカニズム、認証、および認可を提供し、リソースへのアクセスを管理するタスクが含まれます。
リソース | サービスの責任 | お客様の責任 |
---|---|---|
ロギング | Red Hat
|
|
アプリケーションのネットワーク | Red Hat
|
|
クラスターネットワーク | Red Hat
|
|
仮想ネットワーク管理 | Red Hat
|
|
仮想ストレージ管理 | Red Hat
|
|
仮想コンピューティング管理 | Red Hat
|
|
AWS ソフトウェア (パブリック AWS サービス) | AWS Compute: ROSA コントロールプレーン、インフラストラクチャー、ワーカーノードに使用される Amazon EC2 サービスを提供します。 Storage: ROSA がクラスターにローカルノードストレージと永続ボリュームストレージをプロビジョニングできるようにするために使用される Amazon EBS を提供します。 Storage: サービスの組み込みイメージレジストリーに使用される Amazon S3 を提供します。 Networking: 顧客アカウントで実行されている ROSA リソースへのアクセスを制御するために顧客が使用する AWS Identity and Access Management (IAM) を提供します。 |
|
ハードウェアと AWS グローバルインフラストラクチャー | AWS
|
|
3.8.6. サービスアカウントが SRE 所有のプロジェクトで AWS IAM ロールを引き受ける方法
AWS Security Token Service (STS) を使用する Red Hat OpenShift Service on AWS クラスターをインストールすると、クラスター固有の Operator AWS Identity and Access Management (IAM) ロールが作成されます。これらの IAM ロールにより、Red Hat OpenShift Service on AWS クラスター Operator がコア OpenShift 機能を実行できるようになります。
クラスター Operator はサービスアカウントを使用して IAM ロールを引き受けます。サービスアカウントが IAM ロールを引き受けると、クラスター Operator の Pod で使用するサービスアカウントに一時的な STS 認証情報が提供されます。引き受けたロールに必要な AWS 権限がある場合、サービスアカウントは Pod で AWS SDK 操作を実行できます。
SRE 所有プロジェクトで AWS IAM ロールを引き受けるワークフロー
次の図は、SRE 所有プロジェクトで AWS IAM ロールを引き受けるためのワークフローを示しています。
図3.2 SRE 所有プロジェクトで AWS IAM ロールを引き受けるワークフロー
ワークフローには次の段階があります。
クラスター Operator が実行する各プロジェクト内で、Operator のデプロイメント仕様には、投影されたサービスアカウントトークンのボリュームマウントと、Pod の AWS 認証情報設定が含まれるシークレットがあります。トークンは、オーディエンスおよび時間の制限があります。Red Hat OpenShift Service on AWS は 1 時間ごとに新しいトークンを生成し、AWS SDK は AWS 認証情報の設定を含むマウントされたシークレットを読み取ります。この設定には、マウントされたトークンと AWS IAM ロール ARN へのパスが含まれています。シークレットの認証情報設定には次のものが含まれます。
-
AWS SDK オペレーションの実行に必要なパーミッションを持つ IAM ロールの ARN を含む
$AWS_ARN_ROLE
変数。 -
サービスアカウントの OpenID Connect (OIDC) トークンへの Pod 内のフルパスを含む
$AWS_WEB_IDENTITY_TOKEN_FILE
変数。完全パスは/var/run/secrets/openshift/serviceaccount/token
です。
-
AWS SDK オペレーションの実行に必要なパーミッションを持つ IAM ロールの ARN を含む
-
クラスター Operator が AWS サービス(EC2 など)にアクセスするために AWS IAM ロールを引き受ける必要がある場合、Operator で実行される AWS SDK クライアントコードは
AssumeRoleWithWebIdentity
API を呼び出します。 OIDC トークンは、Pod から OIDC プロバイダーに渡されます。次の要件が満たされている場合は、プロバイダーがサービスアカウント ID を認証します。
- ID 署名は有効であり、秘密鍵によって署名されています。
sts.amazonaws.com
オーディエンスは OIDC トークンにリストされており、OIDC プロバイダーで設定されたオーディエンスと一致します。注記STS クラスターを使用する Red Hat OpenShift Service on AWS では、インストール中に OIDC プロバイダーが作成され、デフォルトでサービスアカウント発行者として設定されます。
sts.amazonaws.com
オーディエンスは、デフォルトで OIDC プロバイダーに設定されています。- OIDC トークンの有効期限が切れていません。
- トークン内の発行者の値には、OIDC プロバイダーの URL が含まれています。
- プロジェクトとサービスアカウントが、引き受ける IAM ロールの信頼ポリシーのスコープ内にある場合は、認可が成功します。
- 認証と認可が成功すると、AWS アクセストークン、秘密鍵、セッショントークンの形式で一時的な AWS STS 認証情報が Pod に渡され、サービスアカウントで使用されます。認証情報を使用することで、IAM ロールで有効になっている AWS アクセス許可がサービスアカウントに一時的に付与されます。
- クラスター Operator が実行されると、Pod で AWS SDK を使用している Operator は、投影されたサービスアカウントへのパスが含まれるシークレットと AWS IAM ロール ARN を OIDC プロバイダーに対して認証するためのシークレットを消費します。OIDC プロバイダーは、AWS API に対する認証に使用できるように、一時的な STS 認証情報を返します。
関連情報
- クラスター Operator によって使用される AWS IAM ロールの詳細は、クラスター固有の Operator IAM ロールのリファレンス を参照してください。
- クラスター Operator に必要なポリシーと権限の詳細は、アカウント全体のロールの作成方法 を参照してください。
第4章 受付プラグイン
受付プラグインは、Red Hat OpenShift Service on AWS の機能の調整に役立ちます。
4.1. 受付プラグインについて
受付プラグインは、マスター API へのリクエストをインターセプトして、リソースリクエストを検証します。リクエストが認証および認可された後、受付プラグインは、関連するポリシーが遵守されていることを確認します。受付プラグインは、たとえばセキュリティーポリシー、リソース制限、設定要件を適用するためによく使用されます。
受付プラグインは受付チェーン (admission chain) として順番に実行されます。シーケンス内の受付プラグインが要求を拒否すると、チェーン全体が中止され、エラーが返されます。
Red Hat OpenShift Service on AWS には、各リソースタイプについて有効にされている受付プラグインのデフォルトセットがあります。それらはマスターが適切に機能するために必要です。受付プラグインは、それらが対応していないリソースを無視します。
デフォルト以外にも、受付チェーンは、カスタム Webhook サーバーを呼び出す Webhook 受付プラグインを介して動的に拡張できます。Webhook 受付プラグインには、変更用の受付プラグインと検証用の受付プラグインの 2 種類があります。変更用の受付プラグインが最初に実行され、リソースの変更および要求の検証の両方が可能です。検証用の受付プラグインは要求を検証し、変更用の受付プラグインによってトリガーされた変更も検証できるように変更用の受付プラグインの後に実行されます。
変更用の受付プラグインを使用して Webhook サーバーを呼び出すと、ターゲットオブジェクトに関連するリソースに影響を与える可能性があります。このような場合に、最終結果が想定通りであることを検証するためにいくつかの手順を実行する必要があります。
動的な受付クラスターはコントロールプレーンの操作に影響するため、これは注意して使用する必要があります。Red Hat OpenShift Service on AWS 4 の Webhook 受付プラグインを使用して Webhook サーバーを呼び出す場合は、変更による影響についての情報を十分に確認し、それらの影響の有無についてテストするようにしてください。要求が受付チェーン全体を通過しない場合は、リソースを変更前の元の状態に復元する手順を追加します。
4.2. デフォルトの受付プラグイン
Red Hat OpenShift Service on AWS 4 では、デフォルトの検証および受付プラグインが有効になっています。これらのデフォルトプラグインは、Ingress ポリシー、クラスターリソース制限の上書き、クォータポリシーなどの基本的なコントロールプレーンの機能に貢献するものです。
デフォルトプロジェクトでワークロードを実行したり、デフォルトプロジェクトへのアクセスを共有したりしないでください。デフォルトのプロジェクトは、コアクラスターコンポーネントを実行するために予約されています。
次のデフォルトプロジェクトは、高い特権があるとみなされます (default
、kube-public
、kube-system
、openshift
、openshift-infra
、openshift-node
、および openshift.io/run-level
ラベルが 0
または 1
に設定されているその他のシステム作成プロジェクト)。Pod セキュリティーアドミッション、セキュリティーコンテキスト制約、クラスターリソースクォータ、イメージ参照解決などの受付プラグインに依存する機能は、高い特権を持つプロジェクトでは機能しません。
次のリストには、デフォルトの受付プラグインが含まれています。
例4.1 受付プラグインの検証
-
LimitRanger
-
ServiceAccount
-
PodNodeSelector
-
優先度
-
PodTolerationRestriction
-
OwnerReferencesPermissionEnforcement
-
PersistentVolumeClaimResize
-
RuntimeClass
-
CertificateApproval
-
CertificateSigning
-
CertificateSubjectRestriction
-
autoscaling.openshift.io/ManagementCPUsOverride
-
authorization.openshift.io/RestrictSubjectBindings
-
scheduling.openshift.io/OriginPodNodeEnvironment
-
network.openshift.io/ExternalIPRanger
-
network.openshift.io/RestrictedEndpointsAdmission
-
image.openshift.io/ImagePolicy
-
security.openshift.io/SecurityContextConstraint
-
security.openshift.io/SCCExecRestrictions
-
route.openshift.io/IngressAdmission
-
config.openshift.io/ValidateAPIServer
-
config.openshift.io/ValidateAuthentication
-
config.openshift.io/ValidateFeatureGate
-
config.openshift.io/ValidateConsole
-
operator.openshift.io/ValidateDNS
-
config.openshift.io/ValidateImage
-
config.openshift.io/ValidateOAuth
-
config.openshift.io/ValidateProject
-
config.openshift.io/DenyDeleteClusterConfiguration
-
config.openshift.io/ValidateScheduler
-
quota.openshift.io/ValidateClusterResourceQuota
-
security.openshift.io/ValidateSecurityContextConstraints
-
authorization.openshift.io/ValidateRoleBindingRestriction
-
config.openshift.io/ValidateNetwork
-
operator.openshift.io/ValidateKubeControllerManager
-
ValidatingAdmissionWebhook
-
ResourceQuota
-
quota.openshift.io/ClusterResourceQuota
例4.2 受付プラグインの変更
-
NamespaceLifecycle
-
LimitRanger
-
ServiceAccount
-
NodeRestriction
-
TaintNodesByCondition
-
PodNodeSelector
-
優先度
-
DefaultTolerationSeconds
-
PodTolerationRestriction
-
DefaultStorageClass
-
StorageObjectInUseProtection
-
RuntimeClass
-
DefaultIngressClass
-
autoscaling.openshift.io/ManagementCPUsOverride
-
scheduling.openshift.io/OriginPodNodeEnvironment
-
image.openshift.io/ImagePolicy
-
security.openshift.io/SecurityContextConstraint
-
security.openshift.io/DefaultSecurityContextConstraints
-
MutatingAdmissionWebhook
4.3. Webhook 受付プラグイン
Red Hat OpenShift Service on AWS のデフォルト受付プラグインのほかに、受付チェーンの機能を拡張するために Webhook サーバーを呼び出す Webhook 受付プラグインを使用して動的な受付を実装できます。Webhook サーバーは、定義されたエンドポイントにて HTTP で呼び出されます。
Red Hat OpenShift Service on AWS には、2 種類の Webhook 受付プラグインがあります。
- 受付プロセスで、変更用の受付プラグイン は、アフィニティーラベルの挿入などのタスクを実行できます。
- 受付プロセスの最後に、検証用の受付プラグイン を使用して、アフィニティーラベルが予想通りにされているかどうかの確認など、オブジェクトが適切に設定されていることを確認できます。検証にパスすると、Red Hat OpenShift Service on AWS はオブジェクトを設定済みとしてスケジュールします。
API 要求が送信されると、変更用または検証用の受付コントローラーは設定内の外部 Webhook の一覧を使用し、それらを並行して呼び出します。
- Webhook のすべてが要求を承認する場合、受付チェーンは継続します。
- Webhook のいずれかが要求を拒否する場合、受付要求は拒否され、これは、初回の拒否理由に基づいて実行されます。
- 複数の Webhook が受付要求を拒否する場合、初回の拒否理由のみがユーザーに返されます。
-
Webhook の呼び出し時にエラーが発生した場合、要求は拒否されるか、Webhook はエラーポリシーセットに応じて無視されます。エラーポリシーが
Ignore
に設定されている場合、要求は失敗すると無条件で受け入れられます。ポリシーがFail
に設定される場合、失敗した要求は拒否されます。Ignore
を使用すると、すべてのクライアントの予測できない動作が生じる可能性があります。
以下の図は、複数の Webhook サーバーが呼び出される連続した受付チェーンのプロセスを示しています。
図4.1 変更用および検証用の受付プラグインを含む API 受付チェーン
Webhook 受付プラグインのユースケースの例として使用できるケースでは、すべての Pod に共通のラベルのセットがなければなりません。この例では、変更用の受付プラグインはラベルを挿入でき、検証用の受付プラグインではラベルが予想通りであることを確認できます。Red Hat OpenShift Service on AWS は引き続いて必要なラベルが含まれる Pod をスケジュールし、それらのラベルが含まれない Pod を拒否します。
一般的な Webhook 受付プラグインのユースケースとして、以下が含まれます。
- namespace の予約。
- SR-IOV ネットワークデバイスプラグインによって管理されるカスタムネットワークリソースの制限。
- Pod 優先順位クラスの検証。
Red Hat OpenShift Service on AWS のデフォルトの Webhook タイムアウトの最大値は 13 秒です。この値は変更できません。
4.4. Webhook 受付プラグインのタイプ
クラスター管理者は、API サーバーの受付チェーンで変更用の受付プラグインまたは検証用の受付プラグインを使用して Webhook サーバーを呼び出すことができます。
4.4.1. 受付プラグインの変更
変更用の受付プラグインは、受付プロセスの変更フェーズで起動します。これにより、リソースコンテンツが永続化する前にそれらを変更することができます。変更用の受付プラグインで呼び出し可能な Webhook の一例として、Pod ノードセレクター機能があります。 この機能は namespace でアノテーションを使用してラベルセレクターを検索し、これを Pod 仕様に追加します。
変更用の受付プラグインの設定例:
apiVersion: admissionregistration.k8s.io/v1beta1 kind: MutatingWebhookConfiguration 1 metadata: name: <webhook_name> 2 webhooks: - name: <webhook_name> 3 clientConfig: 4 service: namespace: default 5 name: kubernetes 6 path: <webhook_url> 7 caBundle: <ca_signing_certificate> 8 rules: 9 - operations: 10 - <operation> apiGroups: - "" apiVersions: - "*" resources: - <resource> failurePolicy: <policy> 11 sideEffects: None
- 1
- 変更用の受付プラグイン設定を指定します。
- 2
MutatingWebhookConfiguration
オブジェクトの名前。<webhook_name>
を適切な値に置き換えます。- 3
- 呼び出す Webhook の名前です。
<webhook_name>
を適切な値に置き換えます。 - 4
- Webhook サーバーに接続し、これを信頼し、データをこれに送信する方法についての情報です。
- 5
- フロントエンドサービスが作成される namespace です。
- 6
- フロントエンドサービスの名前です。
- 7
- 受付要求に使用される Webhook URL です。
<webhook_url>
を適切な値に置き換えます。 - 8
- Webhook サーバーで使用されるサーバー証明書に署名する PEM でエンコーディングされた CA 証明書です。
<ca_signing_certificate>
を base64 形式の適切な証明書に置き換えます。 - 9
- API サーバーがこの Webhook 受付プラグインを使用する必要があるタイミングを定義するルールです。
- 10
- API サーバーをトリガーしてこの Webhook 受付プラグインを呼び出す 1 つ以上の操作です。使用できる値は、
create
、update
、delete
、またはconnect
です。<operation>
および<resource>
を適切な値に置き換えます。 - 11
- Webhook サーバーが利用できない場合にポリシーを実行する方法を指定します。
<policy>
をIgnore
(失敗した場合に要求を無条件で受け入れる) またはFail
(失敗した要求を拒否する) のいずれかに置き換えます。Ignore
を使用すると、すべてのクライアントの予測できない動作が生じる可能性があります。
Red Hat OpenShift Service on AWS 4 では、ユーザーによって作成されるオブジェクト、または変更用の受付プラグインを使用するコントロールループは、初回の要求で設定される値が上書きされる場合などに予期しない結果を返す場合があるため、推奨されていません。
4.4.2. 受付プラグインの検証
検証用の受付 Webhook は受付プロセスの検証フェーズで起動します。このフェーズでは、特定 API リソースの変更がない項目の実施を可能にし、リソースが再び変更されないようにすることができます。Pod ノードセレクターは、すべての nodeSelector
フィールドが namespace のノードセレクターの制限の制約を受けるようにするために、検証用の受付プラグインによって呼び出される Webhook の一例です。
検証用の受付 Webhook 設定の例:
apiVersion: admissionregistration.k8s.io/v1beta1 kind: ValidatingWebhookConfiguration 1 metadata: name: <webhook_name> 2 webhooks: - name: <webhook_name> 3 clientConfig: 4 service: namespace: default 5 name: kubernetes 6 path: <webhook_url> 7 caBundle: <ca_signing_certificate> 8 rules: 9 - operations: 10 - <operation> apiGroups: - "" apiVersions: - "*" resources: - <resource> failurePolicy: <policy> 11 sideEffects: Unknown
- 1
- 検証用の受付 Webhook 設定を指定します。
- 2
ValidatingWebhookConfiguration
オブジェクトの名前。<webhook_name>
を適切な値に置き換えます。- 3
- 呼び出す Webhook の名前です。
<webhook_name>
を適切な値に置き換えます。 - 4
- Webhook サーバーに接続し、これを信頼し、データをこれに送信する方法についての情報です。
- 5
- フロントエンドサービスが作成される namespace です。
- 6
- フロントエンドサービスの名前です。
- 7
- 受付要求に使用される Webhook URL です。
<webhook_url>
を適切な値に置き換えます。 - 8
- Webhook サーバーで使用されるサーバー証明書に署名する PEM でエンコーディングされた CA 証明書です。
<ca_signing_certificate>
を base64 形式の適切な証明書に置き換えます。 - 9
- API サーバーがこの Webhook 受付プラグインを使用する必要があるタイミングを定義するルールです。
- 10
- API サーバーをトリガーしてこの Webhook 受付プラグインを呼び出す 1 つ以上の操作です。使用できる値は、
create
、update
、delete
、またはconnect
です。<operation>
および<resource>
を適切な値に置き換えます。 - 11
- Webhook サーバーが利用できない場合にポリシーを実行する方法を指定します。
<policy>
をIgnore
(失敗した場合に要求を無条件で受け入れる) またはFail
(失敗した要求を拒否する) のいずれかに置き換えます。Ignore
を使用すると、すべてのクライアントの予測できない動作が生じる可能性があります。
4.5. 関連情報
第5章 STS を使用する ROSA クラスターの IAM リソースについて
AWS Security Token Service (STS) を使用する Red Hat OpenShift Service on AWS (ROSA) クラスターをデプロイするには、以下の AWS Identity Access Management (IAM) リソースを作成する必要があります。
- ROSA サポート、インストール、コントロールプレーン、およびコンピュート機能に必要な STS パーミッションを提供する特定のアカウント全体の IAM ロールおよびポリシー。これには、アカウント全体の Operator ポリシーが含まれます。
- ROSA クラスター Operator がコア OpenShift 機能を実行できるようにするクラスター固有の Operator IAM ロール。
- クラスター Operator が認証に使用する OpenID Connect (OIDC) プロバイダー。
OpenShift Cluster Manager を使用して ROSA をデプロイする場合は、追加のリソースを作成する必要があります。
- クラスターへのインストールを完了するための OpenShift Cluster Manager IAM ロール。
- AWS アカウント ID を確認するための権限のないユーザーロール。
このドキュメントでは、STS を使用する ROSA クラスターの作成時にデプロイする必要のある IAM リソースについての参考情報を提供します。また、rosa create
コマンドで manual
モードを使用する場合に生成される aws
CLI コマンドも含まれます。
関連情報
- AWS IAM リソースを含む STS を使用して ROSA クラスターをすばやく作成するための詳細な手順は、デフォルトオプションを使用した STS を使用した ROSA クラスターの作成 を参照してください。
- AWS IAM リソースを含むカスタマイズを使用して STS で ROSA クラスターを作成する手順は、カスタマイズを使用して STS を使用する ROSA クラスターの作成 を参照してください。
5.1. OpenShift Cluster Manager のロールおよび権限
OpenShift Cluster Manager を使用して ROSA クラスターを作成する場合、以下の AWS IAM ロールを AWS アカウントにリンクしてクラスターを作成し、管理する必要があります。IAM ロールを AWS アカウントにリンクする方法は、AWS アカウントの関連付け を参照してください。
ROSA CLI (rosa
) ツールのみを使用する場合は、これらの IAM ロールを作成する必要がありません。
これらの AWS IAM ロールは以下のとおりです。
- ROSA ユーザーロールは、お客様の AWS アイデンティティーを検証するために使用する AWS ロールです。このロールには追加のパーミッションがなく、ロールには Red Hat インストーラーアカウントとの信頼関係があります。
ocm-role
リソースは、OpenShift Cluster Manager での ROSA クラスターのインストールに必要なパーミッションを付与します。基本的なパーミッションまたは管理パーミッションをocm-role
リソースに適用できます。管理用ocm-role
リソースを作成する場合、OpenShift Cluster Manager は必要な AWS Operator ロールと OpenID Connect (OIDC) プロバイダーを作成できます。この IAM ロールは、Red Hat インストーラーアカウントとも信頼関係を構築します。注記ocm-role
IAM リソースは、IAM ロールと、作成される必要なポリシーの組み合わせを指します。
OpenShift Cluster Manager で auto モードを使用して Operator ロールポリシーおよび OIDC プロバイダーを作成する場合は、このユーザーロールと管理 ocm-role
リソースを作成する必要があります。
5.1.1. OpenShift Cluster Manager ロールについて
OpenShift Cluster Manager で ROSA クラスターを作成するには、ocm-role
IAM ロールが必要です。基本的な ocm-role
IAM ロールのパーミッションにより、OpenShift Cluster Manager 内でクラスターのメンテナンスを実行できます。Operator ロールおよび OpenID Connect(OIDC) プロバイダーを自動的に作成するには、--admin
オプションを rosa create
コマンドに追加する必要があります。このコマンドは、管理タスクに必要な追加のパーミッションを持つ ocm-role
リソースを作成します。
この昇格された IAM ロールにより、OpenShift Cluster Manager はクラスターの作成時にクラスター固有の Operator ロールおよび OIDC プロバイダーを自動的に作成できるようになりました。このロールおよびポリシーの自動作成の詳細は、関連情報のアカウント全体のロールの作成方法リンクを参照してください。
5.1.1.1. ユーザーロールについて
ocm-role
IAM ロールのほかにも、Red Hat OpenShift Service on AWS が AWS アイデンティティーを検証できるようにユーザーロールを作成する必要があります。このロールにはパーミッションがなく、インストーラーアカウントと ocm-role
リソース間の信頼関係の作成にのみ使用されます。
以下の表は、ocm-role
リソースの関連付けられた基本および管理パーミッションを示しています。
表5.1 基本的な ocm-role
リソースの関連パーミッション
リソース | 説明 |
---|---|
| この権限により、基本ロールは指定された OpenID Connect (OIDC) プロバイダーに関する情報を取得できます。 |
| このパーミッションにより、基本ロールは指定されたロールの情報を取得できます。返されるデータには、ロールのパス、GUID、ARN、およびロールを想定するパーミッションを付与するロールの信頼ポリシーが含まれます。 |
| このパーミッションにより、基本ロールはパス接頭辞内のロールをリスト表示できます。 |
| このパーミッションにより、基本ロールは指定されたロールのタグをリスト表示できます。 |
| このパーミッションにより、基本ロールはアカウントの有効なすべてのリージョンに関する情報を返すことができます。 |
| このパーミッションにより、基本ロールはすべてのルートテーブルに関する情報を返すことができます。 |
| このパーミッションにより、基本ロールはすべてのサブネットに関する情報を返すことができます。 |
| このパーミッションにより、基本ロールは仮想プライベートクラウド (VPC) に関する情報を返すことができます。 |
| このパーミッションにより、基本ロールは一時的なセキュリティー認証情報を取得して、通常のパーミッション以外の AWS リソースにアクセスできます。 |
| このパーミッションにより、基本ロールは web アイデンティティープロバイダーでアカウントを認証されたユーザーの一時的なセキュリティー認証情報を取得できます。 |
表5.2 admin ocm-role
リソースの追加パーミッション
リソース | 説明 |
---|---|
| このパーミッションにより、admin ロールは指定されたポリシーを必要な IAM ロールに割り当てることができます。 |
| この権限は、OpenID Connect (OIDC) をサポートする ID プロバイダーを説明するリソースを作成します。このパーミッションで OIDC プロバイダーを作成すると、このプロバイダーはプロバイダーと AWS 間の信頼関係を確立します。 |
| このパーミッションにより、admin ロールは AWS アカウントのロールを作成できます。 |
| このパーミッションにより、admin ロールは AWS アカウントに関連付けられたポリシーをリスト表示できます。 |
| このパーミッションにより、admin ロールは指定されたポリシーのタグをリスト表示できます。 |
| このパーミッションにより、admin ロールは指定されたポリシーに基づいてユーザーのパーミッション境界を変更できます。 |
| このパーミッションにより、admin ロールは IAM ロールにタグを追加できます。 |
関連情報
ocm-role IAM ロールの作成
ocm-role
IAM ロールは、コマンドラインインターフェイス (CLI) を使用して作成します。
前提条件
- AWS アカウントがある。
- OpenShift Cluster Manager 組織で Red Hat 組織管理者特権がある。
- AWS アカウント全体のロールをインストールするために必要な権限がある。
-
インストールホストに、最新の Red Hat OpenShift Service on AWS (ROSA) CLI (
rosa
) をインストールして設定している。
手順
基本的な権限を持つ ocm-role IAM ロールを作成するには、次のコマンドを実行します。
$ rosa create ocm-role
管理者権限を持つ ocm-role IAM ロールを作成するには、次のコマンドを実行します。
$ rosa create ocm-role --admin
このコマンドを使用すると、特定の属性を指定してロールを作成できます。次の出力例は、選択された自動モードを示しています。これにより、ROSA CLI (
rosa
) で Operator のロールとポリシーを作成できます。詳細は、関連情報に記載されているアカウント全体のロールの作成方法を参照してください。
出力例
I: Creating ocm role ? Role prefix: ManagedOpenShift 1 ? Enable admin capabilities for the OCM role (optional): No 2 ? Permissions boundary ARN (optional): 3 ? Role Path (optional): 4 ? Role creation mode: auto 5 I: Creating role using 'arn:aws:iam::<ARN>:user/<UserName>' ? Create the 'ManagedOpenShift-OCM-Role-182' role? Yes 6 I: Created role 'ManagedOpenShift-OCM-Role-182' with ARN 'arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182' I: Linking OCM role ? OCM Role ARN: arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182 7 ? Link the 'arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182' role with organization '<AWS ARN>'? Yes 8 I: Successfully linked role-arn 'arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182' with organization account '<AWS ARN>'
- 1
- 作成されたすべての AWS リソースの接頭辞値。この例では、
ManagedOpenShift
がすべての AWS リソースを付加します。 - 2
- このロールに追加の管理者権限を付与するかどうかを選択します。注記
--admin
オプションを使用した場合、このプロンプトは表示されません。 - 3
- パーミッション境界を設定するためのポリシーの Amazon Resource Name (ARN)。
- 4
- ユーザー名の IAM パスを指定します。
- 5
- AWS ロールの作成方法を選択します。
auto
を使用して、ROSA CLI はロールおよびポリシーを生成してリンクします。auto
モードでは、AWS ロールを作成するためのいくつかの異なるプロンプトが表示されます。 - 6
auto
メソッドは、接頭辞を使用して特定のocm-role
を作成するかどうかを尋ねます。- 7
- IAM ロールを OpenShift Cluster Manager に関連付けることを確認します。
- 8
- 作成したロールを AWS 組織にリンクします。
AWS IAM ロールは AWS アカウントにリンクして、クラスターを作成および管理します。IAM ロールを AWS アカウントにリンクする方法は、AWS アカウントの関連付け を参照してください。
5.2. アカウント全体の IAM ロールおよびポリシー参照
このセクションでは、Operator ポリシーを含む、STS を使用する ROSA デプロイメントに必要なアカウント全体の IAM ロールおよびポリシーに関する詳細を提供します。また、ポリシーを定義する JSON ファイルも含まれます。
アカウント全体のロールおよびポリシーは、OpenShift マイナーリリースバージョン (OpenShift 4.15 など) に固有のものであり、後方互換性があります。パッチバージョンに関係なく、同じマイナーバージョンの複数のクラスターにアカウント全体のロールおよびポリシーを再利用することで、必要な STS リソースを最小限に抑えることができます。
5.2.1. アカウント全体のロールを作成する方法
Red Hat OpenShift Service on AWS (ROSA) CLI、rosa
、または OpenShift Cluster Manager のガイド付きインストールを使用して、アカウント全体のロールを作成できます。手動で、またはこれらのロールおよびポリシーに事前定義された名前を使用する自動プロセスを使用して、ロールを作成できます。
手動 ocm-role リソースの作成
システムでこれらのロールを作成するのに必要な CLI アクセスがある場合は、手動作成方法を使用できます。このオプションは、目的の CLI ツールまたは OpenShift Cluster Manager から実行できます。手動作成プロセスを開始すると、CLI は、ロールを作成して必要なポリシーにリンクする一連のコマンドを実行するために表示します。
自動 ocm-role リソースの作成
管理者権限で ocm-role
リソースを作成した場合は、OpenShift Cluster Manager からの自動作成方法を使用できます。ROSA CLI では、これらのロールとポリシーを自動的に作成するために、この管理 ocm-role
IAM リソースが必要です。この方法を選択すると、デフォルト名を使用するロールおよびポリシーが作成されます。
OpenShift Cluster Manager で ROSA ガイド付きインストールを使用する場合は、ガイド付きクラスターインストールの最初のステップで、管理者権限を持つ ocm-role
リソースを作成しておく必要があります。このロールがないと、Operator ロールおよびポリシーの自動作成オプションを使用できませんが、クラスターと、そのロールおよびポリシーを手動プロセスで作成することはできます。
sts_installer_trust_policy.json
および sts_support_trust_policy.json
サンプルに存在するアカウント番号は、必要なロールを引き受けることが許可されている Red Hat アカウントを表します。
表5.3 ROSA インストーラーロール、ポリシー、およびポリシーファイル
リソース | 説明 |
---|---|
| ROSA インストーラーによって使用される IAM ロール。 |
| クラスターのインストールタスクを完了するのに必要なパーミッションを持つ ROSA インストーラーを提供する IAM ポリシー。 |
例5.1 sts_installer_trust_policy.json
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::710019948333:role/RH-Managed-OpenShift-Installer" ] }, "Action": [ "sts:AssumeRole" ] } ] }
例5.2 sts_installer_permission_policy.json
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "autoscaling:DescribeAutoScalingGroups", "ec2:AllocateAddress", "ec2:AssociateAddress", "ec2:AssociateDhcpOptions", "ec2:AssociateRouteTable", "ec2:AttachInternetGateway", "ec2:AttachNetworkInterface", "ec2:AuthorizeSecurityGroupEgress", "ec2:AuthorizeSecurityGroupIngress", "ec2:CopyImage", "ec2:CreateDhcpOptions", "ec2:CreateInternetGateway", "ec2:CreateNatGateway", "ec2:CreateNetworkInterface", "ec2:CreateRoute", "ec2:CreateRouteTable", "ec2:CreateSecurityGroup", "ec2:CreateSubnet", "ec2:CreateTags", "ec2:CreateVolume", "ec2:CreateVpc", "ec2:CreateVpcEndpoint", "ec2:DeleteDhcpOptions", "ec2:DeleteInternetGateway", "ec2:DeleteNatGateway", "ec2:DeleteNetworkInterface", "ec2:DeleteRoute", "ec2:DeleteRouteTable", "ec2:DeleteSecurityGroup", "ec2:DeleteSnapshot", "ec2:DeleteSubnet", "ec2:DeleteTags", "ec2:DeleteVolume", "ec2:DeleteVpc", "ec2:DeleteVpcEndpoints", "ec2:DeregisterImage", "ec2:DescribeAccountAttributes", "ec2:DescribeAddresses", "ec2:DescribeAvailabilityZones", "ec2:DescribeDhcpOptions", "ec2:DescribeImages", "ec2:DescribeInstanceAttribute", "ec2:DescribeInstanceCreditSpecifications", "ec2:DescribeInstances", "ec2:DescribeInstanceStatus", "ec2:DescribeInstanceTypeOfferings", "ec2:DescribeInstanceTypes", "ec2:DescribeInternetGateways", "ec2:DescribeKeyPairs", "ec2:DescribeNatGateways", "ec2:DescribeNetworkAcls", "ec2:DescribeNetworkInterfaces", "ec2:DescribePrefixLists", "ec2:DescribeRegions", "ec2:DescribeReservedInstancesOfferings", "ec2:DescribeRouteTables", "ec2:DescribeSecurityGroups", "ec2:DescribeSecurityGroupRules", "ec2:DescribeSubnets", "ec2:DescribeTags", "ec2:DescribeVolumes", "ec2:DescribeVpcAttribute", "ec2:DescribeVpcClassicLink", "ec2:DescribeVpcClassicLinkDnsSupport", "ec2:DescribeVpcEndpoints", "ec2:DescribeVpcs", "ec2:DetachInternetGateway", "ec2:DisassociateRouteTable", "ec2:GetConsoleOutput", "ec2:GetEbsDefaultKmsKeyId", "ec2:ModifyInstanceAttribute", "ec2:ModifyNetworkInterfaceAttribute", "ec2:ModifySubnetAttribute", "ec2:ModifyVpcAttribute", "ec2:ReleaseAddress", "ec2:ReplaceRouteTableAssociation", "ec2:RevokeSecurityGroupEgress", "ec2:RevokeSecurityGroupIngress", "ec2:RunInstances", "ec2:StartInstances", "ec2:StopInstances", "ec2:TerminateInstances", "elasticloadbalancing:AddTags", "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer", "elasticloadbalancing:AttachLoadBalancerToSubnets", "elasticloadbalancing:ConfigureHealthCheck", "elasticloadbalancing:CreateListener", "elasticloadbalancing:CreateLoadBalancer", "elasticloadbalancing:CreateLoadBalancerListeners", "elasticloadbalancing:CreateTargetGroup", "elasticloadbalancing:DeleteLoadBalancer", "elasticloadbalancing:DeleteTargetGroup", "elasticloadbalancing:DeregisterInstancesFromLoadBalancer", "elasticloadbalancing:DeregisterTargets", "elasticloadbalancing:DescribeAccountLimits", "elasticloadbalancing:DescribeInstanceHealth", "elasticloadbalancing:DescribeListeners", "elasticloadbalancing:DescribeLoadBalancerAttributes", "elasticloadbalancing:DescribeLoadBalancers", "elasticloadbalancing:DescribeTags", "elasticloadbalancing:DescribeTargetGroupAttributes", "elasticloadbalancing:DescribeTargetGroups", "elasticloadbalancing:DescribeTargetHealth", "elasticloadbalancing:ModifyLoadBalancerAttributes", "elasticloadbalancing:ModifyTargetGroup", "elasticloadbalancing:ModifyTargetGroupAttributes", "elasticloadbalancing:RegisterInstancesWithLoadBalancer", "elasticloadbalancing:RegisterTargets", "elasticloadbalancing:SetLoadBalancerPoliciesOfListener", "iam:AddRoleToInstanceProfile", "iam:CreateInstanceProfile", "iam:DeleteInstanceProfile", "iam:GetInstanceProfile", "iam:TagInstanceProfile", "iam:GetRole", "iam:GetRolePolicy", "iam:GetUser", "iam:ListAttachedRolePolicies", "iam:ListInstanceProfiles", "iam:ListInstanceProfilesForRole", "iam:ListRolePolicies", "iam:ListRoles", "iam:ListUserPolicies", "iam:ListUsers", "iam:PassRole", "iam:RemoveRoleFromInstanceProfile", "iam:SimulatePrincipalPolicy", "iam:TagRole", "iam:UntagRole", "route53:ChangeResourceRecordSets", "route53:ChangeTagsForResource", "route53:CreateHostedZone", "route53:DeleteHostedZone", "route53:GetAccountLimit", "route53:GetChange", "route53:GetHostedZone", "route53:ListHostedZones", "route53:ListHostedZonesByName", "route53:ListResourceRecordSets", "route53:ListTagsForResource", "route53:UpdateHostedZoneComment", "s3:CreateBucket", "s3:DeleteBucket", "s3:DeleteObject", "s3:DeleteObjectVersion", "s3:GetAccelerateConfiguration", "s3:GetBucketAcl", "s3:GetBucketCORS", "s3:GetBucketLocation", "s3:GetBucketLogging", "s3:GetBucketObjectLockConfiguration", "s3:GetBucketPolicy", "s3:GetBucketRequestPayment", "s3:GetBucketTagging", "s3:GetBucketVersioning", "s3:GetBucketWebsite", "s3:GetEncryptionConfiguration", "s3:GetLifecycleConfiguration", "s3:GetObject", "s3:GetObjectAcl", "s3:GetObjectTagging", "s3:GetObjectVersion", "s3:GetReplicationConfiguration", "s3:ListBucket", "s3:ListBucketVersions", "s3:PutBucketAcl", "s3:PutBucketTagging", "s3:PutBucketVersioning", "s3:PutEncryptionConfiguration", "s3:PutObject", "s3:PutObjectAcl", "s3:PutObjectTagging", "servicequotas:GetServiceQuota", "servicequotas:ListAWSDefaultServiceQuotas", "sts:AssumeRole", "sts:AssumeRoleWithWebIdentity", "sts:GetCallerIdentity", "tag:GetResources", "tag:UntagResources", "ec2:CreateVpcEndpointServiceConfiguration", "ec2:DeleteVpcEndpointServiceConfigurations", "ec2:DescribeVpcEndpointServiceConfigurations", "ec2:DescribeVpcEndpointServicePermissions", "ec2:DescribeVpcEndpointServices", "ec2:ModifyVpcEndpointServicePermissions", "kms:DescribeKey", "cloudwatch:GetMetricData" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue" ], "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceTag/red-hat-managed": "true" } } } ] }
表5.4 ROSA コントロールプレーンのロール、ポリシー、およびポリシーファイル
リソース | 説明 |
---|---|
| ROSA コントロールプレーンによって使用される IAM ロール。 |
| コンポーネントの管理に必要なパーミッションを持つ ROSA コントロールプレーンを提供する IAM ポリシー。 |
例5.3 sts_instance_controlplane_trust_policy.json
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "ec2.amazonaws.com" ] }, "Action": [ "sts:AssumeRole" ] } ] }
例5.4 sts_instance_controlplane_permission_policy.json
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:AttachVolume", "ec2:AuthorizeSecurityGroupIngress", "ec2:CreateSecurityGroup", "ec2:CreateTags", "ec2:CreateVolume", "ec2:DeleteSecurityGroup", "ec2:DeleteVolume", "ec2:Describe*", "ec2:DetachVolume", "ec2:ModifyInstanceAttribute", "ec2:ModifyVolume", "ec2:RevokeSecurityGroupIngress", "elasticloadbalancing:AddTags", "elasticloadbalancing:AttachLoadBalancerToSubnets", "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer", "elasticloadbalancing:CreateListener", "elasticloadbalancing:CreateLoadBalancer", "elasticloadbalancing:CreateLoadBalancerPolicy", "elasticloadbalancing:CreateLoadBalancerListeners", "elasticloadbalancing:CreateTargetGroup", "elasticloadbalancing:ConfigureHealthCheck", "elasticloadbalancing:DeleteListener", "elasticloadbalancing:DeleteLoadBalancer", "elasticloadbalancing:DeleteLoadBalancerListeners", "elasticloadbalancing:DeleteTargetGroup", "elasticloadbalancing:DeregisterInstancesFromLoadBalancer", "elasticloadbalancing:DeregisterTargets", "elasticloadbalancing:Describe*", "elasticloadbalancing:DetachLoadBalancerFromSubnets", "elasticloadbalancing:ModifyListener", "elasticloadbalancing:ModifyLoadBalancerAttributes", "elasticloadbalancing:ModifyTargetGroup", "elasticloadbalancing:ModifyTargetGroupAttributes", "elasticloadbalancing:RegisterInstancesWithLoadBalancer", "elasticloadbalancing:RegisterTargets", "elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer", "elasticloadbalancing:SetLoadBalancerPoliciesOfListener", "kms:DescribeKey" ], "Resource": "*" } ] }
表5.5 ROSA コンピュートノードロール、ポリシー、およびポリシーファイル
リソース | 説明 |
---|---|
| ROSA コンピュートインスタンスによって使用される IAM ロール。 |
| コンポーネントの管理に必要なパーミッションを持つ ROSA コンピュートインスタンスを提供する IAM ポリシー。 |
例5.5 sts_instance_worker_trust_policy.json
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "ec2.amazonaws.com" ] }, "Action": [ "sts:AssumeRole" ] } ] }
例5.6 sts_instance_worker_permission_policy.json
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:DescribeInstances" "ec2:DescribeRegions" ], "Resource": "*" } ] }
表5.6 ROSA サポートロール、ポリシー、およびポリシーファイル
リソース | 説明 |
---|---|
| Red Hat Site Reliability Engineering (SRE) サポートチームによって使用される IAM ロール。 |
| ROSA クラスターをサポートするために必要なパーミッションを持つ Red Hat SRE サポートチームを提供する IAM ポリシー。 |
例5.7 sts_support_trust_policy.json
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::710019948333:role/RH-Technical-Support-Access" ] }, "Action": [ "sts:AssumeRole" ] } ] }
例5.8 sts_support_permission_policy.json
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "cloudtrail:DescribeTrails", "cloudtrail:LookupEvents", "cloudwatch:GetMetricData", "cloudwatch:GetMetricStatistics", "cloudwatch:ListMetrics", "ec2-instance-connect:SendSerialConsoleSSHPublicKey", "ec2:CopySnapshot", "ec2:CreateNetworkInsightsPath", "ec2:CreateSnapshot", "ec2:CreateSnapshots", "ec2:CreateTags", "ec2:DeleteNetworkInsightsAnalysis", "ec2:DeleteNetworkInsightsPath", "ec2:DeleteTags", "ec2:DescribeAccountAttributes", "ec2:DescribeAddresses", "ec2:DescribeAddressesAttribute", "ec2:DescribeAggregateIdFormat", "ec2:DescribeAvailabilityZones", "ec2:DescribeByoipCidrs", "ec2:DescribeCapacityReservations", "ec2:DescribeCarrierGateways", "ec2:DescribeClassicLinkInstances", "ec2:DescribeClientVpnAuthorizationRules", "ec2:DescribeClientVpnConnections", "ec2:DescribeClientVpnEndpoints", "ec2:DescribeClientVpnRoutes", "ec2:DescribeClientVpnTargetNetworks", "ec2:DescribeCoipPools", "ec2:DescribeCustomerGateways", "ec2:DescribeDhcpOptions", "ec2:DescribeEgressOnlyInternetGateways", "ec2:DescribeIamInstanceProfileAssociations", "ec2:DescribeIdentityIdFormat", "ec2:DescribeIdFormat", "ec2:DescribeImageAttribute", "ec2:DescribeImages", "ec2:DescribeInstanceAttribute", "ec2:DescribeInstances", "ec2:DescribeInstanceStatus", "ec2:DescribeInstanceTypeOfferings", "ec2:DescribeInstanceTypes", "ec2:DescribeInternetGateways", "ec2:DescribeIpv6Pools", "ec2:DescribeKeyPairs", "ec2:DescribeLaunchTemplates", "ec2:DescribeLocalGatewayRouteTables", "ec2:DescribeLocalGatewayRouteTableVirtualInterfaceGroupAssociations", "ec2:DescribeLocalGatewayRouteTableVpcAssociations", "ec2:DescribeLocalGateways", "ec2:DescribeLocalGatewayVirtualInterfaceGroups", "ec2:DescribeLocalGatewayVirtualInterfaces", "ec2:DescribeManagedPrefixLists", "ec2:DescribeNatGateways", "ec2:DescribeNetworkAcls", "ec2:DescribeNetworkInsightsAnalyses", "ec2:DescribeNetworkInsightsPaths", "ec2:DescribeNetworkInterfaces", "ec2:DescribePlacementGroups", "ec2:DescribePrefixLists", "ec2:DescribePrincipalIdFormat", "ec2:DescribePublicIpv4Pools", "ec2:DescribeRegions", "ec2:DescribeReservedInstances", "ec2:DescribeRouteTables", "ec2:DescribeScheduledInstances", "ec2:DescribeSecurityGroupReferences", "ec2:DescribeSecurityGroupRules", "ec2:DescribeSecurityGroups", "ec2:DescribeSnapshotAttribute", "ec2:DescribeSnapshots", "ec2:DescribeSpotFleetInstances", "ec2:DescribeStaleSecurityGroups", "ec2:DescribeSubnets", "ec2:DescribeTags", "ec2:DescribeTransitGatewayAttachments", "ec2:DescribeTransitGatewayConnectPeers", "ec2:DescribeTransitGatewayConnects", "ec2:DescribeTransitGatewayMulticastDomains", "ec2:DescribeTransitGatewayPeeringAttachments", "ec2:DescribeTransitGatewayRouteTables", "ec2:DescribeTransitGateways", "ec2:DescribeTransitGatewayVpcAttachments", "ec2:DescribeVolumeAttribute", "ec2:DescribeVolumeStatus", "ec2:DescribeVolumes", "ec2:DescribeVolumesModifications", "ec2:DescribeVpcAttribute", "ec2:DescribeVpcClassicLink", "ec2:DescribeVpcClassicLinkDnsSupport", "ec2:DescribeVpcEndpointConnectionNotifications", "ec2:DescribeVpcEndpointConnections", "ec2:DescribeVpcEndpointServiceConfigurations", "ec2:DescribeVpcEndpointServicePermissions", "ec2:DescribeVpcEndpointServices", "ec2:DescribeVpcEndpoints", "ec2:DescribeVpcPeeringConnections", "ec2:DescribeVpcs", "ec2:DescribeVpnConnections", "ec2:DescribeVpnGateways", "ec2:GetAssociatedIpv6PoolCidrs", "ec2:GetConsoleOutput", "ec2:GetManagedPrefixListEntries", "ec2:GetSerialConsoleAccessStatus", "ec2:GetTransitGatewayAttachmentPropagations", "ec2:GetTransitGatewayMulticastDomainAssociations", "ec2:GetTransitGatewayPrefixListReferences", "ec2:GetTransitGatewayRouteTableAssociations", "ec2:GetTransitGatewayRouteTablePropagations", "ec2:ModifyInstanceAttribute", "ec2:RebootInstances", "ec2:RunInstances", "ec2:SearchLocalGatewayRoutes", "ec2:SearchTransitGatewayMulticastGroups", "ec2:SearchTransitGatewayRoutes", "ec2:StartInstances", "ec2:StartNetworkInsightsAnalysis", "ec2:StopInstances", "ec2:TerminateInstances", "elasticloadbalancing:ConfigureHealthCheck", "elasticloadbalancing:DescribeAccountLimits", "elasticloadbalancing:DescribeInstanceHealth", "elasticloadbalancing:DescribeListenerCertificates", "elasticloadbalancing:DescribeListeners", "elasticloadbalancing:DescribeLoadBalancerAttributes", "elasticloadbalancing:DescribeLoadBalancerPolicies", "elasticloadbalancing:DescribeLoadBalancerPolicyTypes", "elasticloadbalancing:DescribeLoadBalancers", "elasticloadbalancing:DescribeRules", "elasticloadbalancing:DescribeSSLPolicies", "elasticloadbalancing:DescribeTags", "elasticloadbalancing:DescribeTargetGroupAttributes", "elasticloadbalancing:DescribeTargetGroups", "elasticloadbalancing:DescribeTargetHealth", "iam:GetRole", "iam:ListRoles", "kms:CreateGrant", "route53:GetHostedZone", "route53:GetHostedZoneCount", "route53:ListHostedZones", "route53:ListHostedZonesByName", "route53:ListResourceRecordSets", "s3:GetBucketTagging", "s3:GetObjectAcl", "s3:GetObjectTagging", "s3:ListAllMyBuckets" "sts:DecodeAuthorizationMessage", "tiros:CreateQuery", "tiros:GetQueryAnswer", "tiros:GetQueryExplanation" ], "Resource": "*" }, { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": [ "arn:aws:s3:::managed-velero*", "arn:aws:s3:::*image-registry*" ] } ] }
表5.7 ROSA Ingress Operator IAM ポリシーおよびポリシーファイル
リソース | 説明 |
---|---|
| クラスターへの外部アクセスを管理するために必要なパーミッションを持つ ROSA Ingress Operator を提供する IAM ポリシー。 |
例5.9 openshift_ingress_operator_cloud_credentials_policy.json
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "elasticloadbalancing:DescribeLoadBalancers", "route53:ListHostedZones", "route53:ChangeResourceRecordSets", "tag:GetResources" ], "Resource": "*" } ] }
表5.8 ROSA バックエンドストレージ IAM ポリシーおよびポリシーファイル
リソース | 説明 |
---|---|
| Container Storage Interface (CSI) でバックエンドストレージを管理するのに ROSA が必要とする IAM ポリシー。 |
例5.10 openshift_cluster_csi_drivers_ebs_cloud_credentials_policy.json
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:AttachVolume", "ec2:CreateSnapshot", "ec2:CreateTags", "ec2:CreateVolume", "ec2:DeleteSnapshot", "ec2:DeleteTags", "ec2:DeleteVolume", "ec2:DescribeInstances", "ec2:DescribeSnapshots", "ec2:DescribeTags", "ec2:DescribeVolumes", "ec2:DescribeVolumesModifications", "ec2:DetachVolume", "ec2:ModifyVolume" ], "Resource": "*" } ] }
表5.9 ROSA Machine Config Operator ポリシーおよびポリシーファイル
リソース | 説明 |
---|---|
| コアクラスター機能の実行に必要なパーミッションと共に ROSA Machine Config Operator を提供する IAM ポリシー。 |
例5.11 openshift_machine_api_aws_cloud_credentials_policy.json
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:CreateTags", "ec2:DescribeAvailabilityZones", "ec2:DescribeDhcpOptions", "ec2:DescribeImages", "ec2:DescribeInstances", "ec2:DescribeInternetGateways", "ec2:DescribeSecurityGroups", "ec2:DescribeSubnets", "ec2:DescribeVpcs", "ec2:RunInstances", "ec2:TerminateInstances", "elasticloadbalancing:DescribeLoadBalancers", "elasticloadbalancing:DescribeTargetGroups", "elasticloadbalancing:DescribeTargetHealth", "elasticloadbalancing:RegisterInstancesWithLoadBalancer", "elasticloadbalancing:RegisterTargets", "elasticloadbalancing:DeregisterTargets", "iam:PassRole", "iam:CreateServiceLinkedRole" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:Encrypt", "kms:GenerateDataKey", "kms:GenerateDataKeyWithoutPlainText", "kms:DescribeKey" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "kms:RevokeGrant", "kms:CreateGrant", "kms:ListGrants" ], "Resource": "*", "Condition": { "Bool": { "kms:GrantIsForAWSResource": true } } } ] }
表5.10 ROSA Cloud Credential Operator ポリシーおよびポリシーファイル
リソース | 説明 |
---|---|
| クラウドプロバイダーの認証情報の管理に必要なパーミッションと共に ROSA Cloud Credential Operator を提供する IAM ポリシー。 |
例5.12 openshift_cloud_credential_operator_cloud_credential_operator_iam_ro_creds_policy.json
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:GetUser", "iam:GetUserPolicy", "iam:ListAccessKeys" ], "Resource": "*" } ] }
表5.11 ROSA Image Registry Operator ポリシーおよびポリシーファイル
リソース | 説明 |
---|---|
| クラスターの AWS S3 で OpenShift イメージレジストリーストレージを管理するために必要なパーミッションを持つ ROSA イメージレジストリー Operator を提供する IAM ポリシー。 |
例5.13 openshift_image_registry_installer_cloud_credentials_policy.json
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:CreateBucket", "s3:DeleteBucket", "s3:PutBucketTagging", "s3:GetBucketTagging", "s3:PutBucketPublicAccessBlock", "s3:GetBucketPublicAccessBlock", "s3:PutEncryptionConfiguration", "s3:GetEncryptionConfiguration", "s3:PutLifecycleConfiguration", "s3:GetLifecycleConfiguration", "s3:GetBucketLocation", "s3:ListBucket", "s3:GetObject", "s3:PutObject", "s3:DeleteObject", "s3:ListBucketMultipartUploads", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts" ], "Resource": "*" } ] }
関連情報
- OpenShift のメジャー、マイナー、およびパッチバージョンの定義は、Red Hat OpenShift Service on AWS の更新ライフサイクル を参照してください。
5.2.2. アカウント全体の IAM ロールおよびポリシー AWS CLI リファレンス
このセクションでは、rosa
コマンドが端末で生成する aws
CLI コマンドをリスト表示します。コマンドは、手動モードまたは自動モードのいずれかで実行できます。
アカウントロールの作成に手動モードを使用する
手動のロール作成モードでは、確認して実行するための aws
コマンドが生成されます。このプロセスは次のコマンドで開始します。<openshift_version>
は、Red Hat OpenShift Service on AWS (ROSA) のバージョン (4.15
など) を指します。
$ rosa create account-roles --mode manual
提供されているコマンドの例には、ManagedOpenShift
接頭辞が含まれています。--prefix
オプションを使用してカスタム接頭辞を指定しない場合は、ManagedOpenShift
接頭辞がデフォルト値です。
コマンド出力
aws iam create-role \ --role-name ManagedOpenShift-Installer-Role \ --assume-role-policy-document file://sts_installer_trust_policy.json \ --tags Key=rosa_openshift_version,Value=<openshift_version> Key=rosa_role_prefix,Value=ManagedOpenShift Key=rosa_role_type,Value=installer aws iam put-role-policy \ --role-name ManagedOpenShift-Installer-Role \ --policy-name ManagedOpenShift-Installer-Role-Policy \ --policy-document file://sts_installer_permission_policy.json aws iam create-role \ --role-name ManagedOpenShift-ControlPlane-Role \ --assume-role-policy-document file://sts_instance_controlplane_trust_policy.json \ --tags Key=rosa_openshift_version,Value=<openshift_version> Key=rosa_role_prefix,Value=ManagedOpenShift Key=rosa_role_type,Value=instance_controlplane aws iam put-role-policy \ --role-name ManagedOpenShift-ControlPlane-Role \ --policy-name ManagedOpenShift-ControlPlane-Role-Policy \ --policy-document file://sts_instance_controlplane_permission_policy.json aws iam create-role \ --role-name ManagedOpenShift-Worker-Role \ --assume-role-policy-document file://sts_instance_worker_trust_policy.json \ --tags Key=rosa_openshift_version,Value=<openshift_version> Key=rosa_role_prefix,Value=ManagedOpenShift Key=rosa_role_type,Value=instance_worker aws iam put-role-policy \ --role-name ManagedOpenShift-Worker-Role \ --policy-name ManagedOpenShift-Worker-Role-Policy \ --policy-document file://sts_instance_worker_permission_policy.json aws iam create-role \ --role-name ManagedOpenShift-Support-Role \ --assume-role-policy-document file://sts_support_trust_policy.json \ --tags Key=rosa_openshift_version,Value=<openshift_version> Key=rosa_role_prefix,Value=ManagedOpenShift Key=rosa_role_type,Value=support aws iam put-role-policy \ --role-name ManagedOpenShift-Support-Role \ --policy-name ManagedOpenShift-Support-Role-Policy \ --policy-document file://sts_support_permission_policy.json aws iam create-policy \ --policy-name ManagedOpenShift-openshift-ingress-operator-cloud-credentials \ --policy-document file://openshift_ingress_operator_cloud_credentials_policy.json \ --tags Key=rosa_openshift_version,Value=<openshift_version> Key=rosa_role_prefix,Value=ManagedOpenShift Key=operator_namespace,Value=openshift-ingress-operator Key=operator_name,Value=cloud-credentials aws iam create-policy \ --policy-name ManagedOpenShift-openshift-cluster-csi-drivers-ebs-cloud-credent \ --policy-document file://openshift_cluster_csi_drivers_ebs_cloud_credentials_policy.json \ --tags Key=rosa_openshift_version,Value=<openshift_version> Key=rosa_role_prefix,Value=ManagedOpenShift Key=operator_namespace,Value=openshift-cluster-csi-drivers Key=operator_name,Value=ebs-cloud-credentials aws iam create-policy \ --policy-name ManagedOpenShift-openshift-machine-api-aws-cloud-credentials \ --policy-document file://openshift_machine_api_aws_cloud_credentials_policy.json \ --tags Key=rosa_openshift_version,Value=<openshift_version> Key=rosa_role_prefix,Value=ManagedOpenShift Key=operator_namespace,Value=openshift-machine-api Key=operator_name,Value=aws-cloud-credentials aws iam create-policy \ --policy-name ManagedOpenShift-openshift-cloud-credential-operator-cloud-crede \ --policy-document file://openshift_cloud_credential_operator_cloud_credential_operator_iam_ro_creds_policy.json \ --tags Key=rosa_openshift_version,Value=<openshift_version> Key=rosa_role_prefix,Value=ManagedOpenShift Key=operator_namespace,Value=openshift-cloud-credential-operator Key=operator_name,Value=cloud-credential-operator-iam-ro-creds aws iam create-policy \ --policy-name ManagedOpenShift-openshift-image-registry-installer-cloud-creden \ --policy-document file://openshift_image_registry_installer_cloud_credentials_policy.json \ --tags Key=rosa_openshift_version,Value=<openshift_version> Key=rosa_role_prefix,Value=ManagedOpenShift Key=operator_namespace,Value=openshift-image-registry Key=operator_name,Value=installer-cloud-credentials
ロール作成に自動モードを使用する
--mode auto
引数を追加すると、Red Hat OpenShift Service on AWS (ROSA) CLI (rosa
) はロールとポリシーを作成します。次のコマンドは、そのプロセスを開始します。
$ rosa create account-roles --mode auto
提供されているコマンドの例には、ManagedOpenShift
接頭辞が含まれています。--prefix
オプションを使用してカスタム接頭辞を指定しない場合は、ManagedOpenShift
接頭辞がデフォルト値です。
コマンド出力
I: Creating roles using 'arn:aws:iam::<ARN>:user/<UserID>' ? Create the 'ManagedOpenShift-Installer-Role' role? Yes I: Created role 'ManagedOpenShift-Installer-Role' with ARN 'arn:aws:iam::<ARN>:role/ManagedOpenShift-Installer-Role' ? Create the 'ManagedOpenShift-ControlPlane-Role' role? Yes I: Created role 'ManagedOpenShift-ControlPlane-Role' with ARN 'arn:aws:iam::<ARN>:role/ManagedOpenShift-ControlPlane-Role' ? Create the 'ManagedOpenShift-Worker-Role' role? Yes I: Created role 'ManagedOpenShift-Worker-Role' with ARN 'arn:aws:iam::<ARN>:role/ManagedOpenShift-Worker-Role' ? Create the 'ManagedOpenShift-Support-Role' role? Yes I: Created role 'ManagedOpenShift-Support-Role' with ARN 'arn:aws:iam::<ARN>:role/ManagedOpenShift-Support-Role' ? Create the operator policies? Yes I: Created policy with ARN 'arn:aws:iam::<ARN>:policy/ManagedOpenShift-openshift-machine-api-aws-cloud-credentials' I: Created policy with ARN 'arn:aws:iam::<ARN>:policy/ManagedOpenShift-openshift-cloud-credential-operator-cloud-crede' I: Created policy with ARN 'arn:aws:iam::<ARN>:policy/ManagedOpenShift-openshift-image-registry-installer-cloud-creden' I: Created policy with ARN 'arn:aws:iam::<ARN>:policy/ManagedOpenShift-openshift-ingress-operator-cloud-credentials' I: Created policy with ARN 'arn:aws:iam::<ARN>:policy/ManagedOpenShift-openshift-cluster-csi-drivers-ebs-cloud-credent' I: Created policy with ARN 'arn:aws:iam::<ARN>:policy/ManagedOpenShift-openshift-cloud-network-config-controller-cloud' I: To create a cluster with these roles, run the following command: rosa create cluster --sts
5.3. クラスター固有の Operator IAM ロール参照
このセクションでは、STS を使用する Red Hat OpenShift Service on AWS (ROSA) デプロイメントに必要な Operator IAM ロールの詳細を提供します。クラスター Operator は、Operator のロールを使用して、バックエンドストレージ、クラウドプロバイダーの認証情報、クラスターへの外部アクセスの管理など、クラスター操作を実行するために必要な一時的なアクセス許可を取得します。
Operator ロールを作成する場合、一致するクラスターバージョンの Operator ポリシーはロールに割り当てられます。Operator ポリシーは、互換性のある Operator およびバージョンにタグ付けされます。Operator ロールの適切なポリシーは、タグを使用して決定されます。
Operator ロールのアカウントで複数のマッチングポリシーが利用可能な場合は、Operator の作成時にオプションのインタラクティブなリストが提供されます。
表5.12 ROSA クラスター固有の Operator ロール
リソース | 説明 |
---|---|
| Container Storage Interface (CSI) でバックエンドストレージを管理するのに ROSA で必要な IAM ロール。 |
| コアクラスター機能を実行するのに ROSA Machine Config Operator で必要な IAM ロール。 |
| クラウドプロバイダーの認証情報を管理するために ROSA Cloud Credential Operator で必要な IAM ロール。 |
| クラスターのクラウドネットワーク設定を管理するために、クラウドネットワーク設定コントローラーで必要な IAM ロール。 |
| ROSA Image Registry Operator がクラスターの AWS S3 内の OpenShift イメージレジストリーストレージを管理するために必要な IAM ロール。 |
| クラスターへの外部アクセスを管理するのに ROSA Ingress Operator で必要な IAM ロール。 |
| クラスターのクラウドネットワーク認証情報を管理するために、クラウドネットワーク設定コントローラーが必要とする IAM ロール。 |
5.3.1. Operator IAM ロール AWS CLI リファレンス
このセクションでは、manual
モードを使用して以下の rosa
コマンドを実行する際にターミナルに表示される aws
CLI コマンドをリスト表示します。
$ rosa create operator-roles --mode manual --cluster <cluster_name>
manual
モードを使用すると、aws
コマンドは確認用に端末に出力されます。aws
コマンドを確認したら、手動で実行する必要があります。または、rosa create
コマンドで --mode auto
を指定して、aws
コマンドを即時に実行することができます。
コマンド出力
aws iam create-role \ --role-name <cluster_name>-<hash>-openshift-cluster-csi-drivers-ebs-cloud-credent \ --assume-role-policy-document file://operator_cluster_csi_drivers_ebs_cloud_credentials_policy.json \ --tags Key=rosa_cluster_id,Value=<id> Key=rosa_openshift_version,Value=<openshift_version> Key=rosa_role_prefix,Value= Key=operator_namespace,Value=openshift-cluster-csi-drivers Key=operator_name,Value=ebs-cloud-credentials aws iam attach-role-policy \ --role-name <cluster_name>-<hash>-openshift-cluster-csi-drivers-ebs-cloud-credent \ --policy-arn arn:aws:iam::<aws_account_id>:policy/ManagedOpenShift-openshift-cluster-csi-drivers-ebs-cloud-credent aws iam create-role \ --role-name <cluster_name>-<hash>-openshift-machine-api-aws-cloud-credentials \ --assume-role-policy-document file://operator_machine_api_aws_cloud_credentials_policy.json \ --tags Key=rosa_cluster_id,Value=<id> Key=rosa_openshift_version,Value=<openshift_version> Key=rosa_role_prefix,Value= Key=operator_namespace,Value=openshift-machine-api Key=operator_name,Value=aws-cloud-credentials aws iam attach-role-policy \ --role-name <cluster_name>-<hash>-openshift-machine-api-aws-cloud-credentials \ --policy-arn arn:aws:iam::<aws_account_id>:policy/ManagedOpenShift-openshift-machine-api-aws-cloud-credentials aws iam create-role \ --role-name <cluster_name>-<hash>-openshift-cloud-credential-operator-cloud-crede \ --assume-role-policy-document file://operator_cloud_credential_operator_cloud_credential_operator_iam_ro_creds_policy.json \ --tags Key=rosa_cluster_id,Value=<id> Key=rosa_openshift_version,Value=<openshift_version> Key=rosa_role_prefix,Value= Key=operator_namespace,Value=openshift-cloud-credential-operator Key=operator_name,Value=cloud-credential-operator-iam-ro-creds aws iam attach-role-policy \ --role-name <cluster_name>-<hash>-openshift-cloud-credential-operator-cloud-crede \ --policy-arn arn:aws:iam::<aws_account_id>:policy/ManagedOpenShift-openshift-cloud-credential-operator-cloud-crede aws iam create-role \ --role-name <cluster_name>-<hash>-openshift-image-registry-installer-cloud-creden \ --assume-role-policy-document file://operator_image_registry_installer_cloud_credentials_policy.json \ --tags Key=rosa_cluster_id,Value=<id> Key=rosa_openshift_version,Value=<openshift_version> Key=rosa_role_prefix,Value= Key=operator_namespace,Value=openshift-image-registry Key=operator_name,Value=installer-cloud-credentials aws iam attach-role-policy \ --role-name <cluster_name>-<hash>-openshift-image-registry-installer-cloud-creden \ --policy-arn arn:aws:iam::<aws_account_id>:policy/ManagedOpenShift-openshift-image-registry-installer-cloud-creden aws iam create-role \ --role-name <cluster_name>-<hash>-openshift-ingress-operator-cloud-credentials \ --assume-role-policy-document file://operator_ingress_operator_cloud_credentials_policy.json \ --tags Key=rosa_cluster_id,Value=<id> Key=rosa_openshift_version,Value=<openshift_version> Key=rosa_role_prefix,Value= Key=operator_namespace,Value=openshift-ingress-operator Key=operator_name,Value=cloud-credentials aws iam attach-role-policy \ --role-name <cluster_name>-<hash>-openshift-ingress-operator-cloud-credentials \ --policy-arn arn:aws:iam::<aws_account_id>:policy/ManagedOpenShift-openshift-ingress-operator-cloud-credentials
テーブルで提供されているコマンドの例には、ManagedOpenShift
接頭辞を使用する Operator ロールが含まれます。Operator ポリシーを含む、アカウント全体のロールおよびポリシーの作成時にカスタム接頭辞を定義する場合は、Operator ロールの作成時に --prefix <prefix_name>
オプションを使用してこれを参照する必要があります。
5.3.2. カスタム Operator IAM ロールの接頭辞について
AWS Security Token Service (STS) を使用する各 Red Hat OpenShift Service on AWS (ROSA) クラスターには、クラスター固有の Operator IAM ロールが必要です。
デフォルトでは、Operator ロール名の前にクラスター名とランダムな 4 桁のハッシュが付けられます。たとえば、mycluster
という名前のクラスターの Cloud Credential OperatorIAM ロールのデフォルト名は mycluster-<hash>-openshift-cloud-credential-operator-cloud-credentials
です。ここで、<hash>
はランダムな 4 桁の文字列です。
このデフォルトの命名規則により、AWS アカウントのクラスターの Operator IAM ロールを簡単に識別できます。
クラスターの Operator ロールを作成する場合は、オプションで、<cluster_name>-<hash>
の代わりに使用するカスタム接頭辞を指定できます。カスタム接頭辞を使用すると、環境の要件を満たすために、Operator ロール名の前に論理識別子を追加できます。たとえば、クラスター名と環境タイプ (mycluster-dev
など) の接頭辞を付けることができます。この例では、カスタム接頭辞が付いた CloudCredentialOperator のロール名は mycluster-dev-openshift-cloud-credential-operator-cloud-credenti
です。
ロール名は 64 文字に切り捨てられます。
関連情報
- カスタム接頭辞を使用してクラスター固有の Operator IAM ロールを作成する手順は、OpenShift Cluster Manager を使用してカスタマイズしたクラスターを作成する または CLI を使用してカスタマイズしたクラスターを作成する カスタマイズを使用したクラスターの作成を参照してください。
5.4. Operator 認証のための Open ID Connect (OIDC) 要件
STS を使用する ROSA インストールの場合は、クラスター Operator が認証するために使用するクラスター固有の OIDC プロバイダーを作成するか、独自の OIDC プロバイダー用に独自の OIDC 設定を作成する必要があります。
5.4.1. CLI を使用した OIDC プロバイダーの作成
Red Hat OpenShift Service on AWS (ROSA) CLI (rosa
) を使用して、AWS アカウントでホストされる OIDC プロバイダーを作成できます。
前提条件
- ROSA CLI の最新バージョンがインストールされている。
手順
未登録または登録済みの OIDC 設定を使用して OIDC プロバイダーを作成する方法
未登録の OIDC 設定では、クラスターを通じて OIDC プロバイダーを作成する必要があります。次のコマンドを実行して OIDC プロバイダーを作成します。
$ rosa create oidc-provider --mode manual --cluster <cluster_name>
注記manual
モードを使用すると、aws
コマンドはレビュー用に端末に出力されます。aws
コマンドを確認したら、手動で実行する必要があります。または、rosa create
コマンドで--mode auto
を指定して、aws
コマンドを即時に実行することができます。コマンド出力
aws iam create-open-id-connect-provider \ --url https://oidc.op1.openshiftapps.com/<oidc_config_id> \1 --client-id-list openshift sts.<aws_region>.amazonaws.com \ --thumbprint-list <thumbprint> 2
- 1
- クラスターの作成後に OpenID Connect (OIDC) ID プロバイダーにアクセスするために使用する URL。
- 2
- サムプリントは、
rosa create oidc-provider
コマンドの実行時に自動的に生成されます。AWS Identity and Access Management (IAM) OIDC ID プロバイダーでサムプリントをしようする方法の詳細は、AWS ドキュメント を参照してください。
登録された OIDC 設定は、OIDC 設定 ID を使用します。OIDC 設定 ID を指定して次のコマンドを実行します。
$ rosa create oidc-provider --oidc-config-id <oidc_config_id> --mode auto -y
コマンド出力
I: Creating OIDC provider using 'arn:aws:iam::4540112244:user/userName' I: Created OIDC provider with ARN 'arn:aws:iam::4540112244:oidc-provider/dvbwgdztaeq9o.cloudfront.net/241rh9ql5gpu99d7leokhvkp8icnalpf'
5.4.2. OpenID Connect 設定の作成
Red Hat がホストするクラスターを使用する場合は、Red Hat OpenShift Service on AWS (ROSA) CLI (rosa
) を使用して、マネージドまたはアンマネージド OpenID Connect (OIDC) 設定を作成できます。マネージド OIDC 設定は Red Hat の AWS アカウント内に保存されますが、生成されたアンマネージド OIDC 設定は AWS アカウント内に保存されます。OIDC 設定は、OpenShift Cluster Manager で使用するために登録されています。アンマネージド OIDC 設定を作成する場合、CLI は秘密キーを提供します。
OpenID Connect 設定の作成
Red Hat OpenShift Service on AWS クラスターを使用する場合は、クラスターを作成する前に OpenID Connect (OIDC) 設定を作成できます。この設定は、OpenShift Cluster Manager で使用するために登録されています。
前提条件
-
インストールホストに、最新の Red Hat OpenShift Service on AWS (ROSA) CLI (
rosa
) をインストールして設定している。
手順
AWS リソースと一緒に OIDC 設定を作成するには、次のコマンドを実行します。
$ rosa create oidc-config --mode=auto --yes
このコマンドは次の情報を返します。
出力例
? Would you like to create a Managed (Red Hat hosted) OIDC Configuration Yes I: Setting up managed OIDC configuration I: To create Operator Roles for this OIDC Configuration, run the following command and remember to replace <user-defined> with a prefix of your choice: rosa create operator-roles --prefix <user-defined> --oidc-config-id 13cdr6b If you are going to create a Hosted Control Plane cluster please include '--hosted-cp' I: Creating OIDC provider using 'arn:aws:iam::4540112244:user/userName' ? Create the OIDC provider? Yes I: Created OIDC provider with ARN 'arn:aws:iam::4540112244:oidc-provider/dvbwgdztaeq9o.cloudfront.net/13cdr6b'
クラスターを作成するときは、OIDC 設定 ID を指定する必要があります。CLI 出力では、
--mode auto
のこの値が提供されます。それ以外の場合は、--mode manual
のaws
CLI 出力に基づいてこれらの値を決定する必要があります。オプション: OIDC 設定 ID を変数として保存して、後で使用できます。次のコマンドを実行して変数を保存します。
$ export OIDC_ID=<oidc_config_id>1
- 1
- 上記の出力例では、OIDC 設定 ID は 13cdr6b です。
次のコマンドを実行して、変数の値を表示します。
$ echo $OIDC_ID
出力例
13cdr6b
検証
ユーザー組織に関連付けられているクラスターで使用できる可能な OIDC 設定をリストできます。以下のコマンドを実行します。
$ rosa list oidc-config
出力例
ID MANAGED ISSUER URL SECRET ARN 2330dbs0n8m3chkkr25gkkcd8pnj3lk2 true https://dvbwgdztaeq9o.cloudfront.net/2330dbs0n8m3chkkr25gkkcd8pnj3lk2 233hvnrjoqu14jltk6lhbhf2tj11f8un false https://oidc-r7u1.s3.us-east-1.amazonaws.com aws:secretsmanager:us-east-1:242819244:secret:rosa-private-key-oidc-r7u1-tM3MDN
独自の OpenID Connect 設定を作成するためのパラメーターオプション
次のオプションを rosa create oidc-config
コマンドに追加できます。これらのパラメーターはすべてオプションです。パラメーターを指定せずに rosa create oidc-config
コマンドを実行すると、アンマネージドの OIDC 設定が作成されます。
OpenShift Cluster Manager を通じて /oidc_configs
にリクエストを送信して、アンマネージド OIDC 設定を登録する必要があります。応答で ID を受け取ります。この ID を使用してクラスターを作成します。
生ファイル
RSA 秘密キーの生ファイルを提供できます。このキーの名前は rosa-private-key-oidc-<random_label_of_length_4>.key
です。また、discovery-document-oidc-<random_label_of_length_4>.json
という名前の検出ドキュメントと、jwks-oidc-<random_label_of_length_4>.json
という名前の JSON Web キーセットも受け取ります。
これらのファイルを使用してエンドポイントを設定します。このエンドポイントは、/.well-known/openid-configuration
に対して検出ドキュメントで応答し、keys.json
に対して JSON Web キーセットで応答します。秘密キーは、Amazon Web Services (AWS) Secrets Manager Service (SMS) に平文として保存されます。
例
$ rosa create oidc-config --raw-files
モード
OIDC 設定を作成するモードを指定できます。manual
オプションを使用すると、S3 バケット内で OIDC 設定をセットアップする AWS コマンドを受け取ります。このオプションでは、秘密キーを Secrets Manager に保存します。manual
オプションの場合、OIDC エンドポイント URL は S3 バケットの URL になります。OIDC 設定を OpenShift Cluster Manager に登録するには、Secrets Manager ARN を取得する必要があります。
auto
オプションを使用すると、manual
モードと同じ OIDC 設定と AWS リソースを受け取ります。2 つのオプションの大きな違いは、自動
オプションを使用すると ROSA が AWS を呼び出すため、それ以上のアクションを行う必要がないことです。OIDC エンドポイント URL は、S3 バケットの URL です。CLI は Secrets Manager ARN を取得し、OIDC 設定を OpenShift Cluster Manager に登録し、ユーザーが STS クラスターの作成を続行するために実行できる 2 番目の rosa
コマンドを報告します。
例
$ rosa create oidc-config --mode=<auto|manual>
管理
Red Hat の AWS アカウントでホストされる OIDC 設定を作成します。このコマンドは、STS クラスターの作成時に使用する OIDC 設定 ID で直接応答する秘密キーを作成します。
例
$ rosa create oidc-config --managed
出力例
W: For a managed OIDC Config only auto mode is supported. However, you may choose the provider creation mode ? OIDC Provider creation mode: auto I: Setting up managed OIDC configuration I: Please run the following command to create a cluster with this oidc config rosa create cluster --sts --oidc-config-id 233jnu62i9aphpucsj9kueqlkr1vcgra I: Creating OIDC provider using 'arn:aws:iam::242819244:user/userName' ? Create the OIDC provider? Yes I: Created OIDC provider with ARN 'arn:aws:iam::242819244:oidc-provider/dvbwgdztaeq9o.cloudfront.net/233jnu62i9aphpucsj9kueqlkr1vcgra'
5.5. Service Control Policy (SCP) の有効なパーミッションの最小セット
Service Control Policy (SCP) は、組織内のパーミッションを管理する組織ポリシーの一種です。SCP は、組織内のアカウントを、定義されたアクセス制御ガイドラインの範囲内にとどめるためのものです。これらのポリシーは、AWS Organizations で維持され、接続された AWS アカウント内で利用可能なサービスを制御します。SCP の管理はお客様の責任です。
AWS Security Token Service (STS) を使用する場合は、Service Control Policy が次のリソースをブロックしないようにする必要があります。
-
ec2:{}
-
iam:{}
-
tag:*
Service Control Policy (SCP) がこれらの必要なパーミッションを制限していないことを確認します。
サービス | アクション | 効果 | |
---|---|---|---|
必須 | Amazon EC2 | すべて | 許可 |
Amazon EC2 Auto Scaling | すべて | 許可 | |
Amazon S3 | すべて | 許可 | |
アイデンティティーおよびアクセス管理 | すべて | 許可 | |
Elastic Load Balancing | すべて | 許可 | |
Elastic Load Balancing V2 | すべて | 許可 | |
Amazon CloudWatch | すべて | 許可 | |
Amazon CloudWatch Events | すべて | 許可 | |
Amazon CloudWatch Logs | すべて | 許可 | |
AWS EC2 Instance Connect | SendSerialConsoleSSHPublicKey | 許可 | |
AWS Support | すべて | 許可 | |
AWS Key Management Service | すべて | 許可 | |
AWS Security Token Service | すべて | 許可 | |
AWS Tiro | CreateQuery GetQueryAnswer GetQueryExplanation | 許可 | |
AWS Marketplace | サブスクライブ サブスクライブ解除 サブスクリプションの表示 | 許可 | |
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 Services | すべて | 許可 |
第6章 OpenID Connect の概要
OpenID Connect (OIDC) は、セキュリティートークンサービス (STS) を使用して、クライアントが Web ID トークンを提供して複数のサービスにアクセスできるようにします。クライアントが STS を使用してサービスにサインインすると、トークンは OIDC ID プロバイダーに対して検証されます。
OIDC プロトコルは、クライアントの ID を認証するために必要な情報を含む設定 URL を使用します。プロトコルは、プロバイダーがクライアントを検証してサインインするために必要な認証情報をプロバイダーに応答します。
Red Hat OpenShift Service on AWS クラスターは、STS と OIDC を使用して、クラスター内のオペレーターに必要な AWS リソースへのアクセスを許可します。
6.1. OIDC 検証オプションについて
OIDC 検証には 3 つのオプションがあります。
未登録のマネージド OIDC 設定
未登録のマネージド OIDC 設定は、クラスターのインストールプロセス中に作成されます。設定は Red Hat の AWS アカウントでホストされます。このオプションでは、OIDC 設定にリンクする ID は提供されないため、このタイプの OIDC 設定は単一クラスターでのみ使用できます。
登録されたマネージド OIDC 設定
クラスターの作成を開始する前に、登録済みのマネージド OIDC 設定を作成します。この設定は、未登録のマネージド OIDC 設定と同様に、Red Hat の AWS アカウントでホストされます。OIDC 設定にこのオプションを使用すると、OIDC 設定にリンクする ID を受け取ります。Red Hat は、この ID を使用して発行者の URL と秘密キーを識別します。次に、この URL と秘密キーを使用して、認証プロバイダーと Operator ロールを作成できます。これらのリソースは、Identity and Access Management (IAM) AWS サービスを使用して、AWS アカウントの下に作成されます。クラスターの作成プロセス中に OIDC 設定 ID を使用することもできます。
登録済みのアンマネージドの OIDC 設定
クラスターの作成を開始する前に、登録済みのアンマネージド OIDC 設定を作成できます。この設定は AWS アカウントでホストされます。このオプションを使用する場合は、秘密キーを管理する責任があります。Red Hat OpenShift Cluster Manager に設定を登録するには、AWS Secrets Manager (SM) サービスと設定をホストする発行者 URL を使用して AWS Secrets ファイルに秘密キーを保存します。Red Hat OpenShift Service on AWS (ROSA) CLI である
rosa
を使用して、rosa create oidc-config --managed=false
コマンドを使用して、登録されたアンマネージドの OIDC 設定を作成できます。このコマンドは、アカウントの下に設定を作成してホストし、必要なファイルと秘密鍵を作成します。このコマンドは、OpenShift Cluster Manager に設定を登録します。
登録されたオプションを使用して、クラスターの作成を開始する前に必要な IAM リソースを作成できます。このオプションを選択すると、クラスターの作成中に待機時間があり、OIDC プロバイダーと Operator のロールを作成するまでインストールが一時停止するため、インストール時間が短縮されます。
ROSA Classic の場合は、任意の OIDC 設定オプションを使用できます。HCP で ROSA を使用している場合は、マネージドまたはアンマネージドとして登録済みの OIDC 設定を作成する必要があります。登録された OIDC 設定を他のクラスターと共有できます。この設定を共有する機能により、プロバイダーと Operator のロールを共有することもできます。
実稼働クラスターでは認証検証がクラスター全体で使用されるため、クラスター間で OIDC 設定、OIDC プロバイダー、および Operator のロールを再利用することは推奨できません。Red Hat は、非実稼働テスト環境でのみリソースを再利用することを推奨します。
6.2. OpenID Connect 設定の作成
Red Hat がホストするクラスターを使用する場合は、Red Hat OpenShift Service on AWS (ROSA) CLI (rosa
) を使用して、マネージドまたはアンマネージド OpenID Connect (OIDC) 設定を作成できます。マネージド OIDC 設定は Red Hat の AWS アカウント内に保存されますが、生成されたアンマネージド OIDC 設定は AWS アカウント内に保存されます。OIDC 設定は、OpenShift Cluster Manager で使用するために登録されています。アンマネージド OIDC 設定を作成する場合、CLI は秘密キーを提供します。
OpenID Connect 設定の作成
Red Hat OpenShift Service on AWS クラスターを使用する場合は、クラスターを作成する前に OpenID Connect (OIDC) 設定を作成できます。この設定は、OpenShift Cluster Manager で使用するために登録されています。
前提条件
-
インストールホストに、最新の Red Hat OpenShift Service on AWS (ROSA) CLI (
rosa
) をインストールして設定している。
手順
AWS リソースと一緒に OIDC 設定を作成するには、次のコマンドを実行します。
$ rosa create oidc-config --mode=auto --yes
このコマンドは次の情報を返します。
出力例
? Would you like to create a Managed (Red Hat hosted) OIDC Configuration Yes I: Setting up managed OIDC configuration I: To create Operator Roles for this OIDC Configuration, run the following command and remember to replace <user-defined> with a prefix of your choice: rosa create operator-roles --prefix <user-defined> --oidc-config-id 13cdr6b If you are going to create a Hosted Control Plane cluster please include '--hosted-cp' I: Creating OIDC provider using 'arn:aws:iam::4540112244:user/userName' ? Create the OIDC provider? Yes I: Created OIDC provider with ARN 'arn:aws:iam::4540112244:oidc-provider/dvbwgdztaeq9o.cloudfront.net/13cdr6b'
クラスターを作成するときは、OIDC 設定 ID を指定する必要があります。CLI 出力では、
--mode auto
のこの値が提供されます。それ以外の場合は、--mode manual
のaws
CLI 出力に基づいてこれらの値を決定する必要があります。オプション: OIDC 設定 ID を変数として保存して、後で使用できます。次のコマンドを実行して変数を保存します。
$ export OIDC_ID=<oidc_config_id>1
- 1
- 上記の出力例では、OIDC 設定 ID は 13cdr6b です。
次のコマンドを実行して、変数の値を表示します。
$ echo $OIDC_ID
出力例
13cdr6b
検証
ユーザー組織に関連付けられているクラスターで使用できる可能な OIDC 設定をリストできます。以下のコマンドを実行します。
$ rosa list oidc-config
出力例
ID MANAGED ISSUER URL SECRET ARN 2330dbs0n8m3chkkr25gkkcd8pnj3lk2 true https://dvbwgdztaeq9o.cloudfront.net/2330dbs0n8m3chkkr25gkkcd8pnj3lk2 233hvnrjoqu14jltk6lhbhf2tj11f8un false https://oidc-r7u1.s3.us-east-1.amazonaws.com aws:secretsmanager:us-east-1:242819244:secret:rosa-private-key-oidc-r7u1-tM3MDN
独自の OpenID Connect 設定を作成するためのパラメーターオプション
次のオプションを rosa create oidc-config
コマンドに追加できます。これらのパラメーターはすべてオプションです。パラメーターを指定せずに rosa create oidc-config
コマンドを実行すると、アンマネージドの OIDC 設定が作成されます。
OpenShift Cluster Manager を通じて /oidc_configs
にリクエストを送信して、アンマネージド OIDC 設定を登録する必要があります。応答で ID を受け取ります。この ID を使用してクラスターを作成します。
生ファイル
RSA 秘密キーの生ファイルを提供できます。このキーの名前は rosa-private-key-oidc-<random_label_of_length_4>.key
です。また、discovery-document-oidc-<random_label_of_length_4>.json
という名前の検出ドキュメントと、jwks-oidc-<random_label_of_length_4>.json
という名前の JSON Web キーセットも受け取ります。
これらのファイルを使用してエンドポイントを設定します。このエンドポイントは、/.well-known/openid-configuration
に対して検出ドキュメントで応答し、keys.json
に対して JSON Web キーセットで応答します。秘密キーは、Amazon Web Services (AWS) Secrets Manager Service (SMS) に平文として保存されます。
例
$ rosa create oidc-config --raw-files
モード
OIDC 設定を作成するモードを指定できます。manual
オプションを使用すると、S3 バケット内で OIDC 設定をセットアップする AWS コマンドを受け取ります。このオプションでは、秘密キーを Secrets Manager に保存します。manual
オプションの場合、OIDC エンドポイント URL は S3 バケットの URL になります。OIDC 設定を OpenShift Cluster Manager に登録するには、Secrets Manager ARN を取得する必要があります。
auto
オプションを使用すると、manual
モードと同じ OIDC 設定と AWS リソースを受け取ります。2 つのオプションの大きな違いは、自動
オプションを使用すると ROSA が AWS を呼び出すため、それ以上のアクションを行う必要がないことです。OIDC エンドポイント URL は、S3 バケットの URL です。CLI は Secrets Manager ARN を取得し、OIDC 設定を OpenShift Cluster Manager に登録し、ユーザーが STS クラスターの作成を続行するために実行できる 2 番目の rosa
コマンドを報告します。
例
$ rosa create oidc-config --mode=<auto|manual>
管理
Red Hat の AWS アカウントでホストされる OIDC 設定を作成します。このコマンドは、STS クラスターの作成時に使用する OIDC 設定 ID で直接応答する秘密キーを作成します。
例
$ rosa create oidc-config --managed
出力例
W: For a managed OIDC Config only auto mode is supported. However, you may choose the provider creation mode ? OIDC Provider creation mode: auto I: Setting up managed OIDC configuration I: Please run the following command to create a cluster with this oidc config rosa create cluster --sts --oidc-config-id 233jnu62i9aphpucsj9kueqlkr1vcgra I: Creating OIDC provider using 'arn:aws:iam::242819244:user/userName' ? Create the OIDC provider? Yes I: Created OIDC provider with ARN 'arn:aws:iam::242819244:oidc-provider/dvbwgdztaeq9o.cloudfront.net/233jnu62i9aphpucsj9kueqlkr1vcgra'
6.3. CLI を使用した OIDC プロバイダーの作成
Red Hat OpenShift Service on AWS (ROSA) CLI (rosa
) を使用して、AWS アカウントでホストされる OIDC プロバイダーを作成できます。
前提条件
- ROSA CLI の最新バージョンがインストールされている。
手順
未登録または登録済みの OIDC 設定を使用して OIDC プロバイダーを作成する方法
未登録の OIDC 設定では、クラスターを通じて OIDC プロバイダーを作成する必要があります。次のコマンドを実行して OIDC プロバイダーを作成します。
$ rosa create oidc-provider --mode manual --cluster <cluster_name>
注記manual
モードを使用すると、aws
コマンドはレビュー用に端末に出力されます。aws
コマンドを確認したら、手動で実行する必要があります。または、rosa create
コマンドで--mode auto
を指定して、aws
コマンドを即時に実行することができます。コマンド出力
aws iam create-open-id-connect-provider \ --url https://oidc.op1.openshiftapps.com/<oidc_config_id> \1 --client-id-list openshift sts.<aws_region>.amazonaws.com \ --thumbprint-list <thumbprint> 2
- 1
- クラスターの作成後に OpenID Connect (OIDC) ID プロバイダーにアクセスするために使用する URL。
- 2
- サムプリントは、
rosa create oidc-provider
コマンドの実行時に自動的に生成されます。AWS Identity and Access Management (IAM) OIDC ID プロバイダーでサムプリントをしようする方法の詳細は、AWS ドキュメント を参照してください。
登録された OIDC 設定は、OIDC 設定 ID を使用します。OIDC 設定 ID を指定して次のコマンドを実行します。
$ rosa create oidc-provider --oidc-config-id <oidc_config_id> --mode auto -y
コマンド出力
I: Creating OIDC provider using 'arn:aws:iam::4540112244:user/userName' I: Created OIDC provider with ARN 'arn:aws:iam::4540112244:oidc-provider/dvbwgdztaeq9o.cloudfront.net/241rh9ql5gpu99d7leokhvkp8icnalpf'
6.4. 関連情報
- ROSA Classic の手順は、OpenID Connect 設定の作成 を参照してください。
- HCP を使用した ROSA の OpenID Connect 設定の作成 の手順を参照してください。