2.10. SRE およびサービスアカウントのアクセス
Red Hat Site Reliability Engineering (SRE) による Red Hat OpenShift Service on AWS (ROSA) クラスターへのアクセスについて、アイデンティティーおよびアクセス管理の観点から説明します。
2.10.1. アイデンティティーおよびアクセス管理
Red Hat SRE チームによるアクセスのほとんどは、自動化された設定管理によりクラスター Operator を使用して行われます。
サブプロセッサー
利用可能なサブプロセスのリストは、Red Hat カスタマーポータルの Red Hat Subprocessor List を参照してください。
2.10.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 ネットワークからのみ許可されます。
図2.1 SRE による ROSA クラスターへのアクセス
2.10.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 アイデンティティーを使用したすべてのクラウドプロバイダーのパーミッション。 |
2.10.2.2. SRE による AWS アカウントへのアクセス
Red Hat の担当者は、通常の Red Hat OpenShift Service on AWS 操作では AWS アカウントにアクセスしません。緊急のトラブルシューティングが必要な場合に、SRE にはクラウドインフラストラクチャーアカウントにアクセスするための明確に定義された監査可能な手順があります。
分離されたバックプレーンフローでは、SRE が顧客のサポートロールへのアクセスを要求します。このリクエストは、バックプレーン API によってジャストインタイム (JIT) 処理され、特定の SRE 担当者のアカウントに対する組織ロールの権限が動的に更新されます。この SRE のアカウントには、特定の Red Hat 顧客の環境へのアクセス権が付与されます。Red Hat のお客様の環境への SRE アクセスは、アクセス要求時にのみ確立される一時的かつ短期間のアクセスです。
STS トークンへのアクセスは監査ログに記録され、個別のユーザーまでトレースできます。STS および非 STS クラスターはいずれも、SRE によるアクセスに AWS STS サービスを使用します。ManagedOpenShift-Technical-Support-Role に ManagedOpenShift-Support-Access ポリシーが割り当てられており、このロールが管理に使用されると、アクセス制御では統合バックプレーンフローが使用されます。ManagedOpenShift-Support-Role に ManagedOpenShift-Technical-Support-<org_id> ポリシーが割り当てられていると、アクセス制御で分離されたバックプレーンフローが使用されます。詳細は、KCS の記事 Updating Trust Policies for ROSA clusters を参照してください。
2.10.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 を参照してください。
2.10.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 に接続できます。
2.10.3. Red Hat サポートのアクセス
通常、Red Hat の CEE (Customer Experience and Engagement) チームは、クラスターの各部分への読み取り専用アクセスを持ちます。特に、CEE にはコアおよび製品の namespace への制限されたアクセスがありますが、お客様の namespace にはアクセスできません。
| ロール | コア namespace | 階層化した製品 namespace | お客様の namespace | AWS アカウント* |
|---|---|---|---|---|
| OpenShift SRE - 通常操作 [1] | 読み取り: All 書き込み: Very 非常に限定される | 読み取り: All 書き込み: None | 読み取り: None 書き込み: None | 読み取り: None 書き込み: None |
| OpenShift SRE - 昇格されたアクセス [2] (承認されたアクセス によって制御) | 読み取り: All 書き込み: All | 読み取り: All 書き込み: All | 読み取り: All 書き込み: All | 読み取り: All 書き込み: All |
| CEE | 読み取り: All 書き込み: None | 読み取り: All 書き込み: None | 読み取り: None 書き込み: None | 読み取り: None 書き込み: None |
| お客様管理者 | 読み取り: None 書き込み: None | 読み取り: None 書き込み: None | 読み取り: All 書き込み: All | 読み取り: All 書き込み: All |
| お客様ユーザー | 読み取り: None 書き込み: None | 読み取り: None 書き込み: None | 読む: 限定的 [3] 書き込み: 限定的 [3] | 読み取り: None 書き込み: None |
| 上記以外 | 読み取り: None 書き込み: None | 読み取り: None 書き込み: None | 読み取り: None 書き込み: None | 読み取り: None 書き込み: None |
- デプロイメントの失敗、クラスターのアップグレード、および適切でないワーカーノードの置き換えなどの一般的なユースケースに対応することに限定されます。
- 昇格されたアクセスにより、SRE に cluster-admin ロールのアクセスレベルが付与され、承認済みアクセスによって制御されます。詳細は、デフォルトのクラスターロールおよび承認されたアクセスを参照してください。
- 顧客管理者によって RBAC で許可される内容と、ユーザーが作成した namespace に限定されます。
関連情報
- 詳細は、承認済みアクセス を参照してください。
- 詳細は、デフォルトのクラスターロール を参照してください。
2.10.4. お客様のアクセス
お客様のアクセスは、お客様によって作成される namespace、およびお客様管理者ロールによって RBAC を使用して付与されるパーミッションに限定されます。基礎となるインフラストラクチャーまたは製品 namespace へのアクセスは通常、cluster-admin アクセスなしでは許可されません。お客様のアクセスと認証の詳細は、このドキュメントの「認証について」セクションを参照してください。
2.10.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
|
|
2.10.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 ロールを引き受けるためのワークフローを示しています。
図2.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 クライアントコードは
AssumeRoleWithWebIdentityAPI を呼び出します。 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 ロールの詳細は、クラスター固有の OperatorIAM ロールリファレンス を参照してください。
- クラスター Operator に必要なポリシーと権限の詳細は、アカウント全体のロール作成方法を 参照してください。
- 詳細は、承認済みアクセス を参照してください。
