2.4. SRE およびサービスアカウントのアクセス
2.4.1. アイデンティティーおよびアクセス管理
Red Hat Site Reliability Engineering (SRE) チームによるアクセスのほとんどは、自動化された設定管理によりクラスター Operator を使用して行われます。
Workload Identify Federation (WIF) 認証タイプで作成された Google Cloud Platform (GCP) クラスター上の OpenShift Dedicated では、SRE アクセスに Operator は使用されません。代わりに、SRE アカウントアクセスに必要なロールが、WIF 設定の作成中に sd-sre-platform-gcp-access グループに割り当てられ、クラスターのデプロイ前に OpenShift Cluster Manager によって検証されます。WIF 設定の詳細は、関連情報 を参照してください。
2.4.1.1. サブプロセッサー
利用可能なサブプロセスのリストは、Red Hat カスタマーポータルの Red Hat Subprocessor List を参照してください。
2.4.1.2. SRE のすべての OpenShift Dedicated クラスターへのアクセス
SRE は、プロキシーを介して OpenShift Dedicated クラスターにアクセスします。プロキシーは、SRE がログインするときに、OpenShift Dedicated クラスター内のサービスアカウントをミントします。OpenShift Dedicated クラスター用に ID プロバイダーが設定されていないため、SRE はローカル Web コンソールコンテナーを実行してプロキシーにアクセスします。SRE は、クラスター Web コンソールに直接アクセスしません。SRE は、監査可能性を確保するために、個々のユーザーとして認証する必要があります。すべての認証試行は、セキュリティー情報およびイベント管理 (SIEM) システムに記録されます。
2.4.1.3. OpenShift Dedicated の特権アクセスの制御
Red Hat SRE は、OpenShift Dedicated およびパブリッククラウドプロバイダーのコンポーネントにアクセスする場合の最小限の権限の原則に従います。手動による SRE アクセスには、基本的に以下の 4 つのカテゴリーがあります。
- 通常の 2 要素認証を使用するが、権限の昇格のない Red Hat カスタマーポータル経由での SRE の管理者アクセス。
- 通常の 2 要素認証があり、権限の昇格のない Red Hat の企業 SSO を使用した SRE の管理者アクセス。
- OpenShift の昇格。これは Red Hat SSO を使用した手動による昇格です。これは完全に監査されており、SRE が行うすべての操作には管理者の承認が必要です。
- クラウドプロバイダーコンソールまたは CLI アクセスの手動昇格である、クラウドプロバイダーのアクセスまたは昇格。アクセスは 60 分間に制限され、完全に監査されます。
これらのアクセスタイプのそれぞれには、コンポーネントへの異なるレベルのアクセスがあります。
コンポーネント | 通常の SRE 管理者アクセス (Red Hat カスタマーポータル) | 通常の SRE 管理者アクセス (Red Hat SSO) | OpenShift の昇格 | クラウドプロバイダーのアクセス |
---|---|---|---|---|
OpenShift Cluster Manager | R/W | アクセスなし | アクセスなし | アクセスなし |
OpenShift Web コンソール | アクセスなし | R/W | R/W | アクセスなし |
ノードのオペレーティングシステム | アクセスなし | 昇格した OS およびネットワークのパーミッションのリスト。 | 昇格した OS およびネットワークのパーミッションのリスト。 | アクセスなし |
AWS コンソール | アクセスなし | アクセスはありませんが、これはクラウドプロバイダーのアクセスを要求するために使用されるアカウントです。 | アクセスなし | SRE アイデンティティーを使用したすべてのクラウドプロバイダーのパーミッション。 |
2.4.1.4. SRE のクラウドインフラストラクチャーアカウントへのアクセス
Red Hat の担当者は、通常の OpenShift Dedicated 操作ではクラウドインフラストラクチャーアカウントにアクセスしません。緊急のトラブルシューティングの目的で、Red Hat SRE にはクラウドインフラストラクチャーアカウントにアクセスするための明確に定義された監査可能な手順があります。
AWS では、SRE は AWS Security Token Service (STS) を使用して BYOCAdminAccess
ユーザーの有効期限の短い AWS アクセストークンを生成します。STS トークンへのアクセスは監査ログに記録され、個別のユーザーまでトレースできます。BYOCAdminAccess
には AdministratorAccess
IAM ポリシーが割り当てられます。
Google Cloud では、SRE は Red Hat SAML アイデンティティープロバイダー (IDP) に対して認証された後にリソースにアクセスします。IDP は、生存期間のあるトークンを承認します。トークンの発行は、企業の Red Hat IT により監査可能で、個別のユーザーにリンクされます。
2.4.1.5. Red Hat サポートのアクセス
通常、Red Hat CEE チームメンバーは、クラスターの一部に対する読み取り専用アクセスを持ちます。特に、CEE にはコアおよび製品の namespace への制限されたアクセスがありますが、お客様の namespace にはアクセスできません。
ロール | コア namespace | 階層化した製品 namespace | お客様の namespace | クラウドインフラストラクチャーアカウント* |
---|---|---|---|---|
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 | 読み取り: Limited[4] 書き込み: Limited[4] |
お客様ユーザー | 読み取り: None 書き込み: None | 読み取り: None 書き込み: None | 読み取り: Limited[5] 書き込み: Limited[5] | 読み取り: None 書き込み: None |
上記以外 | 読み取り: None 書き込み: None | 読み取り: None 書き込み: None | 読み取り: None 書き込み: None | 読み取り: None 書き込み: None |
Cloud Infrastructure Account は基礎となる AWS または Google Cloud アカウントを参照します。
- デプロイメントの失敗、クラスターのアップグレード、および適切でないワーカーノードの置き換えなどの一般的なユースケースに対応することに限定されます。
- Red Hat は、デフォルトではお客様のデータにアクセスできません。
- SRE のクラウドインフラストラクチャーアカウントへのアクセスは、文書化されたインシデントの発生時の例外的なトラブルシューティングのための "break-glass" 手順です。
- 顧客管理者は、Cloud Infrastructure Access を通じてクラウドインフラストラクチャーアカウントコンソールへのアクセスが限定されます。
- 顧客管理者によって RBAC で許可される内容や、ユーザーが作成した namespace に限定されます。
2.4.1.6. お客様のアクセス
お客様のアクセスは、お客様によって作成される namespace および顧客管理者ロールによって RBAC を使用して付与されるパーミッションに限定されます。基礎となるインフラストラクチャーまたは製品 namespace へのアクセスは通常、cluster-admin
アクセスなしでは許可されません。お客様のアクセスおよび認証の詳細は、このドキュメントの認証に関するセクションを参照してください。
2.4.1.7. アクセスの承認およびレビュー
新規の SRE ユーザーアクセスには、管理者の承認が必要です。分離された SRE アカウントまたは転送された SRE アカウントは、自動化されたプロセスで認可されたユーザーとして削除されます。さらに、SRE は、許可されたユーザーリストの管理のサインオフを含む定期的なアクセスレビューを実行します。
2.4.2. SRE クラスターアクセス
OpenShift Dedicated クラスターへの SRE アクセスは、複数の必要な認証階層を通じて制御され、すべて厳格な企業ポリシーによって管理されます。クラスターにアクセスするすべての認証試行とクラスター内で行われた変更は、それらのアクションを担当する 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 エンドポイントを含むプライベートサブネットがあります。
- Private Service Connect (PSC) クラスターへのアクセス: リクエストが Red Hat の内部バックエンドインフラストラクチャーに送信されます。このインフラストラクチャーにより、トラフィックが保護された信頼できるネットワークを介して GCP 内の Red Hat の Management プロジェクトにルーティングされます。Red Hat Management プロジェクトには、複数のリージョンのサブネットで設定された VPC が含まれています。各リージョンには、各リージョンにあるお客様のクラスターへのプライベートアクセスを提供する PSC エンドポイントが含まれています。トラフィックは適切な地域サブネットを経由してルーティングされます。これにより、パブリックインターネットを経由しない、クラスターへのセキュアでプライベートなアクセスが確保されます。
2.4.3. サービスアカウントが SRE 所有のプロジェクトで AWS IAM ロールを引き受ける方法
AWS Security Token Service (STS) を使用する OpenShift Dedicated クラスターをインストールすると、クラスター固有の Operator AWS Identity and Access Management (IAM) ロールが作成されます。これらの IAM ロールにより、OpenShift Dedicated クラスター Operator がコア OpenShift 機能を実行できるようになります。
クラスター Operator はサービスアカウントを使用して IAM ロールを引き受けます。サービスアカウントが IAM ロールを引き受けると、クラスター Operator の Pod で使用するサービスアカウントに一時的な STS 認証情報が提供されます。引き受けたロールに必要な AWS 権限がある場合、サービスアカウントは Pod で AWS SDK 操作を実行できます。
SRE 所有プロジェクトで AWS IAM ロールを引き受けるワークフロー
次の図は、SRE 所有プロジェクトで AWS IAM ロールを引き受けるためのワークフローを示しています。
図2.1 SRE 所有プロジェクトで AWS IAM ロールを引き受けるワークフロー
ワークフローには次の段階があります。
クラスター Operator が実行する各プロジェクト内で、Operator のデプロイメント仕様には、投影されたサービスアカウントトークンのボリュームマウントと、Pod の AWS 認証情報設定が含まれるシークレットがあります。トークンは、オーディエンスおよび時間の制限があります。OpenShift Dedicated は 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 クラスターを使用する OpenShift Dedicated では、インストール中に 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 認証情報を返します。
2.4.4. 関連情報
WIF 設定と SRE アクセスロールの詳細は、WIF 設定の作成 を参照してください。