認証および認可
Red Hat OpenShift Service on AWS クラスターのセキュリティー保護
概要
第1章 認証および認可の概要 リンクのコピーリンクがクリップボードにコピーされました!
1.1. Red Hat OpenShift Service on AWS の認証および認可に関する一般的な用語集 リンクのコピーリンクがクリップボードにコピーされました!
この用語集では、Red Hat OpenShift Service on AWS の認証および承認で使用される一般的な用語を定義します。
- authentication
- 認証は、Red Hat OpenShift Service on AWS クラスターへのアクセスを決定し、認証されたユーザーのみが Red Hat OpenShift Service on AWS クラスターにアクセスできるようにします。
- 認可
- 認可は、要求されたアクションを実行するパーミッションを識別されたユーザーが持っているかどうかを決定します。
- ベアラートークン
-
ベアラートークンは、ヘッダー
Authorization: Bearer <token>
で API を認証するために使用されます。
- Cloud Credential Operator
- Cloud Credential Operator (CCO) は、クラウドプロバイダーの認証情報をカスタムリソース定義 (CRD) として管理します。
- 設定マップ
-
config map は、設定データを Pod に注入する方法を提供します。タイプ
ConfigMap
のボリューム内の config map に格納されたデータを参照できます。Pod で実行しているアプリケーションは、このデータを使用できます。 - コンテナー
- ソフトウェアとそのすべての依存関係を構成する軽量で実行可能なイメージ。コンテナーはオペレーティングシステムを仮想化するため、データセンター、パブリッククラウドまたはプライベートクラウド、またはローカルホストでコンテナーを実行できます。
- カスタムリソース (CR)
- CR は Kubernetes API のエクステンションです。
- グループ
- グループはユーザーの集まりです。グループは、一度に複数のユーザーにパーミッションを付与する場合に便利です。
- HTPasswd
- HTPasswd は、HTTP ユーザーの認証用のユーザー名とパスワードを格納するファイルを更新します。
- Keystone
- Keystone は、ID、トークン、カタログ、およびポリシーサービスを提供する Red Hat OpenStack Platform (RHOSP) プロジェクトです。
- Lightweight Directory Access Protocol (LDAP)
- LDAP は、ユーザー情報を照会するプロトコルです。
- 手動モード
- 手動モードでは、ユーザーは Cloud Credential Operator (CCO) の代わりにクラウド認証情報を管理します。
- namespace
- namespace は、すべてのプロセスから見える特定のシステムリソースを分離します。namespace 内では、その namespace のメンバーであるプロセスのみがそれらのリソースを参照できます。
- ノード
- ノードは、Red Hat OpenShift Service on AWS クラスター内のワーカーマシンです。ノードは、仮想マシン (VM) または物理マシンのいずれかです。
- OAuth クライアント
- OAuth クライアントは、ベアラートークンを取得するために使用されます。
- OAuth サーバー
- Red Hat OpenShift Service on AWS コントロールプレーンには、設定されたアイデンティティープロバイダーからユーザーのアイデンティティーを決定し、アクセストークンを作成する組み込みの OAuth サーバーが含まれています。
- OpenID Connect
- OpenID Connect は、ユーザーが Single Sign-On (SSO) を使用して OpenID プロバイダーを使用するサイトにアクセスすることを認証するためのプロトコルです。
- passthrough モード
- passthrough モードでは、Cloud Credential Operator (CCO) は提供されるクラウド認証情報を、コンポーネントを要求するコンポーネントに渡します。
- Pod
- Pod は、Kubernetes における最小の論理単位です。Pod は、ワーカーノードで実行される 1 つ以上のコンテナーで構成されます。
- 通常ユーザー
- 最初のログイン時または API 経由でクラスター内に自動的に作成されるユーザー。
- リクエストヘッダー
- 要求ヘッダーは、サーバーが要求の応答を追跡できるように、HTTP 要求コンテキストに関する情報を提供するために使用される HTTP ヘッダーです。
- ロールベースのアクセス制御 (RBAC)
- クラスターユーザーとワークロードが、ロールを実行するために必要なリソースにのみアクセスできるようにするための重要なセキュリティーコントロール。
- サービスアカウント
- サービスアカウントは、クラスターコンポーネントまたはアプリケーションによって使用されます。
- システムユーザー
- クラスターのインストール時に自動的に作成されるユーザー。
- ユーザー
- ユーザーは、API に要求を送信できるエンティティーです。
1.2. Red Hat OpenShift Service on AWS での認証について リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS へのアクセスを制御する際には、dedicated-admin
ロールを持つ管理者が ユーザー認証 を設定し、承認されたユーザーにのみクラスターへのアクセス権を付与します。
ユーザーが Red Hat OpenShift Service on AWS と対話するには、まず何らかの方法で Red Hat OpenShift Service on AWS API に対して認証する必要があります。Red Hat OpenShift Service on AWS API への要求で、OAuth アクセストークンまたは X.509 クライアント証明書 を提供することで認証できます。
有効なアクセストークンまたは証明書を提示しない場合、要求は認証されず、HTTP 401 エラーが発生します。
管理者は、アイデンティティプロバイダーを設定することで認証を設定できます。Red Hat OpenShift Service on AWS でサポートされているアイデンティティプロバイダー を定義し、クラスターに追加できます。
1.3. Red Hat OpenShift Service on AWS での認可について リンクのコピーリンクがクリップボードにコピーされました!
認可は、要求されたアクションを実行する権限を識別されたユーザーが持っているかどうかを決定することです。
管理者は、権限を定義し、ルール、ロール、バインディングなどの RBAC オブジェクト を使用してそれらをユーザーに割り当てることができます。Red Hat OpenShift Service on AWS での認可の仕組みを理解するには、認可の評価 を参照してください。
プロジェクトと namespace を介して、Red Hat OpenShift Service on AWS クラスターへのアクセスを制御することもできます。
クラスターへのユーザーアクセスを制御するだけでなく、Security Context Constraints (SCC) を使用して、Pod が実行できるアクションとアクセスできるリソースを制御することもできます。
次のタスクを通じて、Red Hat OpenShift Service on AWS の認証を管理できます。
- ローカル および クラスター のロールとバインディングの表示。
- ローカルロール を作成し、それをユーザーまたはグループに割り当てます。
- ユーザーまたはグループへのクラスターロールの割り当て: Red Hat OpenShift Service on AWS には、デフォルトのクラスターロール のセットがあります。これらをユーザーまたはグループに追加 できます。
-
クラスター管理者および dedicated-admin ユーザーの作成: Red Hat OpenShift Service on AWS クラスターを作成したユーザーは、他の
cluster-admin
およびdedicated-admin
ユーザーにアクセスを許可できます。 - サービスアカウントの作成: サービスアカウント は、通常のユーザークレデンシャルを共有せずに API アクセスを制御する柔軟な方法を提供します。ユーザーは、アプリケーションでサービスアカウントを作成して使用したり、OAuth クライアント として使用したりできます。
- スコープトークン: スコープトークンは、特定の操作のみを実行できる特定のユーザーとして識別するトークンです。スコープ付きトークンを作成して、パーミッションの一部を別のユーザーまたはサービスアカウントに委任できます。
- LDAP グループの同期: LDAP サーバーに保存されているグループを Red Hat OpenShift Service on AWS ユーザーグループと同期 することにより、ユーザーグループを 1 カ所で管理できます。
第2章 認証について リンクのコピーリンクがクリップボードにコピーされました!
ユーザーが Red Hat OpenShift Service on AWS と対話するには、まずユーザークラスターに対して認証する必要があります。認証層は、Red Hat OpenShift Service on AWS API への要求に関連するユーザーを識別します。その後、認可層が要求元のユーザーに関する情報を使用して、要求を許可するかどうかを決定します。
2.1. ユーザー リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS の ユーザー は、Red Hat OpenShift Service on AWS API への要求を実行できるエンティティーです。Red Hat OpenShift Service on AWS の User
オブジェクトは、それらおよびそれらのグループにロールを追加してシステム内の権限を付与できるアクターを表します。通常、このオブジェクトは Red Hat OpenShift Service on AWS と対話する開発者または管理者のアカウントを表します。
ユーザーにはいくつかのタイプが存在します。
ユーザータイプ | 説明 |
---|---|
|
これは、大半の対話型の Red Hat OpenShift Service on AWS ユーザーが表現される方法です。通常ユーザーは、初回ログイン時にシステムに自動的に作成され、API で作成できます。通常ユーザーは |
|
これらの多くは、インフラストラクチャーが API と安全に対話できるようにすることを主な目的として定義される際に自動的に作成されます。このユーザーは、クラスター管理者 (すべてのものへのアクセスを持つ)、ノードごとのユーザー、ルーターおよびレジストリーで使用できるユーザー、その他が含まれます。最後に、非認証要求に対してデフォルトで使用される |
|
プロジェクトに関連付けられる特殊なシステムユーザーがあります。それらの中には、プロジェクトの初回作成時に自動作成されるものもあれば、プロジェクト管理者が各プロジェクトのコンテンツへのアクセスを定義するために追加で作成するものもあります。サービスアカウントは |
それぞれのユーザーには、Red Hat OpenShift Service on AWS にアクセスするために何らかの認証が必要になります。認証がないか、認証が無効の API 要求は、anonymous
システムユーザーによる要求として認証されます。認証が実行されると、認可されているユーザーの実行内容がポリシーによって決定されます。
2.2. グループ リンクのコピーリンクがクリップボードにコピーされました!
ユーザーは 1 つ以上の グループ に割り当てることができます。それぞれのグループはユーザーの特定のセットを表します。グループは、プロジェクト内のオブジェクトへのアクセスを許可する場合と、ユーザーに個別にアクセスを許可する場合など、複数のユーザーに一度に権限を付与するための認可ポリシーを管理するときに役立ちます。
明示的に定義されたグループに加えて、クラスターによって自動的にプロビジョニングされるシステムグループ、つまり 仮想グループ もあります。
以下のデフォルト仮想グループは最も重要なグループになります。
仮想グループ | 説明 |
---|---|
| 認証されたユーザーに自動的に関連付けられます。 |
| OAuth アクセストークンで認証されたすべてのユーザーに自動的に関連付けられます。 |
| 認証されていないすべてのユーザーに自動的に関連付けられます。 |
2.3. API 認証 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS API への要求は以下の方法で認証されます。
- OAuth アクセストークン
-
<namespace_route>/oauth/authorize
および<namespace_route>/oauth/token
エンドポイントを使用して Red Hat OpenShift Service on AWS OAuth サーバーから取得されます。 -
Authorization: Bearer…
ヘッダーとして送信されます。 -
websocket 要求の
base64url.bearer.authorization.k8s.io.<base64url-encoded-token>
形式の websocket サブプロトコルヘッダーとして送信されます。
-
- X.509 クライアント証明書
- API サーバーへの HTTPS 接続を要求します。
- 信頼される認証局バンドルに対して API サーバーによって検証されます。
- API サーバーは証明書を作成し、その証明書をコントローラーに配布してコントローラーを認証できるようにします。
無効なアクセストークンまたは無効な証明書での要求は認証層によって拒否され、401
エラーが表示されます。
アクセストークンまたは証明書が提供されない場合、認証層は system:anonymous
仮想ユーザーおよび system:unauthenticated
仮想グループを要求に割り当てます。これにより、認可層は匿名ユーザーが実行できる要求 (ある場合) を決定できます。
2.3.1. Red Hat OpenShift Service on AWS OAuth サーバー リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS コントロールプレーンには、組み込みの OAuth サーバーが含まれています。ユーザーは OAuth アクセストークンを取得して、API に対して認証します。
新しい OAuth のトークンが要求されると、OAuth サーバーは設定済みのアイデンティティープロバイダーを使用して要求したユーザーのアイデンティティーを判別します。
次に、そのアイデンティティーがマップするユーザーを判別し、そのユーザーのアクセストークンを作成し、そのトークンを使用できるように返します。
2.3.1.1. OAuth トークン要求 リンクのコピーリンクがクリップボードにコピーされました!
OAuth トークンのすべての要求は、トークンを受信し、使用する OAuth クライアントを指定する必要があります。Red Hat OpenShift Service on AWS API の起動時に、次の OAuth クライアントが自動的に作成されます。
OAuth クライアント | 使用法 |
---|---|
|
対話式ログインを処理できるユーザーエージェントで |
|
|
<namespace_route>
は namespace のルートを参照します。これは、以下のコマンドを実行して確認できます。oc get route oauth-openshift -n openshift-authentication -o json | jq .spec.host
$ oc get route oauth-openshift -n openshift-authentication -o json | jq .spec.host
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
OAuth トークンのすべての要求には <namespace_route>/oauth/authorize
への要求が必要になります。ほとんどの認証統合では、このエンドポイントの前に認証プロキシーを配置するか、サポートするアイデンティティープロバイダーに対して認証情報を検証するように Red Hat OpenShift Service on AWS を設定します。<namespace_route>/oauth/authorize
の要求は、CLI などの対話式ログインページを表示できないユーザーエージェントから送られる場合があります。そのため、Red Hat OpenShift Service on AWS は、対話式ログインフローのほかにも WWW-Authenticate
チャレンジを使用した認証をサポートします。
ブラウザークライアントに対するクロスサイトリクエストフォージェリー (CSRF) 攻撃を防止するため、基本的な認証チャレンジは X-CSRF-Token
ヘッダーが要求に存在する場合にのみ送信されます。基本的な WWW-Authenticate
チャレンジを受信する必要があるクライアントでは、このヘッダーを空でない値に設定する必要があります。
認証プロキシーが WWW-Authenticate
チャレンジをサポートしないか、Red Hat OpenShift Service on AWS が WWW-Authenticate チャレンジをサポートしないアイデンティティープロバイダーを使用するように設定されている場合、ユーザーはブラウザーで <namespace_route>/oauth/token/request
からトークンを手動で取得する必要があります。
第3章 ユーザーが所有する OAuth アクセストークンの管理 リンクのコピーリンクがクリップボードにコピーされました!
ユーザーは、独自の OAuth アクセストークンを確認し、不要になったものを削除できます。
3.1. ユーザーが所有する OAuth アクセストークンのリスト表示 リンクのコピーリンクがクリップボードにコピーされました!
ユーザーが所有する OAuth アクセストークンをリスト表示できます。トークン名には機密性がなく、ログインには使用できません。
手順
ユーザーが所有する OAuth アクセストークンをリスト表示します。
oc get useroauthaccesstokens
$ oc get useroauthaccesstokens
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME CLIENT NAME CREATED EXPIRES REDIRECT URI SCOPES <token1> openshift-challenging-client 2021-01-11T19:25:35Z 2021-01-12 19:25:35 +0000 UTC https://oauth-openshift.apps.example.com/oauth/token/implicit user:full <token2> openshift-browser-client 2021-01-11T19:27:06Z 2021-01-12 19:27:06 +0000 UTC https://oauth-openshift.apps.example.com/oauth/token/display user:full <token3> console 2021-01-11T19:26:29Z 2021-01-12 19:26:29 +0000 UTC https://console-openshift-console.apps.example.com/auth/callback user:full
NAME CLIENT NAME CREATED EXPIRES REDIRECT URI SCOPES <token1> openshift-challenging-client 2021-01-11T19:25:35Z 2021-01-12 19:25:35 +0000 UTC https://oauth-openshift.apps.example.com/oauth/token/implicit user:full <token2> openshift-browser-client 2021-01-11T19:27:06Z 2021-01-12 19:27:06 +0000 UTC https://oauth-openshift.apps.example.com/oauth/token/display user:full <token3> console 2021-01-11T19:26:29Z 2021-01-12 19:26:29 +0000 UTC https://console-openshift-console.apps.example.com/auth/callback user:full
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 特定の OAuth クライアントのユーザーが所有する OAuth アクセストークンをリスト表示します。
oc get useroauthaccesstokens --field-selector=clientName="console"
$ oc get useroauthaccesstokens --field-selector=clientName="console"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME CLIENT NAME CREATED EXPIRES REDIRECT URI SCOPES <token3> console 2021-01-11T19:26:29Z 2021-01-12 19:26:29 +0000 UTC https://console-openshift-console.apps.example.com/auth/callback user:full
NAME CLIENT NAME CREATED EXPIRES REDIRECT URI SCOPES <token3> console 2021-01-11T19:26:29Z 2021-01-12 19:26:29 +0000 UTC https://console-openshift-console.apps.example.com/auth/callback user:full
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.2. ユーザーが所有する OAuth アクセストークンの詳細の表示 リンクのコピーリンクがクリップボードにコピーされました!
ユーザーが所有する OAuth アクセストークンの詳細を表示します。
手順
ユーザーが所有する OAuth アクセストークンの詳細を記述します。
oc describe useroauthaccesstokens <token_name>
$ oc describe useroauthaccesstokens <token_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3. ユーザーが所有する OAuth アクセストークンの削除 リンクのコピーリンクがクリップボードにコピーされました!
oc logout
コマンドは、アクティブなセッションの OAuth トークンのみを無効にします。以下の手順を使用して、不要になったユーザーが所有する OAuth トークンを削除できます。
OAuth アクセストークンを削除すると、そのトークンを使用するすべてのセッションからユーザーをログアウトします。
手順
ユーザーが所有する OAuth アクセストークンを削除します。
oc delete useroauthaccesstokens <token_name>
$ oc delete useroauthaccesstokens <token_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
useroauthaccesstoken.oauth.openshift.io "<token_name>" deleted
useroauthaccesstoken.oauth.openshift.io "<token_name>" deleted
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.4. 認証されていないグループのクラスターロールへの追加 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、クラスターロールバインディングを作成することにより、認証されていないユーザーを Red Hat OpenShift Service on AWS の次のクラスターロールに追加できます。認証されていないユーザーには、パブリックではないクラスターロールへのアクセス権はありません。これは、特定のユースケースで必要な場合にのみ行うようにしてください。
認証されていないユーザーを以下のクラスターロールに追加できます。
-
system:scope-impersonation
-
system:webhook
-
system:oauth-token-deleter
-
self-access-reviewer
認証されていないアクセスを変更するときは、常に組織のセキュリティー標準に準拠していることを確認してください。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc
) がインストールされている。
手順
add-<cluster_role>-unauth.yaml
という名前の YAML ファイルを作成し、次のコンテンツを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して設定を適用します。
oc apply -f add-<cluster_role>.yaml
$ oc apply -f add-<cluster_role>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第4章 アイデンティティープロバイダーの設定 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS クラスターを作成したら、アイデンティティプロバイダーを設定して、ユーザーがクラスターにログインしてアクセスする方法を決定する必要があります。
以下のトピックでは、OpenShift Cluster Manager コンソールを使用してアイデンティティープロバイダーを設定する方法を説明します。または、ROSA CLI (rosa
) を使用してアイデンティティープロバイダーを設定し、クラスターにアクセスできます。
4.1. アイデンティティープロバイダーについて リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS には、ビルトイン OAuth サーバーが含まれます。開発者および管理者は OAuth アクセストークンを取得して、API に対して認証します。管理者は、クラスターのインストール後に、OAuth をアイデンティティープロバイダーを指定するように設定できます。アイデンティティープロバイダーを設定すると、ユーザーはログインし、クラスターにアクセスできます。
4.1.1. サポートされるアイデンティティープロバイダー リンクのコピーリンクがクリップボードにコピーされました!
以下の種類のアイデンティティープロバイダーを設定できます。
アイデンティティープロバイダー | 説明 |
---|---|
GitHub または GitHub Enterprise | GitHub または GitHub Enterprise の OAuth 認証サーバーに対して、ユーザー名とパスワードを検証するように GitHub アイデンティティープロバイダーを設定します。 |
GitLab | GitLab.com またはその他の GitLab インスタンスをアイデンティティープロバイダーとして使用するように GitLab アイデンティティープロバイダーを設定します。 |
| Google の OpenID Connect 統合機能 を使用して Google アイデンティティープロバイダーを設定します。 |
LDAP | 単純なバインド認証を使用して、LDAPv3 サーバーに対してユーザー名とパスワードを検証するように LDAP アイデンティティープロバイダーを設定します。 |
OpenID Connect | Authorization Code Flow を使用して OpenID Connect (OIDC) アイデンティティープロバイダーと統合するように OIDC アイデンティティープロバイダーを設定します。 |
htpasswd | 単一の静的管理ユーザー用に htpasswd アイデンティティープロバイダーを設定します。問題のトラブルシューティングを行うには、ユーザーとしてクラスターにログインできます。 重要 htpasswd ID プロバイダーオプションは、単一の静的管理ユーザーを作成できるようにするためだけに含まれています。htpasswd は、Red Hat OpenShift Service on AWS の汎用 ID プロバイダーとしてはサポートされていません。単一ユーザーを設定する手順は、htpasswd アイデンティティープロバイダーの設定 を参照してください。 |
4.1.2. アイデンティティープロバイダーパラメーター リンクのコピーリンクがクリップボードにコピーされました!
以下のパラメーターは、すべてのアイデンティティープロバイダーに共通するパラメーターです。
パラメーター | 説明 |
---|---|
| プロバイダー名は、プロバイダーのユーザー名に接頭辞として付加され、アイデンティティー名が作成されます。 |
| 新規アイデンティティーがログイン時にユーザーにマップされる方法を定義します。以下の値のいずれかを入力します。
|
mappingMethod
パラメーターを add
に設定すると、アイデンティティープロバイダーの追加または変更時に新規プロバイダーのアイデンティティーを既存ユーザーにマッピングできます。
4.2. GitHub アイデンティティープロバイダーの設定 リンクのコピーリンクがクリップボードにコピーされました!
GitHub または GitHub Enterprise の OAuth 認証サーバーに対してユーザー名とパスワードを検証し、Red Hat OpenShift Service on AWS クラスターにアクセスするように GitHub アイデンティティープロバイダーを設定します。OAuth は Red Hat OpenShift Service on AWS と GitHub または GitHub Enterprise 間のトークン交換フローを容易にします。
GitHub 認証を設定することによって、ユーザーは GitHub 認証情報を使用して Red Hat OpenShift Service on AWS にログインできます。GitHub ユーザー ID を持つすべてのユーザーが Red Hat OpenShift Service on AWS クラスターにログインできないようにするために、アクセスを特定の GitHub 組織のユーザーに制限する必要があります。
前提条件
- GitHub 組織管理者が、GitHub 組織設定 内に OAuth アプリケーションを直接作成している。
- GitHub 組織またはチーム が GitHub アカウントに設定されている。
手順
- OpenShift Cluster Manager から、Cluster List ページに移動し、アイデンティティープロバイダーを設定するクラスターを選択します。
- Access control タブをクリックします。
Add identity provider をクリックします。
注記クラスターの作成後に表示される警告メッセージの Add Oauth configuration リンクをクリックして、アイデンティティープロバイダーを設定することもできます。
- ドロップダウンメニューから GitHub を選択します。
アイデンティティープロバイダーの一意の名前を入力します。この名前は後で変更することができません。
OAuth callback URL が指定のフィールドに自動的に生成されます。これを使用して GitHub アプリケーションを登録します。
https://oauth-openshift.apps.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>
https://oauth-openshift.apps.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
https://oauth.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>
https://oauth.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- アプリケーションを GitHub に登録します。
- Red Hat OpenShift Service on AWS に戻り、ドロップダウンメニューからマッピング方法を選択します。ほとんどの場合は、Claim の使用が推奨されます。
- GitHub から提供される Client ID および Client secret を入力します。
- hostname を入力します。GitHub Enterprise のホステッドインスタンスを使用する場合は、ホスト名を入力する必要があります。
- オプション: 認証局 (CA) ファイルを使用して、設定された GitHub Enterprise URL のサーバー証明書を検証できます。Browse をクリックして CA ファイル を見つけ、これをアイデンティティープロバイダーに割り当てます。
- Use organizations または Use teams を選択し、アクセスを特定の GitHub 組織または GitHub チームに制限します。
- アクセスを制限する組織またはチームの名前を入力します。Add more をクリックして、ユーザーが所属できる複数の組織またはチームを指定します。
- Confirm をクリックします。
検証
- 設定されたアイデンティティープロバイダーが、Cluster List ページの Access control タブに表示されるようになりました。
4.3. GitLab アイデンティティープロバイダーの設定 リンクのコピーリンクがクリップボードにコピーされました!
GitLab.com またはその他の GitLab インスタンスをアイデンティティープロバイダーとして使用するように GitLab アイデンティティープロバイダーを設定します。
前提条件
- GitLab バージョン 7.7.0 から 11.0 を使用する場合は、OAuth 統合 を使用して接続します。GitLab バージョン 11.1 以降の場合は、OAuth ではなく OpenID Connect (OIDC) を使用して接続します。
手順
- OpenShift Cluster Manager から、Cluster List ページに移動し、アイデンティティープロバイダーを設定するクラスターを選択します。
- Access control タブをクリックします。
Add identity provider をクリックします。
注記クラスターの作成後に表示される警告メッセージの Add Oauth configuration リンクをクリックして、アイデンティティープロバイダーを設定することもできます。
- ドロップダウンメニューから GitLab を選択します。
アイデンティティープロバイダーの一意の名前を入力します。この名前は後で変更することができません。
OAuth callback URL が指定のフィールドに自動的に生成されます。この URL を GitLab に指定します。
https://oauth.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>
https://oauth.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
https://oauth-openshift.apps.openshift-cluster.example.com/oauth2callback/gitlab
https://oauth-openshift.apps.openshift-cluster.example.com/oauth2callback/gitlab
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- GitLab に新規アプリケーションを追加します。
- Red Hat OpenShift Service on AWS に戻り、ドロップダウンメニューからマッピング方法を選択します。ほとんどの場合は、Claim の使用が推奨されます。
- GitLab から提供される Client ID および Client secret を入力します。
- GitLab プロバイダーの URL を入力します。
- オプション: 認証局 (CA) ファイルを使用して、設定された GitLab URL のサーバー証明書を検証できます。Browse をクリックして CA ファイル を見つけ、これをアイデンティティープロバイダーに割り当てます。
- Confirm をクリックします。
検証
- 設定されたアイデンティティープロバイダーが、Cluster List ページの Access control タブに表示されるようになりました。
4.4. Google アイデンティティープロバイダーの設定 リンクのコピーリンクがクリップボードにコピーされました!
ユーザーが Google 認証情報で認証できるように Google アイデンティティープロバイダーを設定します。
Google をアイデンティティープロバイダーとして使用することで、Google ユーザーはサーバーに対して認証されます。hostedDomain
設定属性を使用して、特定のホストドメインのメンバーに認証を限定することができます。
手順
- OpenShift Cluster Manager から、Cluster List ページに移動し、アイデンティティープロバイダーを設定するクラスターを選択します。
- Access control タブをクリックします。
Add identity provider をクリックします。
注記クラスターの作成後に表示される警告メッセージの Add Oauth configuration リンクをクリックして、アイデンティティープロバイダーを設定することもできます。
- ドロップダウンメニューから Google を選択します。
アイデンティティープロバイダーの一意の名前を入力します。この名前は後で変更することができません。
OAuth callback URL が指定のフィールドに自動的に生成されます。この URL を Google に指定します。
https://oauth.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>
https://oauth.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
https://oauth-openshift.apps.openshift-cluster.example.com/oauth2callback/google
https://oauth-openshift.apps.openshift-cluster.example.com/oauth2callback/google
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- Google の OpenID Connect 統合機能 を使用して Google アイデンティティープロバイダーを設定します。
- Red Hat OpenShift Service on AWS に戻り、ドロップダウンメニューからマッピング方法を選択します。ほとんどの場合は、Claim の使用が推奨されます。
- 登録済みの Google プロジェクトの Client ID と、Google が発行する Client secret を入力します。
- ホストされたドメインを入力して、ユーザーを Google Apps ドメインに制限します。
- Confirm をクリックします。
検証
- 設定されたアイデンティティープロバイダーが、Cluster List ページの Access control タブに表示されるようになりました。
4.5. LDAP アイデンティティープロバイダーの設定 リンクのコピーリンクがクリップボードにコピーされました!
単純なバインド認証を使用して LDAPv3 サーバーに対してユーザー名とパスワードを検証するように LDAP アイデンティティープロバイダーを設定します。
前提条件
LDAP アイデンティティープロバイダーを設定する場合は、設定済みの LDAP URL を入力する必要があります。設定される URL は、LDAP ホストと使用する検索パラメーターを指定する RFC 2255 URL です。URL の構文は以下のようになります。
ldap://host:port/basedn?attribute?scope?filter
ldap://host:port/basedn?attribute?scope?filter
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Expand URL コンポーネント 説明 ldap
通常の LDAP の場合は、文字列
ldap
を使用します。セキュアな LDAP (LDAPS) の場合は、代わりにldaps
を使用します。host:port
LDAP サーバーの名前とポートです。デフォルトは、ldap の場合は
localhost:389
、LDAPS の場合はlocalhost:636
です。basedn
すべての検索が開始されるディレクトリーのブランチの DN です。これは少なくともディレクトリーツリーの最上位である必要がありますが、ディレクトリーのサブツリーを指定することもできます。
attribute
検索対象の属性です。RFC 2255 はコンマ区切りの属性のリストを許可しますが、属性をどれだけ指定しても最初の属性のみが使用されます。属性を指定しない場合は、デフォルトで
uid
が使用されます。使用しているサブツリーのすべてのエントリー間で一意の属性を選択することを推奨します。scope
検索の範囲です。
one
またはsub
のいずれかを指定できます。範囲を指定しない場合は、デフォルトの範囲としてsub
が使用されます。filter
有効な LDAP 検索フィルターです。指定しない場合のデフォルトは
(objectClass=*)
です。検索の実行時に属性、フィルター、指定したユーザー名が組み合わされて以下のような検索フィルターが作成されます。
(&(<filter>)(<attribute>=<username>))
(&(<filter>)(<attribute>=<username>))
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要LDAP ディレクトリーの検索に認証が必要な場合は、エントリー検索の実行に使用する
bindDN
とbindPassword
を指定します。
手順
- OpenShift Cluster Manager から、Cluster List ページに移動し、アイデンティティープロバイダーを設定するクラスターを選択します。
- Access control タブをクリックします。
Add identity provider をクリックします。
注記クラスターの作成後に表示される警告メッセージの Add Oauth configuration リンクをクリックして、アイデンティティープロバイダーを設定することもできます。
- ドロップダウンメニューから LDAP を選択します。
- アイデンティティープロバイダーの一意の名前を入力します。この名前は後で変更することができません。
- ドロップダウンメニューからマッピング方法を選択します。ほとんどの場合は、Claim の使用が推奨されます。
- LDAP URL を入力して、使用する LDAP 検索パラメーターを指定します。
- オプション: Bind DN および Bind password を入力します。
LDAP 属性をアイデンティティーにマップする属性を入力します。
- 値をユーザー ID として使用する ID 属性を入力します。Add more をクリックして、複数の ID 属性を追加します。
- オプション: 表示名の値として使用する Preferred username 属性を入力します。Add more をクリックして、優先する複数のユーザー名属性を追加します。
- オプション: メールアドレスの値として使用する Email 属性を入力します。Add more をクリックして、複数のメール属性を追加します。
- オプション: Show advanced Options をクリックし、認証局 (CA) ファイルを LDAP アイデンティティープロバイダーに追加し、設定された URL のサーバー証明書を検証します。Browse をクリックして CA ファイル を見つけ、これをアイデンティティープロバイダーに割り当てます。
オプション: 高度なオプションで、LDAP プロバイダーを 非セキュア にするよう選択できます。このオプションを選択すると、CA ファイルは使用できません。
重要非セキュアな LDAP 接続 (ldap:// またはポート 389) を使用している場合は、設定ウィザードで Insecure オプションを確認する必要があります。
- Confirm をクリックします。
検証
- 設定されたアイデンティティープロバイダーが、Cluster List ページの Access control タブに表示されるようになりました。
4.6. OpenID アイデンティティープロバイダーの設定 リンクのコピーリンクがクリップボードにコピーされました!
Authorization Code Flow を使用して OpenID Connect アイデンティティープロバイダーに統合するように OpenID アイデンティティープロバイダーを設定します。
Red Hat OpenShift Service on AWS の認証 Operator では、設定済みの OpenID Connect アイデンティティープロバイダーが OpenID Connect Discovery 仕様を実装する必要があります。
要求は、OpenID アイデンティティープロバイダーから返される JWT id_token
から読み取られ、指定される場合は発行者 URL によって返される JSON から読み取られます。
1 つ以上の要求をユーザーのアイデンティティーを使用するように設定される必要があります。
また、どの要求をユーザーの推奨ユーザー名、表示名およびメールアドレスとして使用するか指定することができます。複数の要求が指定されている場合は、値が入力されている最初の要求が使用されます。標準の要求は以下の通りです。
要求 | 説明 |
---|---|
|
ユーザーのプロビジョニング時に優先されるユーザー名です。 |
| メールアドレス。 |
| 表示名。 |
詳細は、OpenID クレームのドキュメント を参照してください。
前提条件
- OpenID Connect を設定する前に、Red Hat OpenShift Service on AWS クラスターで使用する Red Hat 製品またはサービスのインストール前提条件を確認してください。
手順
- OpenShift Cluster Manager から、Cluster List ページに移動し、アイデンティティープロバイダーを設定するクラスターを選択します。
- Access control タブをクリックします。
Add identity provider をクリックします。
注記クラスターの作成後に表示される警告メッセージの Add Oauth configuration リンクをクリックして、アイデンティティープロバイダーを設定することもできます。
- ドロップダウンメニューから OpenID を選択します。
アイデンティティープロバイダーの一意の名前を入力します。この名前は後で変更することができません。
OAuth callback URL が指定のフィールドに自動的に生成されます。
https://oauth.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>
https://oauth.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
https://oauth-openshift.apps.openshift-cluster.example.com/oauth2callback/openid
https://oauth-openshift.apps.openshift-cluster.example.com/oauth2callback/openid
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 認可リクエストを作成する 手順に従って、新しい OpenID Connect クライアントを OpenID ID プロバイダーに登録します。
- Red Hat OpenShift Service on AWS に戻り、ドロップダウンメニューからマッピング方法を選択します。ほとんどの場合は、Claim の使用が推奨されます。
- OpenID から提供される Client ID および Client secret を入力します。
- Issuer URL を入力します。これは、OpenID プロバイダーが発行者 ID としてアサートする URL です。URL クエリーパラメーターまたはフラグメントのない https スキームを使用する必要があります。
- メールアドレスの値として使用する Email 属性を入力します。Add more をクリックして、複数のメール属性を追加します。
- 優先するユーザー名の値として使用する Name 属性を入力します。Add more をクリックして、優先する複数のユーザー名を追加します。
- 表示名の値として使用する Preferred username 属性を入力します。Add more をクリックして、複数の表示名を追加します。
- オプション: Show advanced Options をクリックし、認証局 (CA) ファイルを OpenID アイデンティティープロバイダーに追加します。
-
オプション: 高度なオプションから、追加のスコープ を追加できます。デフォルトでは、
OpenID
の範囲が要求されます。 - Confirm をクリックします。
検証
- 設定されたアイデンティティープロバイダーが、Cluster List ページの Access control タブに表示されるようになりました。
4.7. htpasswd アイデンティティープロバイダーの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者権限で単一の静的ユーザーを作成するように htpasswd アイデンティティープロバイダーを設定します。問題のトラブルシューティングを行うには、ユーザーとしてクラスターにログインできます。
htpasswd ID プロバイダーオプションは、単一の静的管理ユーザーを作成できるようにするためだけに含まれています。htpasswd は、Red Hat OpenShift Service on AWS の汎用 ID プロバイダーとしてはサポートされていません。
手順
- OpenShift Cluster Manager から、Cluster List ページに移動し、クラスターを選択します。
- Access control → Identity providers の順に選択します。
- Add identity provider をクリックします。
- Identity Provider ドロップダウンメニューから HTPasswd を選択します。
- アイデンティティープロバイダーの Name フィールドに一意の名前を追加します。
静的ユーザーに推奨されるユーザー名およびパスワードを使用するか、独自のユーザー名およびパスワードを作成します。
注記この手順で定義した認証情報は、以下の手順で Add を選択した後に表示されません。認証情報を失った場合は、アイデンティティープロバイダーを再作成し、認証情報を再度定義する必要があります。
- Add を選択して htpasswd アイデンティティープロバイダーおよび単一の静的ユーザーを作成します。
クラスターを管理する静的ユーザーにパーミッションを付与します。
- Access control → Cluster Roles and Access で、Add user を選択します。
- 前のステップで作成した静的ユーザーの User ID を入力します。
- Add user を選択して、管理者権限をユーザーに付与します。
検証
設定された htpasswd アイデンティティープロバイダーは、Access control → Identity providers ページに表示されます。
注記アイデンティティープロバイダーの作成後に、同期は通常 2 分以内に完了します。htpasswd アイデンティティープロバイダーが利用可能になると、ユーザーとしてクラスターにログインできます。
- 管理ユーザーは、Access control → Cluster Roles and Access ページで確認できます。ユーザーの管理グループメンバーシップも表示されます。
第5章 RBAC の使用によるパーミッションの定義および適用 リンクのコピーリンクがクリップボードにコピーされました!
5.1. RBAC の概要 リンクのコピーリンクがクリップボードにコピーされました!
ロールベースアクセス制御 (RBAC) オブジェクトは、ユーザーがプロジェクト内で所定のアクションを実行することが許可されるかどうかを決定します。
dedicated-admin
ロールを持つ管理者は、クラスターロールおよびバインディングを使用して、Red Hat OpenShift Service on AWS プラットフォーム自体およびすべてのプロジェクトへの各種のアクセスレベルを持つユーザーを制御できます。
開発者はローカルロールとバインディングを使用して、プロジェクトにアクセスできるユーザーを制御できます。認可は認証とは異なる手順であることに注意してください。認証はアクションを実行するユーザーのアイデンティティーの判別により密接に関連しています。
認可は以下を使用して管理されます。
認可オブジェクト | 説明 |
---|---|
ルール |
オブジェクトのセットで許可されている動詞のセット(例: ユーザーまたはサービスアカウントが Pod の |
ロール | ルールのコレクション。ユーザーおよびグループを複数のロールに関連付けたり、バインドしたりできます。 |
バインディング | ロールを使用したユーザー/グループ間の関連付けです。 |
2 つのレベルの RBAC ロールおよびバインディングが認可を制御します。
RBAC レベル | 説明 |
---|---|
クラスター RBAC | すべてのプロジェクトで適用可能なロールおよびバインディングです。クラスターロール はクラスター全体で存在し、クラスターロールのバインディング はクラスターロールのみを参照できます。 |
ローカル RBAC | 所定のプロジェクトにスコープ設定されているロールおよびバインディングです。ローカルロール は単一プロジェクトのみに存在し、ローカルロールのバインディングはクラスターロールおよびローカルロールの 両方 を参照できます。 |
クラスターのロールバインディングは、クラスターレベルで存在するバインディングですが、ロールバインディングはプロジェクトレベルで存在します。ロールバインディングは、プロジェクトレベルで存在します。クラスターの view (表示) ロールは、ユーザーがプロジェクトを表示できるようローカルのロールバインディングを使用してユーザーにバインドする必要があります。ローカルロールは、クラスターのロールが特定の状況に必要なパーミッションのセットを提供しない場合にのみ作成する必要があります。
この 2 つのレベルからなる階層により、ローカルロールで個別プロジェクト内のカスタマイズが可能になる一方で、クラスターロールによる複数プロジェクト間での再利用が可能になります。
評価時に、クラスターロールのバインディングおよびローカルロールのバインディングが使用されます。以下に例を示します。
- クラスター全体の "allow" ルールがチェックされます。
- ローカルにバインドされた "allow" ルールがチェックされます。
- デフォルトで拒否します。
5.1.1. デフォルトのクラスターロール リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS にはデフォルトのクラスターロールのセットがあります。このロールを、クラスター全体で、またはローカルにユーザーおよびグループにバインドできます。
デフォルトのクラスターロールを手動で変更することは推奨されません。このようなシステムロールへの変更は、クラスターが正常に機能しなくなることがあります。
デフォルトのクラスターロール | 説明 |
---|---|
|
プロジェクトマネージャー。ローカルバインディングで使用される場合、 |
| プロジェクトおよびユーザーに関する基本的な情報を取得できるユーザーです。 |
| すべてのプロジェクトですべてのアクションを実行できるスーパーユーザーです。ローカルバインディングでユーザーにバインドされる場合は、クォータに対する完全な制御およびプロジェクト内のすべてのリソースに対するすべてのアクションを実行できます。 |
| 基本的なクラスターのステータス情報を取得できるユーザーです。 |
| ほとんどのオブジェクトを取得または表示できるが、変更できないユーザー。 |
| プロジェクトのほとんどのプロジェクトを変更できるが、ロールまたはバインディングを表示したり、変更したりする機能を持たないユーザーです。 |
| 独自のプロジェクトを作成できるユーザーです。 |
| 変更できないものの、プロジェクトでほとんどのオブジェクトを確認できるユーザーです。それらはロールまたはバインディングを表示したり、変更したりできません。 |
ローカルバインディングとクラスターバインディングに関する違いに留意してください。ローカルのロールバインディングを使用して cluster-admin
ロールをユーザーにバインドする場合、このユーザーがクラスター管理者の特権を持っているように表示されます。しかし、実際はそうではありません。一方、cluster-admin
をプロジェクトのユーザーにバインドすると、そのプロジェクトにのみ有効なスーパー管理者の権限がそのユーザーに付与されます。そのユーザーはクラスターロール admin
のパーミッションを有するほか、レート制限を編集する機能などの、そのプロジェクトに関するいくつかの追加パーミッションを持ちます。このバインディングは、クラスター管理者にバインドされるクラスターのロールバインディングをリスト表示しない Web コンソール UI を使うと分かりにくくなります。ただし、これは、cluster-admin
をローカルにバインドするために使用するローカルのロールバインディングをリスト表示します。
クラスターロール、ローカルロール、クラスターロールのバインディング、ローカルロールのバインディング、ユーザー、グループおよびサービスアカウントの関係は以下に説明されています。
get pods/exec
、get pods/*
、および get *
ルールは、ロールに適用されると実行権限を付与します。最小権限の原則を適用し、ユーザーおよびエージェントに必要な最小限の RBAC 権限のみを割り当てます。詳細は、RBAC ルールによる実行権限の許可 を参照してください。
5.1.2. 認可の評価 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS は、以下を使用して認可を評価します。
- アイデンティティー
- ユーザーが属するユーザー名とグループのリスト。
- アクション
実行する動作。ほとんどの場合、これは以下で構成されます。
- プロジェクト: アクセスするプロジェクト。プロジェクトは追加のアノテーションを含む Kubernetes namespace であり、これにより、ユーザーのコミュニティーは、他のコミュニティーと分離された状態で独自のコンテンツを編成し、管理できます。
-
動詞:
get
、list
、create
、update
、delete
、deletecollection
、またはwatch
などのアクション自体。 - リソース名: アクセスする API エンドポイント。
- バインディング
- バインディングの詳細なリスト、ロールを持つユーザーまたはグループ間の関連付け。
Red Hat OpenShift Service on AWS は以下の手順を使って認可を評価します。
- アイデンティティーおよびプロジェクトでスコープ設定されたアクションは、ユーザーおよびそれらのグループに適用されるすべてのバインディングを検索します。
- バインディングは、適用されるすべてのロールを見つけるために使用されます。
- ロールは、適用されるすべてのルールを見つけるために使用されます。
- 一致を見つけるために、アクションが各ルールに対してチェックされます。
- 一致するルールが見つからない場合、アクションはデフォルトで拒否されます。
ユーザーおよびグループは一度に複数のロールに関連付けたり、バインドしたりできることに留意してください。
プロジェクト管理者は CLI を使用してローカルロールとローカルバインディングを表示できます。これには、それぞれのロールが関連付けられる動詞およびリソースのマトリクスが含まれます。
プロジェクト管理者にバインドされるクラスターロールは、ローカルバインディングによってプロジェクト内で制限されます。これは、cluster-admin または system:admin に付与されるクラスターロールのようにクラスター全体でバインドされる訳ではありません。
クラスターロールは、クラスターレベルで定義されるロールですが、クラスターレベルまたはプロジェクトレベルのいずれかでバインドできます。
5.1.2.1. クラスターロールの集計 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトの admin、edit、view、cluster-reader クラスターロールでは、クラスターロールの集約 がサポートされており、各ロールは新規ルール作成時に動的に更新されます。この機能は、カスタムリソースを作成して Kubernetes API を拡張する場合にのみ適用できます。
5.2. プロジェクトおよび namespace リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes namespace は、クラスターでスコープ設定するメカニズムを提供します。namespace の詳細は、Kubernetes ドキュメント を参照してください。
namespace は、次の一意のスコープを提供します。
- 基本的な命名の衝突を避けるための名前付きリソース。
- 信頼されるユーザーに委任された管理権限。
- コミュニティーリソースの消費を制限する機能。
システム内の大半のオブジェクトのスコープは namespace で設定されますが、一部はノードやユーザーを含め、除外され、namespace が設定されません。
プロジェクト は追加のアノテーションを持つ Kubernetes namespace であり、通常ユーザーのリソースへのアクセスが管理される中心的な手段です。プロジェクトはユーザーのコミュニティーが他のコミュニティーとは切り離してコンテンツを編成し、管理することを許可します。ユーザーには、管理者によってプロジェクトへのアクセスが付与される必要があり、許可される場合はプロジェクトを作成でき、それらの独自のプロジェクトへのアクセスが自動的に付与されます。
プロジェクトには、別個の name
、displayName
、および description
を設定できます。
-
必須の
name
はプロジェクトの一意の識別子であり、CLI ツールまたは API を使用する場合に最も表示されます。名前の最大長さは 63 文字です。 -
オプションの
displayName
は、Web コンソールでのプロジェクトの表示方法を示します (デフォルトはname
に設定される)。 -
オプションの
description
には、プロジェクトのさらに詳細な記述を使用でき、これも Web コンソールで表示できます。
各プロジェクトは、以下の独自のセットのスコープを設定します。
オブジェクト | 説明 |
---|---|
| Pod、サービス、レプリケーションコントローラーなど。 |
| ユーザーがオブジェクトに対してアクションを実行できるかどうかに関するルール。 |
| 制限を設定できるそれぞれの種類のオブジェクトのクォータ。 |
| サービスアカウントは、プロジェクトのオブジェクトへの指定されたアクセスで自動的に機能します。 |
dedicated-admin
ロールを持つ管理者は、プロジェクトを作成し、そのプロジェクトの管理者権限をユーザーコミュニティーのメンバーに委譲できます。また、dedicated-admin
ロールを持つ管理者は、開発者が独自のプロジェクトを作成することを許可できます。
開発者および管理者は、CLI または Web コンソールを使用してプロジェクトとの対話を実行できます。
5.3. デフォルトプロジェクト リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS にはデフォルトのプロジェクトが多数含まれ、openshift-
で始まるプロジェクトはユーザーにとって最も重要になります。これらのプロジェクトは、Pod として実行されるマスターコンポーネントおよび他のインフラストラクチャーコンポーネントをホストします。Critical Pod アノテーション を持つこれらの namespace で作成される Pod は Critical (重要) とみなされ、kubelet によるアドミッションが保証されます。これらの namespace のマスターコンポーネント用に作成された Pod には、すでに Critical のマークが付けられています。
デフォルトプロジェクトでワークロードを実行したり、デフォルトプロジェクトへのアクセスを共有したりしないでください。デフォルトのプロジェクトは、コアクラスターコンポーネントを実行するために予約されています。
デフォルトプロジェクトである default
、kube-public
、kube-system
、openshift
、openshift-infra
、openshift-node
、および openshift.io/run-level
ラベルが 0
または 1
に設定されているその他のシステム作成プロジェクトは、高い特権があるとみなされます。Pod セキュリティーアドミッション、Security Context Constraints、クラスターリソースクォータ、イメージ参照解決などのアドミッションプラグインに依存する機能は、高い特権を持つプロジェクトでは機能しません。
5.4. クラスターロールおよびバインディングの表示 リンクのコピーリンクがクリップボードにコピーされました!
oc
CLI で oc describe
コマンドを使用して、クラスターロールおよびバインディングを表示できます。
前提条件
-
oc
CLI がインストールされている。 - クラスターロールおよびバインディングを表示するパーミッションを取得している。
手順
クラスターロールおよびそれらの関連付けられたルールセットを表示するには、以下を実行します。
oc describe clusterrole.rbac
$ oc describe clusterrole.rbac
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 各種のロールにバインドされたユーザーおよびグループを示す、クラスターのロールバインディングの現在のセットを表示するには、以下を実行します。
oc describe clusterrolebinding.rbac
$ oc describe clusterrolebinding.rbac
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.5. ローカルのロールバインディングの表示 リンクのコピーリンクがクリップボードにコピーされました!
oc
CLI で oc describe
コマンドを使用して、ローカルロールおよびバインディングを表示できます。
前提条件
-
oc
CLI がインストールされている。 ローカルロールおよびバインディングを表示するパーミッションを取得している。
-
ローカルにバインドされた
admin
のデフォルトのクラスターロールを持つユーザーは、そのプロジェクトのロールおよびバインディングを表示し、管理できます。
-
ローカルにバインドされた
手順
現在のプロジェクトの各種のロールにバインドされたユーザーおよびグループを示す、ローカルのロールバインディングの現在のセットを表示するには、以下を実行します。
oc describe rolebinding.rbac
$ oc describe rolebinding.rbac
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 別のプロジェクトのローカルロールバインディングを表示するには、
-n
フラグをコマンドに追加します。oc describe rolebinding.rbac -n joe-project
$ oc describe rolebinding.rbac -n joe-project
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.6. ロールのユーザーへの追加 リンクのコピーリンクがクリップボードにコピーされました!
oc adm
管理者 CLI を使用してロールおよびバインディングを管理できます。
ロールをユーザーまたはグループにバインドするか、追加することにより、そのロールによって付与されるアクセスがそのユーザーまたはグループに付与されます。oc adm policy
コマンドを使用して、ロールのユーザーおよびグループへの追加、またはユーザーおよびグループからの削除を行うことができます。
デフォルトのクラスターロールのすべてを、プロジェクト内のローカルユーザーまたはグループにバインドできます。
手順
ロールを特定プロジェクトのユーザーに追加します。
oc adm policy add-role-to-user <role> <user> -n <project>
$ oc adm policy add-role-to-user <role> <user> -n <project>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、以下を実行して
admin
ロールをjoe
プロジェクトのalice
ユーザーに追加できます。oc adm policy add-role-to-user admin alice -n joe
$ oc adm policy add-role-to-user admin alice -n joe
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ヒントまたは、以下の YAML を適用してユーザーにロールを追加できます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力でローカルロールバインディングを確認し、追加の内容を確認します。
oc describe rolebinding.rbac -n <project>
$ oc describe rolebinding.rbac -n <project>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、
joe
プロジェクトのローカルロールバインディングを表示するには、以下を実行します。oc describe rolebinding.rbac -n joe
$ oc describe rolebinding.rbac -n joe
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
alice
ユーザーがadmins
RoleBinding
に追加されています。
5.7. ローカルロールの作成 リンクのコピーリンクがクリップボードにコピーされました!
プロジェクトのローカルロールを作成し、これをユーザーにバインドできます。
手順
プロジェクトのローカルロールを作成するには、以下のコマンドを実行します。
oc create role <name> --verb=<verb> --resource=<resource> -n <project>
$ oc create role <name> --verb=<verb> --resource=<resource> -n <project>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドで以下を指定します。
-
<name>
: ローカルのロール名です。 -
<verb>
: ロールに適用する動詞のコンマ区切りのリストです。 -
<resource>
: ロールが適用されるリソースです。 -
<project>
(プロジェクト名)
たとえば、ユーザーが
blue
プロジェクトで Pod を閲覧できるようにするローカルロールを作成するには、以下のコマンドを実行します。oc create role podview --verb=get --resource=pod -n blue
$ oc create role podview --verb=get --resource=pod -n blue
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
新規ロールをユーザーにバインドするには、以下のコマンドを実行します。
oc adm policy add-role-to-user podview user2 --role-namespace=blue -n blue
$ oc adm policy add-role-to-user podview user2 --role-namespace=blue -n blue
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.8. ローカルロールバインディングのコマンド リンクのコピーリンクがクリップボードにコピーされました!
以下の操作を使用し、ローカルのロールバインディングでのユーザーまたはグループの関連付けられたロールを管理する際に、プロジェクトは -n
フラグで指定できます。これが指定されていない場合には、現在のプロジェクトが使用されます。
ローカル RBAC 管理に以下のコマンドを使用できます。
コマンド | 説明 |
---|---|
| リソースに対してアクションを実行できるユーザーを示します。 |
| 指定されたロールを現在のプロジェクトの指定ユーザーにバインドします。 |
| 現在のプロジェクトの指定ユーザーから指定されたロールを削除します。 |
| 現在のプロジェクトの指定ユーザーと、そのすべてのロールを削除します。 |
| 指定されたロールを現在のプロジェクトの指定グループにバインドします。 |
| 現在のプロジェクトの指定グループから指定されたロールを削除します。 |
| 現在のプロジェクトの指定グループと、そのすべてのロールを削除します。 |
5.9. cluster-admin アクセス権限の付与 リンクのコピーリンクがクリップボードにコピーされました!
クラスターを作成したユーザーは、cluster-admin
ユーザーロールをアカウントに追加して、最大管理者権限を割り当てます。これらの権限は、クラスターの作成時に自動的にユーザーアカウントに割り当てられることはありません。
さらに、クラスターを作成したユーザーのみが、他の cluster-admin
または dedicated-admin
ユーザーにクラスターアクセスを付与できます。dedicated-admin
アクセスを持つユーザーの権限は少なくなります。ベストプラクティスとして、cluster-admin
ユーザーの数をできるだけ少なく制限できます。
前提条件
- アイデンティティープロバイダー (IDP) をクラスターに追加している。
- 作成するユーザーの IDP ユーザー名がある。
- クラスターにログインしている。
手順
ユーザーに
cluster-admin
権限を付与します。rosa grant user cluster-admin --user=<idp_user_name> --cluster=<cluster_name>
$ rosa grant user cluster-admin --user=<idp_user_name> --cluster=<cluster_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ユーザーがクラスター管理者としてリスト表示されていることを確認します。
rosa list users --cluster=<cluster_name>
$ rosa list users --cluster=<cluster_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
GROUP NAME cluster-admins rh-rosa-test-user dedicated-admins rh-rosa-test-user
GROUP NAME cluster-admins rh-rosa-test-user dedicated-admins rh-rosa-test-user
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.10. dedicated-admin アクセスの取り消し リンクのコピーリンクがクリップボードにコピーされました!
クラスターを作成したユーザーのみが、他の cluster-admin
または dedicated-admin
ユーザーにクラスターアクセスを付与できます。dedicated-admin
アクセスを持つユーザーの権限は少なくなります。ベストプラクティスとして、dedicated-admin
アクセスをほとんどの管理者に付与することができます。
前提条件
- アイデンティティープロバイダー (IDP) をクラスターに追加している。
- 作成するユーザーの IDP ユーザー名がある。
- クラスターにログインしている。
手順
以下のコマンドを実行して、ユーザーを
dedicated-admin
にプロモートします。rosa grant user dedicated-admin --user=<idp_user_name> --cluster=<cluster_name>
$ rosa grant user dedicated-admin --user=<idp_user_name> --cluster=<cluster_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、ユーザーに
dedicated-admin
アクセスがあることを確認します。oc get groups dedicated-admins
$ oc get groups dedicated-admins
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME USERS dedicated-admins rh-rosa-test-user
NAME USERS dedicated-admins rh-rosa-test-user
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記Forbidden
エラーは、dedicated-admin
権限を持たないユーザーがこのコマンドを実行する場合に表示されます。
5.10.1. 認証されていないグループのクラスターロールバインディング リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS 4.17 より前では、認証されていないグループでも一部のクラスターロールへのアクセスが許可されていました。Red Hat OpenShift Service on AWS 4.17 より前のバージョンから更新されたクラスターは、認証されていないグループに対してこのアクセスを保持します。
セキュリティー上の理由から、Red Hat OpenShift Service on AWS 4 では、認証されていないグループがクラスターロールにデフォルトでアクセスできません。
ユースケースによっては、クラスターロールに system:unauthenticated
を追加する必要があります。
クラスター管理者は、認証されていないユーザーを次のクラスターロールに追加できます。
-
system:scope-impersonation
-
system:webhook
-
system:oauth-token-deleter
-
self-access-reviewer
認証されていないアクセスを変更するときは、常に組織のセキュリティー標準に準拠していることを確認してください。
第6章 サービスアカウントの概要および作成 リンクのコピーリンクがクリップボードにコピーされました!
6.1. サービスアカウントの概要 リンクのコピーリンクがクリップボードにコピーされました!
サービスアカウントは、コンポーネントが API に直接アクセスできるようにする Red Hat OpenShift Service on AWS アカウントです。サービスアカウントは各プロジェクト内に存在する API オブジェクトです。サービスアカウントは、通常ユーザーの認証情報を共有せずに API アクセスを制御する柔軟な方法を提供します。
Red Hat OpenShift Service on AWS CLI または Web コンソールを使用する場合、API トークンは API に対する認証を行います。コンポーネントをサービスアカウントに関連付け、通常ユーザーの認証情報を使用せずにそれらが API にアクセスできるようにします。
各サービスアカウントのユーザー名は、そのプロジェクトおよび名前から派生します。
system:serviceaccount:<project>:<name>
system:serviceaccount:<project>:<name>
すべてのサービスアカウントは 2 つのグループのメンバーでもあります。
グループ | 説明 |
---|---|
system:serviceaccounts | システムのすべてのサービスアカウントが含まれます。 |
system:serviceaccounts:<project> | 指定されたプロジェクトのすべてのサービスアカウントが含まれます。 |
6.1.1. 自動的に生成されたイメージプルシークレット リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、Red Hat OpenShift Service on AWS は各サービスアカウントに対してイメージプルシークレットを作成します。
Red Hat OpenShift Service on AWS 4.16 より前では、作成されたサービスアカウントごとに、長期間有効なサービスアカウント API トークンシークレットも生成されていました。Red Hat OpenShift Service on AWS 4.16 以降では、このサービスアカウント API トークンシークレットは作成されなくなりました。
4 にアップグレードした後も、既存の長期有効サービスアカウント API トークンシークレットは削除されず、引き続き機能します。クラスターで使用されている長期有効 API トークンを検出する方法、または不要な場合に削除する方法は、Red Hat ナレッジベースの記事 Long-lived service account API tokens in OpenShift Container Platform を参照してください。
このイメージプルシークレットは、OpenShift イメージレジストリーをクラスターのユーザー認証および認可システムに統合するために必要です。
ただし、ImageRegistry
機能を有効にしていない場合、または Cluster Image Registry Operator の設定で統合済みの OpenShift イメージレジストリーを無効にしている場合、イメージプルシークレットはサービスアカウントごとに生成されません。
統合済みの OpenShift イメージレジストリーを有効にしていたクラスターでそれを無効にすると、以前に生成されたイメージプルシークレットが自動的に削除されます。
6.2. サービスアカウントの作成 リンクのコピーリンクがクリップボードにコピーされました!
サービスアカウントをプロジェクトで作成し、これをロールにバインドすることでパーミッションを付与できます。
手順
オプション: サービスアカウントを現在のプロジェクトで表示するには、以下を実行します。
oc get sa
$ oc get sa
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME SECRETS AGE builder 1 2d default 1 2d deployer 1 2d
NAME SECRETS AGE builder 1 2d default 1 2d deployer 1 2d
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新規サービスアカウントを現在のプロジェクトで作成するには、以下を実行します。
oc create sa <service_account_name>
$ oc create sa <service_account_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 別のプロジェクトでサービスアカウントを作成するには、
-n <project_name>
を指定します。
出力例
serviceaccount "robot" created
serviceaccount "robot" created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ヒントまたは、以下の YAML を適用してサービスアカウントを作成できます。
apiVersion: v1 kind: ServiceAccount metadata: name: <service_account_name> namespace: <current_project>
apiVersion: v1 kind: ServiceAccount metadata: name: <service_account_name> namespace: <current_project>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: サービスアカウントのシークレットを表示します。
oc describe sa robot
$ oc describe sa robot
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3. ロールのサービスアカウントへの付与 リンクのコピーリンクがクリップボードにコピーされました!
ロールをサービスアカウントに付与する方法は、ロールを通常ユーザーアカウントに付与する方法と同じです。
現在のプロジェクトのサービスアカウントを変更できます。たとえば、
view
ロールをtop-secret
プロジェクトのrobot
サービスアカウントに追加するには、以下を実行します。oc policy add-role-to-user view system:serviceaccount:top-secret:robot
$ oc policy add-role-to-user view system:serviceaccount:top-secret:robot
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ヒントまたは、以下の YAML を適用してロールを追加できます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow アクセスをプロジェクトの特定のサービスアカウントに付与することもできます。たとえば、サービスアカウントが属するプロジェクトから、
-z
フラグを使用し、<service_account_name>
を指定します。oc policy add-role-to-user <role_name> -z <service_account_name>
$ oc policy add-role-to-user <role_name> -z <service_account_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要プロジェクトの特定のサービスアカウントにアクセスを付与する必要がある場合には、
-z
フラグを使用します。このフラグを使用することにより、アクセスが指定されたサービスアカウントのみに付与することができます。ヒントまたは、以下の YAML を適用してロールを追加できます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 別の namespace を変更するには、
-n
オプションを使用して、以下の例にあるように、適用先のプロジェクト namespace を指定します。たとえば、すべてのプロジェクトのすべてのサービスアカウントが
my-project
プロジェクトのリソースを表示できるようにするには、以下を実行します。oc policy add-role-to-group view system:serviceaccounts -n my-project
$ oc policy add-role-to-group view system:serviceaccounts -n my-project
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ヒントまたは、以下の YAML を適用してロールを追加できます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow managers
プロジェクトのすべてのサービスアカウントがmy-project
プロジェクトのリソースを編集できるようにするには、以下を実行します。oc policy add-role-to-group edit system:serviceaccounts:managers -n my-project
$ oc policy add-role-to-group edit system:serviceaccounts:managers -n my-project
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ヒントまたは、以下の YAML を適用してロールを追加できます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第7章 アプリケーションでのサービスアカウントの使用 リンクのコピーリンクがクリップボードにコピーされました!
7.1. サービスアカウントの概要 リンクのコピーリンクがクリップボードにコピーされました!
サービスアカウントは、コンポーネントが API に直接アクセスできるようにする Red Hat OpenShift Service on AWS アカウントです。サービスアカウントは各プロジェクト内に存在する API オブジェクトです。サービスアカウントは、通常ユーザーの認証情報を共有せずに API アクセスを制御する柔軟な方法を提供します。
Red Hat OpenShift Service on AWS CLI または Web コンソールを使用する場合、API トークンは API に対する認証を行います。コンポーネントをサービスアカウントに関連付け、通常ユーザーの認証情報を使用せずにそれらが API にアクセスできるようにします。
各サービスアカウントのユーザー名は、そのプロジェクトおよび名前から派生します。
system:serviceaccount:<project>:<name>
system:serviceaccount:<project>:<name>
すべてのサービスアカウントは 2 つのグループのメンバーでもあります。
グループ | 説明 |
---|---|
system:serviceaccounts | システムのすべてのサービスアカウントが含まれます。 |
system:serviceaccounts:<project> | 指定されたプロジェクトのすべてのサービスアカウントが含まれます。 |
7.2. デフォルトのサービスアカウント リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS クラスターには、クラスター管理用のデフォルトのサービスアカウントが含まれ、各プロジェクトのサービスアカウントは追加で生成されます。
7.2.1. デフォルトのクラスターサービスアカウント リンクのコピーリンクがクリップボードにコピーされました!
一部のインフラストラクチャーコントローラーは、サービスアカウント認証情報を使用して実行されます。以下のサービスアカウントは、サーバーの起動時に Red Hat OpenShift Service on AWS インフラストラクチャープロジェクト (openshift-infra
) に作成され、クラスター全体で以下のロールが付与されます。
サービスアカウント | 説明 |
---|---|
|
|
|
|
|
|
7.2.2. デフォルトのプロジェクトサービスアカウントおよびロール リンクのコピーリンクがクリップボードにコピーされました!
3 つのサービスアカウントが各プロジェクトで自動的に作成されます。
サービスアカウント | 使用法 |
---|---|
|
ビルド Pod で使用されます。 注記
|
|
デプロイメント Pod によって使用され、 注記
|
| 別のサービスアカウントが指定されていない限り、その他すべての Pod を実行するために使用されます。 |
プロジェクトのすべてのサービスアカウントには system:image-puller
ロールが付与されます。このロールがあることで、内部コンテナーイメージレジストリーを使用してイメージをイメージストリームからプルできます。
7.2.3. 自動的に生成されたイメージプルシークレット リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、Red Hat OpenShift Service on AWS は各サービスアカウントに対してイメージプルシークレットを作成します。
Red Hat OpenShift Service on AWS 4.16 より前では、作成されたサービスアカウントごとに、長期間有効なサービスアカウント API トークンシークレットも生成されていました。Red Hat OpenShift Service on AWS 4.16 以降では、このサービスアカウント API トークンシークレットは作成されなくなりました。
4 にアップグレードした後も、既存の長期有効サービスアカウント API トークンシークレットは削除されず、引き続き機能します。クラスターで使用されている長期有効 API トークンを検出する方法、または不要な場合に削除する方法は、Red Hat ナレッジベースの記事 Long-lived service account API tokens in OpenShift Container Platform を参照してください。
このイメージプルシークレットは、OpenShift イメージレジストリーをクラスターのユーザー認証および認可システムに統合するために必要です。
ただし、ImageRegistry
機能を有効にしていない場合、または Cluster Image Registry Operator の設定で統合済みの OpenShift イメージレジストリーを無効にしている場合、イメージプルシークレットはサービスアカウントごとに生成されません。
統合済みの OpenShift イメージレジストリーを有効にしていたクラスターでそれを無効にすると、以前に生成されたイメージプルシークレットが自動的に削除されます。
7.3. サービスアカウントの作成 リンクのコピーリンクがクリップボードにコピーされました!
サービスアカウントをプロジェクトで作成し、これをロールにバインドすることでパーミッションを付与できます。
手順
オプション: サービスアカウントを現在のプロジェクトで表示するには、以下を実行します。
oc get sa
$ oc get sa
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME SECRETS AGE builder 1 2d default 1 2d deployer 1 2d
NAME SECRETS AGE builder 1 2d default 1 2d deployer 1 2d
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新規サービスアカウントを現在のプロジェクトで作成するには、以下を実行します。
oc create sa <service_account_name>
$ oc create sa <service_account_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 別のプロジェクトでサービスアカウントを作成するには、
-n <project_name>
を指定します。
出力例
serviceaccount "robot" created
serviceaccount "robot" created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ヒントまたは、以下の YAML を適用してサービスアカウントを作成できます。
apiVersion: v1 kind: ServiceAccount metadata: name: <service_account_name> namespace: <current_project>
apiVersion: v1 kind: ServiceAccount metadata: name: <service_account_name> namespace: <current_project>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: サービスアカウントのシークレットを表示します。
oc describe sa robot
$ oc describe sa robot
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第8章 サービスアカウントの OAuth クライアントとしての使用 リンクのコピーリンクがクリップボードにコピーされました!
8.1. OAuth クライアントとしてのサービスアカウント リンクのコピーリンクがクリップボードにコピーされました!
サービスアカウントは、OAuth クライアントの制限されたフォームで使用できます。サービスアカウントは一部の基本ユーザー情報へのアクセスを許可するスコープのサブセットと、サービスアカウント自体の namespace 内のロールベースの権限のみを要求できます。
-
user:info
-
user:check-access
-
role:<any_role>:<service_account_namespace>
-
role:<any_role>:<service_account_namespace>:!
サービスアカウントを OAuth クライアントとして使用する場合:
-
client_id
はsystem:serviceaccount:<service_account_namespace>:<service_account_name>
です。 client_secret
には、サービスアカウントの API トークンのいずれかを指定できます。以下に例を示します。oc sa get-token <service_account_name>
$ oc sa get-token <service_account_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
WWW-Authenticate
チャレンジを取得するには、サービスアカウントのserviceaccounts.openshift.io/oauth-want-challenges
アノテーションをtrue
に設定します。 -
redirect_uri
は、サービスアカウントのアノテーションに一致する必要があります。
8.1.1. OAuth クライアントとしてのサービスアカウントの URI のリダイレクト リンクのコピーリンクがクリップボードにコピーされました!
アノテーションキーには、以下のように接頭辞 serviceaccounts.openshift.io/oauth-redirecturi.
または serviceaccounts.openshift.io/oauth-redirectreference.
が含まれる必要があります。
serviceaccounts.openshift.io/oauth-redirecturi.<name>
serviceaccounts.openshift.io/oauth-redirecturi.<name>
最も単純なフォームでは、アノテーションは有効なリダイレクト URI を直接指定するために使用できます。以下に例を示します。
"serviceaccounts.openshift.io/oauth-redirecturi.first": "https://example.com" "serviceaccounts.openshift.io/oauth-redirecturi.second": "https://other.com"
"serviceaccounts.openshift.io/oauth-redirecturi.first": "https://example.com"
"serviceaccounts.openshift.io/oauth-redirecturi.second": "https://other.com"
上記の例の first
および second
ポストフィックスは 2 つの有効なリダイレクト URI を分離するために使用されます。
さらに複雑な設定では、静的なリダイレクト URI のみでは不十分な場合があります。たとえば、ルートのすべての Ingress が有効とみなされる必要があるかもしれません。この場合は、serviceaccounts.openshift.io/oauth-redirectreference.
接頭辞を使用した動的なリダイレクト URI を使用できます。
以下に例を示します。
"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"
"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"
このアノテーションの値にはシリアライズされた JSON データが含まれるため、これを拡張フォーマットで表示するとより容易になります。
ここでは、OAuthRedirectReference
により jenkins
という名前のルートを参照できます。そのため、そのルートのすべての Ingress は有効とみなされます。OAuthRedirectReference
の詳細な仕様は以下のようになります。
アノテーションはどちらも、接頭辞も組み合わせて、参照オブジェクトで提供されるデータをオーバーライドできます。以下に例を示します。
"serviceaccounts.openshift.io/oauth-redirecturi.first": "custompath" "serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"
"serviceaccounts.openshift.io/oauth-redirecturi.first": "custompath"
"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"
first
ポストフィックスはアノテーションを関連付けるために使用されます。jenkins
ルートに https://example.com
の Ingress がある場合に、https://example.com/custompath
は有効とみなされますが、https://example.com
は有効とみなされません。オーバーライドするデータを部分的に指定するためのフォーマットは以下のようになります。
型 | 構文 |
---|---|
スキーム | "https://" |
ホスト名 | "//website.com" |
ポート | "//:8000" |
パス | "examplepath" |
ホスト名のオーバーライドを指定すると、参照されるオブジェクトのホスト名データが置き換わりますが、これは望ましい動作ではありません。
上記の構文のいずれの組み合わせも、以下のフォーマットを使用して実行できます。
<scheme:>//<hostname><:port>/<path>
同じオブジェクトを複数回参照して、柔軟性を向上することができます。
"serviceaccounts.openshift.io/oauth-redirecturi.first": "custompath" "serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}" "serviceaccounts.openshift.io/oauth-redirecturi.second": "//:8000" "serviceaccounts.openshift.io/oauth-redirectreference.second": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"
"serviceaccounts.openshift.io/oauth-redirecturi.first": "custompath"
"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"
"serviceaccounts.openshift.io/oauth-redirecturi.second": "//:8000"
"serviceaccounts.openshift.io/oauth-redirectreference.second": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"
jenkins
という名前のルートに https://example.com
の Ingress がある場合には、https://example.com:8000
と https://example.com/custompath
の両方が有効とみなされます。
必要な動作を得るために、静的で動的なアノテーションを同時に使用できます。
"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}" "serviceaccounts.openshift.io/oauth-redirecturi.second": "https://other.com"
"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"
"serviceaccounts.openshift.io/oauth-redirecturi.second": "https://other.com"
第9章 サービスアカウントの AWS IAM ロールの引き受け リンクのコピーリンクがクリップボードにコピーされました!
AWS Security Token Service (STS) を使用する Red Hat OpenShift Service on AWS では、OpenShift API サーバーを有効にして、Pod 内の AWS Identity and Access Management (IAM) ロールの引き受けに使用できる署名付きサービスアカウントトークンを投影できます。想定した IAM ロールに必要な AWS パーミッションがある場合は、Pod は、一時的な STS 認証を使用して、AWS 操作を実行し、AWS API に対して認証できます。
Pod ID Webhook を使用してサービスアカウントトークンを生成し、独自のワークロードに対する AWS Identity and Access Management (IAM) ロールを推測できます。想定された IAM ロールに必要な AWS アクセス許可がある場合、Pod は一時的な STS 認証情報を使用して AWS SDK 操作を実行できます。
9.1. サービスアカウントが SRE 所有のプロジェクトで AWS IAM ロールを引き受ける方法 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS クラスターをインストールすると、クラスター固有の Operator AWS Identity and Access Management (IAM) ロールが作成されます。これらの IAM ロールにより、ROSA cluster Operator がコア OpenShift 機能を実行できるようになります。
クラスター Operator はサービスアカウントを使用して IAM ロールを引き受けます。サービスアカウントが IAM ロールを引き受けると、クラスター Operator の Pod でサービスアカウントが使用するための一時的な AWS STS 認証情報が提供されます。引き受けたロールに必要な AWS 権限がある場合、サービスアカウントは Pod で AWS SDK 操作を実行できます。
Red Hat SRE 所有プロジェクトで AWS IAM ロールを引き受けるためのワークフロー
次の図は、SRE 所有プロジェクトで AWS IAM ロールを引き受けるためのワークフローを示しています。
図9.1 SRE 所有プロジェクトで AWS IAM ロールを引き受けるワークフロー
ワークフローには次の段階があります。
クラスター Operator が実行する各プロジェクト内で、Operator のデプロイメント仕様には、投影されたサービスアカウントトークンのボリュームマウントと、Pod の AWS 認証情報設定が含まれるシークレットがあります。トークンは、オーディエンスおよび時間の制限があります。ROSA は 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 クラスターを使用する ROSA では、インストール中に 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 認証情報を返します。
9.2. サービスアカウントがユーザー定義プロジェクトで AWS IAM ロールを引き受ける方法 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS クラスターをインストールすると、Pod アイデンティティー Webhook リソースがデフォルトで含まれます。
Pod ID Webhook を使用して、ユーザー定義プロジェクトのサービスアカウントが、同じプロジェクトの Pod で AWS Identity and Access Management (IAM) ロールを引き受けることができます。IAM ロールを引き受けると、Pod 内のサービスアカウントが使用する一時的な STS 認証情報が提供されます。引き受けたロールに必要な AWS 権限がある場合、サービスアカウントは Pod で AWS SDK 操作を実行できます。
Pod の Pod ID Webhook を有効にするには、プロジェクトで eks.amazonaws.com/role-arn
アノテーションを使用してサービスアカウントを作成する必要があります。アノテーションは、サービスアカウントが引き受ける AWS IAM ロールの Amazon Resource Name (ARN) を参照する必要があります。また、Pod
仕様でサービスアカウントを参照し、サービスアカウントと同じプロジェクトに Pod をデプロイする必要があります。
ユーザー定義プロジェクトでの Pod ID Webhook ワークフロー
次の図は、ユーザー定義プロジェクトでの Pod ID Webhook ワークフローを示しています。
図9.2 ユーザー定義プロジェクトでの Pod ID Webhook ワークフロー
ワークフローには次の段階があります。
-
ユーザー定義のプロジェクト内で、ユーザーは
eks.amazonaws.com/role-arn
アノテーションを含むサービスアカウントを作成します。アノテーションは、サービスアカウントが引き受ける AWS IAM ロールの ARN を指します。 アノテーション付きのサービスアカウントを参照する設定を使用して Pod が同じプロジェクトにデプロイされると、Pod ID Webhook により Pod が変更になります。ミューテーションは、
Pod
またはDeployment
リソース設定で指定する必要なく、次のコンポーネントを Pod に挿入します。-
AWS SDK オペレーションを実行するために必要なアクセス権を持つ IAM ロールの ARN を含む
$AWS_ARN_ROLE
環境変数。 -
サービスアカウントの OpenID Connect (OIDC) トークンへの Pod 内のフルパスを含む
$AWS_WEB_IDENTITY_TOKEN_FILE
環境変数。フルパスは/var/run/secrets/eks.amazonaws.com/serviceaccount/token
です。 -
マウントポイント
/var/run/secrets/eks.amazonaws.com/serviceaccount
にマウントされたaws-iam-token
ボリューム。token
という名前の OIDC トークンファイルがボリュームに含まれています。
-
AWS SDK オペレーションを実行するために必要なアクセス権を持つ IAM ロールの ARN を含む
OIDC トークンは、Pod から OIDC プロバイダーに渡されます。次の要件が満たされている場合は、プロバイダーがサービスアカウント ID を認証します。
- ID 署名は有効であり、秘密鍵によって署名されています。
sts.amazonaws.com
オーディエンスは OIDC トークンにリストされており、OIDC プロバイダーで設定されたオーディエンスと一致します。注記Pod ID Webhook は、デフォルトで
sts.amazonaws.com
オーディエンスを OIDC トークンに適用します。- OIDC トークンの有効期限が切れていません。
- トークンの発行者の値には、OIDC プロバイダーの URL が含まれています。
- プロジェクトとサービスアカウントが、引き受ける IAM ロールの信頼ポリシーのスコープ内にある場合は、認可が成功します。
- 認証と認可が成功すると、セッショントークンの形式の一時的な AWS STS 認証情報が Pod に渡され、サービスアカウントで使用できるようになります。認証情報を使用することで、IAM ロールで有効になっている AWS アクセス許可がサービスアカウントに一時的に付与されます。
- Pod で AWS SDK オペレーションを実行すると、サービスアカウントは一時的な STS 認証情報を AWS API に提供して、その ID を確認します。
9.3. 独自の Pod で AWS IAM ロールを引き受ける リンクのコピーリンクがクリップボードにコピーされました!
このセクションの手順に従って、ユーザー定義のプロジェクトにデプロイされた Pod でサービスアカウントが AWS Identity and Access Management (IAM) ロールを引き受けられるようにします。
AWS IAM ロール、サービスアカウント、AWS SDK を含むコンテナーイメージ、イメージを使用してデプロイされた Pod など、必要なリソースを作成できます。この例では、AWS Boto3 SDK for Python が使用されています。また、Pod ID Webhook が AWS 環境変数、ボリュームマウント、およびトークンボリュームを Pod に変更することを確認することもできます。さらに、サービスアカウントが Pod で AWS IAM ロールを引き受け、AWS SDK オペレーションを正常に実行できることを確認できます。
9.3.1. サービスアカウントの AWS IAM ロールの設定 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS クラスターのサービスアカウントが引き受ける AWS Identity and Access Management (IAM) ロールを作成します。サービスアカウントが Pod で AWS SDK オペレーションを実行するために必要なアクセス許可をアタッチします。
前提条件
- AWS アカウントに IAM ロールをインストールして設定するために必要なアクセス許可がある。
- AWS Security Token Service (STS) を使用する Red Hat OpenShift Service on AWS クラスターにアクセスできる。管理者レベルのユーザー権限は必要ありません。
STS クラスターを使用する Red Hat OpenShift Service on AWS でサービスアカウント発行者として設定されている OpenID Connect (OIDC) プロバイダーの Amazon Resource Name (ARN) がある。
注記STS クラスターを使用する Red Hat OpenShift Service on AWS では、インストール中に OIDC プロバイダーが作成され、デフォルトでサービスアカウント発行者として設定されます。OIDC プロバイダーの ARN がわからない場合は、クラスター管理者に問い合わせてください。
-
AWS CLI (
aws
) をインストールしている。
手順
次の JSON 設定を使用して、
trust-policy.json
という名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<oidc_provider_arn>
を OIDC プロバイダーの ARN に置き換えます (例:arn:aws:iam::<aws_account_id>:oidc-provider/rh-oidc.s3.us-east-1.amazonaws.com/1v3r0n44npxu4g58so46aeohduomfres
)。ARN は、rosa describe cluster
CLI コマンドを使用して取得できます。- 2
- 指定されたプロジェクトとサービスアカウントにロールを制限します。
<oidc_provider_name>
を OIDC プロバイダーの名前に置き換えます (例:rh-oidc.s3.us-east-1.amazonaws.com/1v3r0n44npxu4g58so46aeohduomfres
)。<project_name>:<service_account_name>
を実際のプロジェクト名とサービスアカウント名に置き換えます (例:my-project:test-service-account
)。注記または、
"<oidc_provider_name>:sub": "system:serviceaccount:<project_name>:*"
を使用して、指定したプロジェクト内の任意のサービスアカウントにロールを制限できます。*
ワイルドカードを指定する場合は、前の行でStringEquals
をStringLike
に置き換える必要があります。
trust-policy.json
ファイルで定義されている信頼ポリシーを使用する AWS IAM ロールを作成します。aws iam create-role \ --role-name <aws_iam_role_name> \ --assume-role-policy-document file://trust-policy.json
$ aws iam create-role \ --role-name <aws_iam_role_name> \
1 --assume-role-policy-document file://trust-policy.json
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
ROLE arn:aws:iam::<aws_account_id>:role/<aws_iam_role_name> 2022-09-28T12:03:17+00:00 / AQWMS3TB4Z2N3SH7675JK <aws_iam_role_name> ASSUMEROLEPOLICYDOCUMENT 2012-10-17 STATEMENT sts:AssumeRoleWithWebIdentity Allow STRINGEQUALS system:serviceaccount:<project_name>:<service_account_name> PRINCIPAL <oidc_provider_arn>
ROLE arn:aws:iam::<aws_account_id>:role/<aws_iam_role_name> 2022-09-28T12:03:17+00:00 / AQWMS3TB4Z2N3SH7675JK <aws_iam_role_name> ASSUMEROLEPOLICYDOCUMENT 2012-10-17 STATEMENT sts:AssumeRoleWithWebIdentity Allow STRINGEQUALS system:serviceaccount:<project_name>:<service_account_name> PRINCIPAL <oidc_provider_arn>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力でロールの ARN を保持します。ロール ARN の形式は
arn:aws:iam::<aws_account_id>:role/<aws_iam_role_name>
です。サービスアカウントが Pod で AWS SDK 操作を実行するときに必要なマネージド AWS アクセス許可をアタッチします。
aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess \ --role-name <aws_iam_role_name>
$ aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess \
1 --role-name <aws_iam_role_name>
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - オプション: カスタム属性または権限境界をロールに追加します。詳細は、AWS ドキュメントの AWS サービスにアクセス許可を委任するロールの作成 を参照してください。
9.3.2. プロジェクトでサービスアカウントを作成する リンクのコピーリンクがクリップボードにコピーされました!
ユーザー定義プロジェクトにサービスアカウントを追加します。サービスアカウントに引き受けさせる AWS Identity and Access Management (IAM) ロールの Amazon Resource Name (ARN) を参照する eks.amazonaws.com/role-arn
アノテーションをサービスアカウント設定に含めます。
前提条件
- サービスアカウントの AWS IAM ロールを作成している。詳細は、サービスアカウントの AWS IAM ロールの設定 を参照してください。
- AWS Security Token Service (STS) クラスターを使用して Red Hat OpenShift Service on AWS にアクセスできます。管理者レベルのユーザー権限は必要ありません。
-
OpenShift CLI (
oc
) がインストールされている。
手順
Red Hat OpenShift Service on AWS クラスターで、プロジェクトを作成します。
oc new-project <project_name>
$ oc new-project <project_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<project-name>
は、プロジェクト名に置き換えます。この名前は、AWS IAM ロールの設定で指定したプロジェクト名と一致する必要があります。
注記プロジェクトが作成されると、自動的にプロジェクトに切り替わります。
次のサービスアカウント設定で、
test-service-account.yaml
という名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<service_account_name>
をサービスアカウントの名前に置き換えます。この名前は、AWS IAM ロールの設定で指定したサービスアカウント名と一致させる必要があります。- 2
<project-name>
は、プロジェクト名に置き換えます。この名前は、AWS IAM ロールの設定で指定したプロジェクト名と一致する必要があります。- 3
- サービスアカウントが Pod 内で使用するために想定する AWS IAM ロールの ARN を指定します。
<aws_iam_role_arn>
を、サービスアカウント用に作成した AWS IAM ロールの ARN に置き換えます。ロール ARN の形式はarn:aws:iam::<aws_account_id>:role/<aws_iam_role_name>
です。
プロジェクトにサービスアカウントを作成します。
oc create -f test-service-account.yaml
$ oc create -f test-service-account.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
serviceaccount/<service_account_name> created
serviceaccount/<service_account_name> created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービスアカウントの詳細を確認します。
oc describe serviceaccount <service_account_name>
$ oc describe serviceaccount <service_account_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<service_account_name>
をサービスアカウントの名前に置き換えます。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.3.3. サンプル AWS SDK コンテナーイメージの作成 リンクのコピーリンクがクリップボードにコピーされました!
この手順のステップでは、AWS SDK を含むコンテナーイメージを作成する方法の例を示します。
例の手順では、Podman を使用してコンテナーイメージを作成し、Quay.io を使用してイメージをホストします。Quay.io の詳細は、Quay.io の使用を開始する を参照してください。コンテナーイメージを使用して、AWS SDK オペレーションを実行できる Pod をデプロイできます。
この手順例では、AWS Boto3 SDK for Python がコンテナーイメージにインストールされます。AWS Boto3 SDK のインストールと使用の詳細は、AWS Boto3 ドキュメント を参照してください。その他の AWS SDK の詳細は、AWS ドキュメントの AWS SDKs and Tools Reference Guide を参照してください。
前提条件
- インストールホストに Podman をインストールしている。
- Quay.io ユーザーアカウントを持っている。
手順
次の設定を
Containerfile
という名前のファイルに追加します。FROM ubi9/ubi RUN dnf makecache && dnf install -y python3-pip && dnf clean all && pip3 install boto3>=1.15.0
FROM ubi9/ubi
1 RUN dnf makecache && dnf install -y python3-pip && dnf clean all && pip3 install boto3>=1.15.0
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow ファイルを含むディレクトリーから、
awsboto3sdk
という名前のコンテナーイメージをビルドします。podman build -t awsboto3sdk .
$ podman build -t awsboto3sdk .
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Quay.io にログインします。
podman login quay.io
$ podman login quay.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Quay.io へのアップロードの準備として、イメージにタグを付けます。
podman tag localhost/awsboto3sdk quay.io/<quay_username>/awsboto3sdk:latest
$ podman tag localhost/awsboto3sdk quay.io/<quay_username>/awsboto3sdk:latest
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<quay_username>
を Quay.io ユーザー名に置き換えます。
タグ付けされたコンテナーイメージを Quay.io にプッシュします。
podman push quay.io/<quay_username>/awsboto3sdk:latest
$ podman push quay.io/<quay_username>/awsboto3sdk:latest
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<quay_username>
を Quay.io ユーザー名に置き換えます。
イメージを含む Quay.io リポジトリーを公開します。これによりイメージが公開され、Red Hat OpenShift Service on AWS クラスターに Pod をデプロイするために使用できるようになります。
- https://quay.io/ で、イメージを含むリポジトリーの Repository Settings ページに移動します。
- Make Public をクリックして、リポジトリーを公開します。
9.3.4. AWS SDK を含む Pod のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
AWS SDK を含むコンテナーイメージからユーザー定義プロジェクトに Pod をデプロイします。Pod 設定で、eks.amazonaws.com/role-arn
アノテーションを含むサービスアカウントを指定します。
Pod のサービスアカウント参照が配置されると、Pod ID Webhook が AWS 環境変数、ボリュームマウント、およびトークンボリュームを Pod に挿入します。Pod のミューテーションにより、サービスアカウントは Pod で AWS IAM ロールを自動的に引き受けることができます。
前提条件
- サービスアカウントの AWS Identity and Access Management (IAM) ロールを作成している。詳細は、サービスアカウントの AWS IAM ロールの設定 を参照してください。
- AWS Security Token Service (STS) を使用する Red Hat OpenShift Service on AWS クラスターにアクセスできる。管理者レベルのユーザー権限は必要ありません。
-
OpenShift CLI (
oc
) がインストールされている。 -
サービスアカウントが引き受ける IAM ロールの Amazon Resource Name (ARN) を参照する
eks.amazonaws.com/role-arn
アノテーションを含むサービスアカウントをプロジェクトに作成している。 AWS SDK を含むコンテナーイメージがあり、そのイメージをクラスターで使用できる。詳細な手順は、サンプルの AWS SDK コンテナーイメージの作成 を参照してください。
注記この手順例では、AWS Boto3 SDK for Python が使用されています。AWS Boto3 SDK のインストールと使用の詳細は、AWS Boto3 ドキュメント を参照してください。その他の AWS SDK の詳細は、AWS ドキュメントの AWS SDKs and Tools Reference Guide を参照してください。
手順
次の Pod 設定で
awsboto3sdk-pod.yaml
という名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<project-name>
は、プロジェクト名に置き換えます。この名前は、AWS IAM ロールの設定で指定したプロジェクト名と一致する必要があります。- 2
- Pod の名前を指定します。
- 3
<service_account_name>
を、AWS IAM ロールを引き受けるように設定されたサービスアカウントの名前に置き換えます。この名前は、AWS IAM ロールの設定で指定したサービスアカウント名と一致させる必要があります。- 4
awsboto3sdk
コンテナーイメージの場所を指定します。<quay_username>
を Quay.io ユーザー名に置き換えます。- 5
- この Pod 設定の例では、この行は Pod を 100000 秒間実行し続け、Pod で直接検証テストを有効にします。詳細な検証手順は、Pod で想定される IAM ロールの検証 を参照してください。
awsboto3sdk
Pod をデプロイします。oc create -f awsboto3sdk-pod.yaml
$ oc create -f awsboto3sdk-pod.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
pod/awsboto3sdk created
pod/awsboto3sdk created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.3.5. Pod で想定される IAM ロールを確認する リンクのコピーリンクがクリップボードにコピーされました!
プロジェクトに awsboto3sdk
Pod をデプロイした後、Pod ID Webhook が Pod を変更したことを確認します。必要な AWS 環境変数、ボリュームマウント、および OIDC トークンボリュームが Pod 内に存在することを確認します。
Pod で AWS SDK オペレーションを実行するときに、サービスアカウントが AWS アカウントの AWS Identity and Access Management (IAM) ロールを引き受けていることを確認することもできます。
前提条件
- サービスアカウントの AWS IAM ロールを作成している。詳細は、サービスアカウントの AWS IAM ロールの設定 を参照してください。
- AWS Security Token Service (STS) を使用する Red Hat OpenShift Service on AWS クラスターにアクセスできる。管理者レベルのユーザー権限は必要ありません。
-
OpenShift CLI (
oc
) がインストールされている。 -
サービスアカウントが引き受ける IAM ロールの Amazon Resource Name (ARN) を参照する
eks.amazonaws.com/role-arn
アノテーションを含むサービスアカウントをプロジェクトに作成している。 AWS SDK を含むユーザー定義プロジェクトに Pod をデプロイしている。Pod は、Pod ID Webhook を使用するサービスアカウントを参照して、AWS SDK オペレーションの実行に必要な AWS IAM ロールを引き受けます。詳細な手順は、AWS SDK を含む Pod のデプロイ を参照してください。
注記この手順例では、AWS Boto3 SDK for Python を含む Pod が使用されます。AWS Boto3 SDK のインストールと使用の詳細は、AWS Boto3 ドキュメント を参照してください。その他の AWS SDK の詳細は、AWS ドキュメントの AWS SDKs and Tools Reference Guide を参照してください。
手順
AWS 環境変数、ボリュームマウント、および OIDC トークンボリュームが、デプロイされた
awsboto3sdk
Pod の説明にリストされていることを確認します。oc describe pod awsboto3sdk
$ oc describe pod awsboto3sdk
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Pod ID Webhook によって Pod に挿入された
AWS_ROLE_ARN
環境変数を一覧表示します。この変数には、サービスアカウントが引き受ける AWS IAM ロールの ARN が含まれます。 - 2
- Pod ID Webhook によって Pod に挿入された
AWS_WEB_IDENTITY_TOKEN_FILE
環境変数を一覧表示します。この変数には、サービスアカウントの ID を確認するために使用される OIDC トークンの完全なパスが含まれています。 - 3
- Pod ID Webhook によって Pod に挿入されたボリュームマウントを一覧表示します。
- 4
/var/run/secrets/eks.amazonaws.com/serviceaccount
マウントポイントにマウントされているaws-iam-token
ボリュームを一覧表示します。ボリュームには、AWS IAM ロールを引き受けるためにサービスアカウントを認証するために使用される OIDC トークンが含まれています。
awsboto3sdk
Pod でインタラクティブターミナルを起動します。oc exec -ti awsboto3sdk -- /bin/sh
$ oc exec -ti awsboto3sdk -- /bin/sh
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pod のインタラクティブターミナルで、Pod ID Webhook により
$AWS_ROLE_ARN
環境変数が Pod に変更されたことを確認します。echo $AWS_ROLE_ARN
$ echo $AWS_ROLE_ARN
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
arn:aws:iam::<aws_account_id>:role/<aws_iam_role_name>
arn:aws:iam::<aws_account_id>:role/<aws_iam_role_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 出力では、AWS SDK オペレーションを実行するために必要なアクセス許可を持つ AWS IAM ロールの ARN を指定する必要があります。
Pod のインタラクティブターミナルで、Pod ID Webhook によって
$AWS_WEB_IDENTITY_TOKEN_FILE
環境変数が Pod に変更されたことを確認します。echo $AWS_WEB_IDENTITY_TOKEN_FILE
$ echo $AWS_WEB_IDENTITY_TOKEN_FILE
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
/var/run/secrets/eks.amazonaws.com/serviceaccount/token
/var/run/secrets/eks.amazonaws.com/serviceaccount/token
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 出力では、Pod 内のサービスアカウントの OIDC トークンへのフルパスを指定する必要があります。
Pod のインタラクティブターミナルで、OIDC トークンファイルを含む
aws-iam-token
ボリュームマウントが Pod ID Webhook によってマウントされたことを確認します。mount | grep -is 'eks.amazonaws.com'
$ mount | grep -is 'eks.amazonaws.com'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
tmpfs on /run/secrets/eks.amazonaws.com/serviceaccount type tmpfs (ro,relatime,seclabel,size=13376888k)
tmpfs on /run/secrets/eks.amazonaws.com/serviceaccount type tmpfs (ro,relatime,seclabel,size=13376888k)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pod のインタラクティブターミナルで、
token
という名前の OIDC トークンファイルが/var/run/secrets/eks.amazonaws.com/serviceaccount/
マウントポイントに存在することを確認します。ls /var/run/secrets/eks.amazonaws.com/serviceaccount/token
$ ls /var/run/secrets/eks.amazonaws.com/serviceaccount/token
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
/var/run/secrets/eks.amazonaws.com/serviceaccount/token
/var/run/secrets/eks.amazonaws.com/serviceaccount/token
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Pod ID Webhook によって Pod にマウントされた
aws-iam-token
ボリューム内の OIDC トークンファイル。トークンは、AWS でサービスアカウントの ID を認証するために使用されます。
Pod で、AWS Boto3 SDK オペレーションが正常に実行されることを確認します。
Pod の対話型ターミナルで、Python 3 シェルを開始します。
python3
$ python3
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Python 3 シェルで、
boto3
モジュールをインポートします。>>> import boto3
>>> import boto3
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Boto3
s3
サービスリソースを含む変数を作成します。>>> s3 = boto3.resource('s3')
>>> s3 = boto3.resource('s3')
Copy to Clipboard Copied! Toggle word wrap Toggle overflow AWS アカウントのすべての S3 バケットの名前を出力します。
>>> for bucket in s3.buckets.all(): ... print(bucket.name) ...
>>> for bucket in s3.buckets.all(): ... print(bucket.name) ...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
<bucket_name> <bucket_name> <bucket_name> ...
<bucket_name> <bucket_name> <bucket_name> ...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービスアカウントが AWS IAM ロールを正常に引き受けた場合は、AWS アカウントで使用可能なすべての S3 バケットが出力に一覧表示されます。
第10章 スコープトークン リンクのコピーリンクがクリップボードにコピーされました!
10.1. トークンのスコープについて リンクのコピーリンクがクリップボードにコピーされました!
スコープ付きトークンを作成して、パーミッションの一部を別のユーザーまたはサービスアカウントに委任できます。たとえば、プロジェクト管理者が Pod の作成権限を委任しないといけない場合があります。
スコープ付きトークンは、指定されるユーザーを識別しますが、そのスコープによって特定のアクションに制限されるトークンです。cluster-admin
ロールを持つユーザーのみがスコープ付きトークンを作成できます。
スコープは、トークンの一連のスコープを PolicyRules
のセットに変換して評価されます。次に、要求がそれらのルールに対してマッチングされます。要求属性は、追加の認可検査のために "標準" のオーソライザーに渡せるよう、スコープルールのいずれかに一致している必要があります。
10.1.1. ユーザースコープ リンクのコピーリンクがクリップボードにコピーされました!
ユーザースコープでは、指定されたユーザーに関する情報を取得することにフォーカスが置かれます。それらはインテントベースであるため、ルールは自動的に作成されます。
-
user:full
: ユーザーのすべてのパーミッションによる API の完全な読み取り/書き込みアクセスを許可します。 -
user:info
: 名前やグループなどのユーザーに関する情報の読み取り専用アクセスを許可します。 -
user:check-access
:self-localsubjectaccessreviews
およびself-subjectaccessreviews
へのアクセスを許可します。これらは、要求オブジェクトの空のユーザーおよびグループを渡す変数です。 -
user:list-projects
: ユーザーがアクセスできるプロジェクトをリスト表示するための読み取り専用アクセスを許可します。
10.1.2. ロールスコープ リンクのコピーリンクがクリップボードにコピーされました!
ロールスコープにより、namespace でフィルターされる指定ロールと同じレベルのアクセスを持たせることができます。
role:<cluster-role name>:<namespace or * for all>
: 指定された namespace のみにあるクラスターロール (cluster-role) で指定されるルールにスコープを制限します。注記注意: これは、アクセスのエスカレートを防ぎます。ロールはシークレット、ロールバインディング、およびロールなどのリソースへのアクセスを許可しますが、このスコープはそれらのリソースへのアクセスを制限するのに役立ちます。これにより、予期しないエスカレーションを防ぐことができます。
edit
などのロールはエスカレートされるロールとみなされないことが多いですが、シークレットのアクセスを持つロールの場合はエスカレーションが生じます。-
role:<cluster-role name>:<namespace or * for all>:!
: bang (!) を含めることでこのスコープでアクセスのエスカレートを許可されますが、それ以外には上記の例と同様になります。
10.2. 認証されていないグループのクラスターロールへの追加 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、クラスターロールバインディングを作成することにより、認証されていないユーザーを Red Hat OpenShift Service on AWS の次のクラスターロールに追加できます。認証されていないユーザーには、パブリックではないクラスターロールへのアクセス権はありません。これは、特定のユースケースで必要な場合にのみ行うようにしてください。
認証されていないユーザーを以下のクラスターロールに追加できます。
-
system:scope-impersonation
-
system:webhook
-
system:oauth-token-deleter
-
self-access-reviewer
認証されていないアクセスを変更するときは、常に組織のセキュリティー標準に準拠していることを確認してください。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc
) がインストールされている。
手順
add-<cluster_role>-unauth.yaml
という名前の YAML ファイルを作成し、次のコンテンツを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して設定を適用します。
oc apply -f add-<cluster_role>.yaml
$ oc apply -f add-<cluster_role>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第11章 バインドされたサービスアカウントトークンの使用 リンクのコピーリンクがクリップボードにコピーされました!
バインドされたサービスアカウントトークンを使用すると、AWS または AWS IAM 上の Red Hat OpenShift Service や Google Cloud Platform IAM などのクラウドプロバイダーのアイデンティティーアクセス管理 (IAM) サービスとの統合機能が向上します。
11.1. バインドされたサービスアカウントトークンについて リンクのコピーリンクがクリップボードにコピーされました!
バインドされたサービスアカウントトークンを使用して、所定のサービスアカウントトークンのパーミッションの範囲を制限できます。これらのトークンは対象であり、時間のバインドがあります。これにより、サービスアカウントの IAM ロールへの認証と Pod にマウントされた一時的な認証情報の生成が容易になります。ボリュームのローテーションと TokenRequest API を使用してバインドされたサービスアカウントのトークンを要求できます。
11.2. ボリュームローテーションを使用したバインドされたサービスアカウントトークンの設定 リンクのコピーリンクがクリップボードにコピーされました!
ボリュームのデプロイメントを使用してバインドされたサービスアカウントのトークンを要求するように Pod を設定できます。
前提条件
-
dedicated-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
サービスアカウントを作成している。この手順では、サービスアカウントの名前が
build-robot
であることを前提としています。
手順
ボリュームの展開を使用してバインドされたサービスアカウントのトークンを使用するように Pod を設定します。
以下の内容を含む
pod-projected-svc-token.yaml
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 侵害のリスクを最小限に抑えるために、コンテナーが root として実行されるのを防ぎます。
- 2
- リスクを軽減するために、必須のシステムコールに限定してデフォルトの seccomp プロファイルを設定します。
- 3
- 既存のサービスアカウントへの参照。
- 4
- トークンのデプロイメント先となるファイルのマウントポイントに対する相対パス。
- 5
- オプションで、サービスアカウントトークンの有効期限を秒単位で設定します。デフォルト値は 3600 秒 (1 時間) であり、この値は 600 秒 (10 分) 以上にする必要があります。トークンの有効期間がその 80% を過ぎている場合や、トークンの生成から 24 時間を経過している場合、kubelet はトークンのローテーションの試行を開始します。
- 6
- オプションで、トークンの意図された対象を設定します。トークンの受信側は、受信側のアイデンティティーがトークンの適切対象の要求と一致することを確認し、一致しない場合はトークンを拒否する必要があります。対象はデフォルトで API サーバーの識別子に設定されます。
注記予期しない障害を防ぐために、Red Hat OpenShift Service on AWS は
--service-account-extend-token-expiration
のデフォルトをtrue
にして、expirationSeconds
の値を最初のトークンの生成から 1 年になるようにオーバーライドします。この設定は変更できません。Pod を作成します。
oc create -f pod-projected-svc-token.yaml
$ oc create -f pod-projected-svc-token.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow kubelet は Pod に代わってトークンを要求し、保存し、トークンを設定可能なファイルパスで Pod に対して利用可能にし、有効期限に達するとトークンを更新します。
バインドされたトークンを使用するアプリケーションは、ローテーション時にトークンのリロードを処理する必要があります。
トークンの有効期間がその 80% を過ぎている場合や、トークンの生成から 24 時間を経過している場合、kubelet はトークンをローテーションします。
11.3. Pod の外部でバインドされたサービスアカウントトークンの作成 リンクのコピーリンクがクリップボードにコピーされました!
前提条件
-
サービスアカウントを作成している。この手順では、サービスアカウントの名前が
build-robot
であることを前提としています。
手順
次のコマンドを実行して、Pod の外部にバインドされたサービスアカウントトークンを作成します。
oc create token build-robot
$ oc create token build-robot
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
eyJhbGciOiJSUzI1NiIsImtpZCI6IkY2M1N4MHRvc2xFNnFSQlA4eG9GYzVPdnN3NkhIV0tRWmFrUDRNcWx4S0kifQ.eyJhdWQiOlsiaHR0cHM6Ly9pc3N1ZXIyLnRlc3QuY29tIiwiaHR0cHM6Ly9pc3N1ZXIxLnRlc3QuY29tIiwiaHR0cHM6Ly9rdWJlcm5ldGVzLmRlZmF1bHQuc3ZjIl0sImV4cCI6MTY3OTU0MzgzMCwiaWF0IjoxNjc5NTQwMjMwLCJpc3MiOiJodHRwczovL2lzc3VlcjIudGVzdC5jb20iLCJrdWJlcm5ldGVzLmlvIjp7Im5hbWVzcGFjZSI6ImRlZmF1bHQiLCJzZXJ2aWNlYWNjb3VudCI6eyJuYW1lIjoidGVzdC1zYSIsInVpZCI6ImM3ZjA4MjkwLWIzOTUtNGM4NC04NjI4LTMzMTM1NTVhNWY1OSJ9fSwibmJmIjoxNjc5NTQwMjMwLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6ZGVmYXVsdDp0ZXN0LXNhIn0.WyAOPvh1BFMUl3LNhBCrQeaB5wSynbnCfojWuNNPSilT4YvFnKibxwREwmzHpV4LO1xOFZHSi6bXBOmG_o-m0XNDYL3FrGHd65mymiFyluztxa2lgHVxjw5reIV5ZLgNSol3Y8bJqQqmNg3rtQQWRML2kpJBXdDHNww0E5XOypmffYkfkadli8lN5QQD-MhsCbiAF8waCYs8bj6V6Y7uUKTcxee8sCjiRMVtXKjQtooERKm-CH_p57wxCljIBeM89VdaR51NJGued4hVV5lxvVrYZFu89lBEAq4oyQN_d6N1vBWGXQMyoihnt_fQjn-NfnlJWk-3NSZDIluDJAv7e-MTEk3geDrHVQKNEzDei2-Un64hSzb-n1g1M0Vn0885wQBQAePC9UlZm8YZlMNk1tq6wIUKQTMv3HPfi5HtBRqVc2eVs0EfMX4-x-PHhPCasJ6qLJWyj6DvyQ08dP4DW_TWZVGvKlmId0hzwpg59TTcLR0iCklSEJgAVEEd13Aa_M0-faD11L3MhUGxw0qxgOsPczdXUsolSISbefs7OKymzFSIkTAn9sDQ8PHMOsuyxsK8vzfrR-E0z7MAeguZ2kaIY7cZqbN6WFy0caWgx46hrKem9vCKALefElRYbCg3hcBmowBcRTOqaFHLNnHghhU1LaRpoFzH7OUarqX9SGQ
eyJhbGciOiJSUzI1NiIsImtpZCI6IkY2M1N4MHRvc2xFNnFSQlA4eG9GYzVPdnN3NkhIV0tRWmFrUDRNcWx4S0kifQ.eyJhdWQiOlsiaHR0cHM6Ly9pc3N1ZXIyLnRlc3QuY29tIiwiaHR0cHM6Ly9pc3N1ZXIxLnRlc3QuY29tIiwiaHR0cHM6Ly9rdWJlcm5ldGVzLmRlZmF1bHQuc3ZjIl0sImV4cCI6MTY3OTU0MzgzMCwiaWF0IjoxNjc5NTQwMjMwLCJpc3MiOiJodHRwczovL2lzc3VlcjIudGVzdC5jb20iLCJrdWJlcm5ldGVzLmlvIjp7Im5hbWVzcGFjZSI6ImRlZmF1bHQiLCJzZXJ2aWNlYWNjb3VudCI6eyJuYW1lIjoidGVzdC1zYSIsInVpZCI6ImM3ZjA4MjkwLWIzOTUtNGM4NC04NjI4LTMzMTM1NTVhNWY1OSJ9fSwibmJmIjoxNjc5NTQwMjMwLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6ZGVmYXVsdDp0ZXN0LXNhIn0.WyAOPvh1BFMUl3LNhBCrQeaB5wSynbnCfojWuNNPSilT4YvFnKibxwREwmzHpV4LO1xOFZHSi6bXBOmG_o-m0XNDYL3FrGHd65mymiFyluztxa2lgHVxjw5reIV5ZLgNSol3Y8bJqQqmNg3rtQQWRML2kpJBXdDHNww0E5XOypmffYkfkadli8lN5QQD-MhsCbiAF8waCYs8bj6V6Y7uUKTcxee8sCjiRMVtXKjQtooERKm-CH_p57wxCljIBeM89VdaR51NJGued4hVV5lxvVrYZFu89lBEAq4oyQN_d6N1vBWGXQMyoihnt_fQjn-NfnlJWk-3NSZDIluDJAv7e-MTEk3geDrHVQKNEzDei2-Un64hSzb-n1g1M0Vn0885wQBQAePC9UlZm8YZlMNk1tq6wIUKQTMv3HPfi5HtBRqVc2eVs0EfMX4-x-PHhPCasJ6qLJWyj6DvyQ08dP4DW_TWZVGvKlmId0hzwpg59TTcLR0iCklSEJgAVEEd13Aa_M0-faD11L3MhUGxw0qxgOsPczdXUsolSISbefs7OKymzFSIkTAn9sDQ8PHMOsuyxsK8vzfrR-E0z7MAeguZ2kaIY7cZqbN6WFy0caWgx46hrKem9vCKALefElRYbCg3hcBmowBcRTOqaFHLNnHghhU1LaRpoFzH7OUarqX9SGQ
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第12章 SCC (Security Context Constraints) の管理 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS では、SCC (Security Context Constraints) を使用して、クラスター内の Pod のアクセス許可を制御できます。
デフォルトの SCC は、インストール中、および一部の Operator またはその他のコンポーネントをインストールするときに作成されます。クラスター管理者は、OpenShift CLI (oc
) を使用して独自の SCC を作成することもできます。
デフォルトの SCC は変更しないでください。デフォルトの SCC をカスタマイズすると、一部のプラットフォーム Pod がデプロイされるか、ROSA がアップグレードされるときに問題が発生する可能性があります。さらに、一部のクラスターのアップグレード中にデフォルトの SCC 値がデフォルトにリセットされ、それらの SCC に対するすべてのカスタマイズが破棄されます。
デフォルトの SCC を変更する代わりに、必要に応じて独自の SCC を作成および変更します。詳細な手順は、Security Context Constraints の作成 を参照してください。
12.1. Security Context Constraints について リンクのコピーリンクがクリップボードにコピーされました!
RBAC リソースがユーザーアクセスを制御するのと同じ方法で、管理者は Security Context Constraints (SCC) を使用して Pod のパーミッションを制御できます。これらのアクセス許可によって、Pod が実行できるアクションとアクセスできるリソースが決まります。SCC を使用して、Pod がシステムに受け入れられるために必要な Pod の実行に関する条件の一覧を定義できます。
管理者は Security Context Constraints で、以下を制御できます。
-
Pod が
allowPrivilegedContainer
フラグが付いた特権付きコンテナーを実行できるかどうか -
Pod が
allowPrivilegeEscalation
フラグで制約されているかどうか - コンテナーが要求できる機能
- ホストディレクトリーのボリュームとしての使用
- コンテナーの SELinux コンテキスト
- コンテナーのユーザー ID
- ホストの namespace とネットワークの使用
-
Pod ボリュームを所有する
FSGroup
の割り当て - 許可される補助グループの設定
- コンテナーが root ファイルシステムへの書き込みアクセスを必要とするかどうか
- ボリュームタイプの使用
-
許可される
seccomp
プロファイルの設定
Red Hat OpenShift Service on AWS の namespace には openshift.io/run-level
ラベルを設定しないでください。このラベルは、Kubernetes API サーバーや OpenShift API サーバーなどのメジャー API グループの起動管理に、内部の Red Hat OpenShift Service on AWS コンポーネントで使用されます。openshift.io/run-level
ラベルが設定される場合には対象の namespace の Pod に SCC が適用されず、その namespace で実行されるワークロードには高度な特権が割り当てられます。
12.1.1. デフォルトの Security Context Constraints リンクのコピーリンクがクリップボードにコピーされました!
クラスターには、以下の表で説明されているように、デフォルトの SCC (Security Context Constraints) が複数含まれます。追加の SCC は、Operator または他のコンポーネントの Red Hat OpenShift Service on AWS へのインストール時にインストールされる可能性があります。
デフォルトの SCC は変更しないでください。デフォルトの SCC をカスタマイズすると、一部のプラットフォーム Pod がデプロイされるか、ROSA がアップグレードされるときに問題が発生する可能性があります。さらに、一部のクラスターのアップグレード中にデフォルトの SCC 値がデフォルトにリセットされ、それらの SCC に対するすべてのカスタマイズが破棄されます。
デフォルトの SCC を変更する代わりに、必要に応じて独自の SCC を作成および変更します。詳細な手順は、Security Context Constraints の作成 を参照してください。
Security Context Constraints | 説明 |
---|---|
|
SCC のすべての機能が |
| ホストの全 namespace にアクセスできますが、対象の namespace に割り当てられた UID および SELinux コンテキストで Pod を実行する必要があります。 警告 この SCC で、ホストは namespace、ファイルシステム、および PID にアクセスできます。信頼できる Pod だけがこの SCC を使用する必要があります。付与には注意が必要です。 |
|
SCC のすべての機能を 警告 この SCC は、UID 0 を含む任意の UID としてホストファイルシステムにアクセスできます。付与には注意が必要です。 |
| ホストのネットワークおよびホストポートを使用できますが、対象の namespace に割り当てられた UID および SELinux コンテキストで Pod を実行する必要があります。 警告
追加のワークロードをコントロールプレーンホストで実行する場合は、 |
|
|
| Prometheus ノードエクスポーターに使用されます。 警告 この SCC は、UID 0 を含む任意の UID としてホストファイルシステムにアクセスできます。付与には注意が必要です。 |
|
SCC のすべての機能が |
|
|
| すべての特権およびホスト機能にアクセスでき、任意のユーザー、任意のグループ、FSGroup、および任意の SELinux コンテキストで実行できます。 警告 これは最も制限の少ない SCC であり、クラスター管理にのみ使用してください。付与には注意が必要です。
注記
Pod の仕様で |
| すべてのホスト機能へのアクセスが拒否され、Pod を UID および namespace に割り当てられる SELinux コンテキストで実行する必要があります。
Red Hat OpenShift Service on AWS 4.10 以前からアップグレードされたクラスターでは、すべての認証済みユーザーがこの SCC を使用できます。アクセスが明示的に付与されない限り、新しい Red Hat OpenShift Service on AWS 4.11 以降のインストールのユーザーは |
|
これは新規インストールで提供され、デフォルトで認証済みユーザーに使用される最も制限の厳しい SCC です。 注記
|
12.1.2. Security Context Constraints の設定 リンクのコピーリンクがクリップボードにコピーされました!
Security Context Constraints (SCC) は、Pod がアクセスできるセキュリティー機能を制御する設定およびストラテジーで構成されています。これらの設定は以下のカテゴリーに分類されます。
カテゴリー | 説明 |
---|---|
ブール値による制御 |
このタイプのフィールドはデフォルトで最も制限のある値に設定されます。たとえば、 |
許可されるセットによる制御 | このタイプのフィールドがセットに対してチェックされ、その値が許可されることを確認します。 |
ストラテジーによる制御 | 値を生成するストラテジーを持つ項目は以下を提供します。
|
CRI-O には、Pod の各コンテナーについて許可されるデフォルトの機能リストがあります。
-
CHOWN
-
DAC_OVERRIDE
-
FSETID
-
FOWNER
-
SETGID
-
SETUID
-
SETPCAP
-
NET_BIND_SERVICE
-
KILL
コンテナーはこのデフォルトリストから機能を使用しますが、Pod マニフェストの作成者は追加機能を要求したり、デフォルト動作の一部を削除してリストを変更できます。allowedCapabilities
パラメーター、defaultAddCapabilities
パラメーター、および requiredDropCapabilities
パラメーターを使用して、Pod からのこのような要求を制御します。これらのパラメーターを使用して、(各コンテナーに追加する必要のある機能や、各コンテナーから禁止または破棄する必要のあるものなど) 要求できる機能を指定できます。
requiredDropCapabilities
パラメーターを ALL
に設定すると、すべての capabilites をコンテナーから取り除くことができます。これは、restricted-v2
SCC の機能です。
12.1.3. Security Context Constraints ストラテジー リンクのコピーリンクがクリップボードにコピーされました!
RunAsUser
MustRunAs
:runAsUser
が設定されることを要求します。デフォルトで設定済みのrunAsUser
を使用します。設定済みのrunAsUser
に対して検証します。MustRunAs
スニペットの例... runAsUser: type: MustRunAs uid: <id> ...
... runAsUser: type: MustRunAs uid: <id> ...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow MustRunAsRange
: 事前に割り当てられた値を使用していない場合に、最小値および最大値が定義されることを要求します。デフォルトでは最小値を使用します。許可される範囲全体に対して検証します。MustRunAsRange
スニペットの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow MustRunAsNonRoot
: Pod がゼロ以外のrunAsUser
で送信されること、またはUSER
ディレクティブをイメージに定義することを要求します。デフォルトは指定されません。MustRunAsNonRoot
スニペットの例... runAsUser: type: MustRunAsNonRoot ...
... runAsUser: type: MustRunAsNonRoot ...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow RunAsAny
: デフォルトは指定されません。runAsUser
の指定を許可します。RunAsAny
スニペットの例... runAsUser: type: RunAsAny ...
... runAsUser: type: RunAsAny ...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
SELinuxContext
-
MustRunAs
: 事前に割り当てられた値を使用していない場合にseLinuxOptions
が設定されることを要求します。デフォルトとしてseLinuxOptions
を使用します。seLinuxOptions
に対して検証します。 -
RunAsAny
: デフォルトは指定されません。seLinuxOptions
の指定を許可します。
SupplementalGroups
-
MustRunAs
: 事前に割り当てられた値を使用していない場合に、少なくとも 1 つの範囲が指定されることを要求します。デフォルトとして最初の範囲の最小値を使用します。すべての範囲に対して検証します。 -
RunAsAny
: デフォルトは指定されません。supplementalGroups
の指定を許可します。
FSGroup
-
MustRunAs
: 事前に割り当てられた値を使用していない場合に、少なくとも 1 つの範囲が指定されることを要求します。デフォルトとして最初の範囲の最小値を使用します。最初の範囲の最初の ID に対して検証します。 -
RunAsAny
: デフォルトは指定されません。fsGroup
ID の指定を許可します。
12.1.4. ボリュームの制御 リンクのコピーリンクがクリップボードにコピーされました!
特定のボリュームタイプの使用は、SCC の volumes
フィールドを設定して制御できます。
このフィールドの許容値は、ボリュームの作成時に定義されるボリュームソースに対応します。
-
awsElasticBlockStore
-
azureDisk
-
azureFile
-
cephFS
-
cinder
-
configMap
-
csi
-
downwardAPI
-
emptyDir
-
fc
-
flexVolume
-
flocker
-
gcePersistentDisk
-
ephemeral
-
gitRepo
-
glusterfs
-
hostPath
-
iscsi
-
nfs
-
persistentVolumeClaim
-
photonPersistentDisk
-
portworxVolume
-
projected
-
quobyte
-
rbd
-
scaleIO
-
secret
-
storageos
-
vsphereVolume
- * (すべてのボリュームタイプの使用を許可する特殊な値)
-
none
(すべてのボリュームタイプの使用を無効にする特殊な値。後方互換の場合にのみ存在する)
新規 SCC について許可されるボリュームの推奨される最小セットは、configMap
、downwardAPI
、emptyDir
、persistentVolumeClaim
、secret
、および projected
です。
Red Hat OpenShift Service on AWS の各リリースに新しいタイプ追加されるため、この許可されるボリュームタイプリストがすべて網羅しているわけではありません。
後方互換性を確保するため、allowHostDirVolumePlugin
の使用は volumes
フィールドの設定をオーバーライドします。たとえば、allowHostDirVolumePlugin
が false に設定されていて、volumes
フィールドで許可されている場合は、volumes
から hostPath
値が削除されます。
12.1.5. アドミッション制御 リンクのコピーリンクがクリップボードにコピーされました!
SCC が設定された アドミッション制御 により、ユーザーに付与された機能に基づいてリソースの作成に対する制御が可能になります。
SCC の観点では、これはアドミッションコントローラーが、SCC の適切なセットを取得するためにコンテキストで利用可能なユーザー情報を検査できることを意味します。これにより、Pod はその運用環境に関する要求を行ったり、Pod に適用する一連の制約を生成したりする権限が与えられます
アドミッションが Pod を許可するために使用する SCC のセットはユーザーアイデンティティーおよびユーザーが属するグループによって決定されます。さらに、Pod がサービスアカウントを指定する場合は、許可される SCC のセットに、サービスアカウントでアクセスできる制約が含まれます。
デプロイメントなどのワークロードリソースを作成する場合、SCC の検索と、作成された Pod の許可には、サービスアカウントのみが使用されます。
アドミッションは以下の方法を使用して、Pod の最終的なセキュリティーコンテキストを作成します。
- 使用できるすべての SCC を取得します。
- 要求に指定されていないセキュリティーコンテキストに、設定のフィールド値を生成します。
- 利用可能な制約に対する最終的な設定を検証します。
制約の一致するセットが検出される場合は、Pod が受け入れられます。要求が SCC に一致しない場合は、Pod が拒否されます。
Pod はすべてのフィールドを SCC に対して検証する必要があります。以下は、検証する必要がある 2 つのフィールドの例です。
これらの例は、事前に割り当てられた値を使用するストラテジーに関連します。
MustRunAs
の FSGroup SCC ストラテジー
Pod が fsGroup
ID を定義する場合、その ID はデフォルトの fsGroup
ID と同一にする必要があります。そうでない場合は、Pod が SCC で検証されず、次の SCC が評価されます。
SecurityContextConstraints.fsGroup
フィールドに値 RunAsAny
があり、Pod 仕様で Pod.spec.securityContext.fsGroup
が省略されると、このフィールドは有効とみなされます。検証時に、他の SCC 設定が他の Pod フィールドを拒否し、そのため Pod を失敗させる可能性があることに注意してください。
MustRunAs
の SupplementalGroups
SCC ストラテジー
Pod 仕様が 1 つ以上の supplementalGroups
ID を定義する場合、Pod の ID は namespace の openshift.io/sa.scc.supplemental-groups
アノテーションの ID のいずれかと同一にする必要があります。そうでない場合は、Pod が SCC で検証されず、次の SCC が評価されます。
SecurityContextConstraints.supplementalGroups
フィールドに値 RunAsAny
があり、Pod 仕様が Pod.spec.securityContext.supplementalGroups
を省略する場合、このフィールドは有効とみなされます。検証時に、他の SCC 設定が他の Pod フィールドを拒否し、そのため Pod を失敗させる可能性があることに注意してください。
12.1.6. Security Context Constraints の優先度設定 リンクのコピーリンクがクリップボードにコピーされました!
SCC (Security Context Constraints) には優先度フィールドがあり、アドミッションコントローラーの要求検証を試行する順序に影響を与えます。
優先順位値 0
は可能な限り低い優先順位です。nil 優先順位は 0
または最低の優先順位とみなされます。優先順位の高い SCC は、並べ替え時にセットの先頭に移動します。
使用可能な SCC の完全なセットが決定すると、SCC は次の方法で順序付けられます。
- 最も優先度の高い SCC が最初に並べられます。
- 優先度が等しいと、SCC は最も制限の多いものから少ないものの順に並べ替えられます。
- 優先度と制限の両方が等しいと、SCC は名前でソートされます。
デフォルトで、クラスター管理者に付与される anyuid
SCC には SCC セットの優先度が指定されます。これにより、クラスター管理者は Pod の SecurityContext
で RunAsUser
を指定することにより、任意のユーザーとして Pod を実行できます。
12.2. 事前に割り当てられる Security Context Constraints 値について リンクのコピーリンクがクリップボードにコピーされました!
アドミッションコントローラーは、これが namespace の事前に割り当てられた値を検索し、Pod の処理前に Security Context Constraints (SCC) を設定するようにトリガーする SCC (Security Context Constraint) の特定の条件を認識します。各 SCC ストラテジーは他のストラテジーとは別に評価されます。この際、(許可される場合に) Pod 仕様の値と共に集計された各ポリシーの事前に割り当てられた値が使用され、実行中の Pod で定義される各種 ID の最終の値が設定されます。
以下の SCC により、アドミッションコントローラーは、範囲が Pod 仕様で定義されていない場合に事前に定義された値を検索できます。
-
最小または最大値が設定されていない
MustRunAsRange
のRunAsUser
ストラテジーです。アドミッションはopenshift.io/sa.scc.uid-range
アノテーションを検索して範囲フィールドを設定します。 -
レベルが設定されていない
MustRunAs
のSELinuxContext
ストラテジーです。アドミッションはopenshift.io/sa.scc.mcs
アノテーションを検索してレベルを設定します。 -
MustRunAs
のFSGroup
ストラテジーです。アドミッションは、openshift.io/sa.scc.supplemental-groups
アノテーションを検索します。 -
MustRunAs
のSupplementalGroups
ストラテジーです。アドミッションは、openshift.io/sa.scc.supplemental-groups
アノテーションを検索します。
生成フェーズでは、セキュリティーコンテキストのプロバイダーが Pod にとくに設定されていないパラメーター値をデフォルト設定します。デフォルト設定は選択されるストラテジーに基づいて行われます。
-
RunAsAny
およびMustRunAsNonRoot
ストラテジーはデフォルトの値を提供しません。Pod がパラメーター値 (グループ ID など) を必要とする場合は、値を Pod 仕様内に定義する必要があります。 -
MustRunAs
(単一の値) ストラテジーは、常に使用されるデフォルト値を提供します。たとえば、グループ ID の場合は、Pod 仕様が独自の ID 値を定義する場合でも、namespace のデフォルトパラメーター値が Pod のグループに表示されます。 -
MustRunAsRange
およびMustRunAs
(範囲ベース) ストラテジーは、範囲の最小値を提供します。単一値のMustRunAs
ストラテジーの場合のように、namespace のデフォルト値は実行中の Pod に表示されます。範囲ベースのストラテジーが複数の範囲で設定可能な場合、これは最初に設定された範囲の最小値を指定します。
FSGroup
および SupplementalGroups
ストラテジーは、openshift.io/sa.scc.supplemental-groups
アノテーションが namespace に存在しない場合に openshift.io/sa.scc.uid-range
アノテーションにフォールバックします。いずれも存在しない場合は、SCC が作成されません。
デフォルトで、アノテーションベースの FSGroup
ストラテジーは、自身をアノテーションの最小値に基づく単一の範囲で設定します。たとえば、アノテーションが 1/3
を読み取ると、FSGroup
ストラテジーは 1
の最小値および最大値で自身を設定します。追加のグループを FSGroup
フィールドで許可する必要がある場合は、アノテーションを使用しないカスタム SCC を設定することができます。
openshift.io/sa.scc.supplemental-groups
アノテーションは、<start>/<length
または <start>-<end>
形式のコンマ区切りのブロックのリストを受け入れます。openshift.io/sa.scc.uid-range
アノテーションは単一ブロックのみを受け入れます。
12.3. Security Context Constraints の例 リンクのコピーリンクがクリップボードにコピーされました!
以下の例は、Security Context Constraints (SCC) 形式およびアノテーションを示しています。
アノテーション付き privileged
SCC
- 1
- Pod が要求できる機能の一覧です。特殊な記号
*
は任意の機能を許可しますが、リストが空の場合は、いずれの機能も要求できないことを意味します。 - 2
- Pod に含める追加機能のリストです。
- 3
- セキュリティーコンテキストの許可される値を定める
FSGroup
ストラテジータイプです。 - 4
- この SCC へのアクセスを持つグループです。
- 5
- Pod から取り除く機能のリストです。または、
ALL
を指定してすべての機能をドロップします。 - 6
- セキュリティーコンテキストの許可される値を定める
runAsUser
ストラテジータイプです。 - 7
- セキュリティーコンテキストの許可される値を定める
seLinuxContext
ストラテジータイプです。 - 8
- セキュリティーコンテキストの許可される補助グループを定める
supplementalGroups
ストラテジーです。 - 9
- この SCC にアクセスできるユーザーです。
- 10
- セキュリティーコンテキストで許容されるボリュームタイプです。この例では、
*
はすべてのボリュームタイプの使用を許可します。
SCC の users
フィールドおよび groups
フィールドは SCC にアクセスできるユーザー制御します。デフォルトで、クラスター管理者、ノードおよびビルドコントローラーに特権付き SCC へのアクセスが付与されます。認証されたすべてのユーザーには restricted-v2
SCC へのアクセスが付与されます。
明示的な runAsUser
設定を使用しない場合
- 1
- コンテナーまたは Pod が実行時に使用するユーザー ID を要求しない場合、有効な UID はこの Pod を作成する SCC よって異なります。
restricted-v2
SCC はデフォルトですべての認証ユーザーに付与されるため、ほとんどの場合はすべてのユーザーおよびサービスアカウントで利用でき、使用されます。restricted-v2
SCC は、securityContext.runAsUser
フィールドの使用できる値を制限し、これをデフォルトに設定するためにMustRunAsRange
ストラテジーを使用します。受付プラグインではこの範囲を指定しないため、現行プロジェクトでopenshift.io/sa.scc.uid-range
アノテーションを検索して範囲フィールドにデータを設定します。最終的にコンテナーのrunAsUser
は予測が困難な範囲の最初の値と等しい値になります。予測が困難であるのはすべてのプロジェクトにはそれぞれ異なる範囲が設定されるためです。
明示的な runAsUser
設定を使用する場合
- 1
- 特定のユーザー ID を要求するコンテナーまたは Pod が Red Hat OpenShift Service on AWS で受け入れられるのは、サービスアカウントまたはユーザーに、そのユーザー ID を許可するように、SCC へのアクセスが付与されている場合のみです。SCC は、任意の ID や特定の範囲内にある ID、または要求に固有のユーザー ID を許可します。
この設定は、SELinux、fsGroup、および Supplemental Groups について有効です。
12.4. Security Context Constraints の作成 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトの Security Context Constraints (SCC) がアプリケーションのワークロード要件を満たさない場合は、OpenShift CLI (oc
) を使用してカスタム SCC を作成できます。
独自の SCC の作成と変更は高度な操作であり、クラスターを不安定にする可能性があります。独自の SCC の使用について質問がある場合は、Red Hat サポートにお問い合わせください。Red Hat サポートへの連絡方法は、サポートを受ける方法 を参照してください。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
ロールを持つユーザーとしてクラスターにログインしている。
手順
scc-admin.yaml
という名前の YAML ファイルで SCC を定義します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプションとして、
requiredDropCapabilities
フィールドに必要な値を設定して、SCC の特定の機能を取り除くことができます。指定された機能はコンテナーからドロップされます。すべてのケイパビリティーを破棄するには、ALL
を指定します。たとえば、KILL
機能、MKNOD
機能、およびSYS_CHROOT
機能のない SCC を作成するには、以下を SCC オブジェクトに追加します。requiredDropCapabilities: - KILL - MKNOD - SYS_CHROOT
requiredDropCapabilities: - KILL - MKNOD - SYS_CHROOT
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記allowedCapabilities
とrequiredDropCapabilities
の両方に、機能を追加できません。CRI-O は、Docker ドキュメント に記載されている同じ一連の機能の値をサポートします。
ファイルを渡して SCC を作成します。
oc create -f scc-admin.yaml
$ oc create -f scc-admin.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
securitycontextconstraints "scc-admin" created
securitycontextconstraints "scc-admin" created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
SCC が作成されていることを確認します。
oc get scc scc-admin
$ oc get scc scc-admin
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP PRIORITY READONLYROOTFS VOLUMES scc-admin true [] RunAsAny RunAsAny RunAsAny RunAsAny <none> false [awsElasticBlockStore azureDisk azureFile cephFS cinder configMap downwardAPI emptyDir fc flexVolume flocker gcePersistentDisk gitRepo glusterfs iscsi nfs persistentVolumeClaim photonPersistentDisk quobyte rbd secret vsphere]
NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP PRIORITY READONLYROOTFS VOLUMES scc-admin true [] RunAsAny RunAsAny RunAsAny RunAsAny <none> false [awsElasticBlockStore azureDisk azureFile cephFS cinder configMap downwardAPI emptyDir fc flexVolume flocker gcePersistentDisk gitRepo glusterfs iscsi nfs persistentVolumeClaim photonPersistentDisk quobyte rbd secret vsphere]
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.5. 特定の SCC を必要とするワークロードの設定 リンクのコピーリンクがクリップボードにコピーされました!
特定の Security Context Constraints (SCC) を要求するようにワークロードを設定できます。これは、特定の SCC をワークロードに固定する場合、または必要な SCC がクラスター内の別の SCC によってプリエンプションされるのを防ぐ場合に役立ちます。
特定の SCC を要求するには、ワークロードに openshift.io/required-scc
アノテーションを設定します。このアノテーションは、デプロイメントやデーモンセットなど、Pod マニフェストテンプレートを設定できる任意のリソースに設定できます。
SCC はクラスター内に存在し、ワークロードに適用できる必要があります。そうでない場合、Pod のアドミッションは失敗します。Pod を作成するユーザーまたは Pod のサービスアカウントが Pod の namespace で SCC の use
権限を持っている場合、SCC はワークロードに適用可能であるとみなされます。
ライブ Pod のマニフェスト内の openshift.io/required-scc
アノテーションを変更しないでください。変更すると、Pod のアドミッションが失敗するためです。必要な SCC を変更するには、基礎となる Pod テンプレートのアノテーションを更新します。これにより、Pod が削除され、再作成されます。
前提条件
- SCC はクラスター内に存在する必要があります。
手順
デプロイメント用の YAML ファイルを作成し、
openshift.io/required-scc
アノテーションを設定して必要な SCC を指定します。deployment.yaml
の例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 必要な SCC の名前を指定します。
次のコマンドを実行して、リソースを作成します。
oc create -f deployment.yaml
$ oc create -f deployment.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
デプロイメントで指定された SCC が使用されたことを確認します。
次のコマンドを実行して、Pod の
openshift.io/scc
アノテーションの値を表示します。oc get pod <pod_name> -o jsonpath='{.metadata.annotations.openshift\.io\/scc}{"\n"}'
$ oc get pod <pod_name> -o jsonpath='{.metadata.annotations.openshift\.io\/scc}{"\n"}'
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<pod_name>
をデプロイメント Pod の名前に置き換えます。
出力を調べて、表示された SCC がデプロイメントで定義した SCC と一致することを確認します。
出力例
my-scc
my-scc
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.6. Security Context Constraints へのロールベースのアクセス リンクのコピーリンクがクリップボードにコピーされました!
SCC は RBAC で処理されるリソースとして指定できます。これにより、SCC へのアクセスのスコープを特定プロジェクトまたはクラスター全体に設定できます。ユーザー、グループ、またはサービスアカウントを SCC に直接割り当てると、クラスター全体のスコープが保持されます。
デフォルトプロジェクトでワークロードを実行したり、デフォルトプロジェクトへのアクセスを共有したりしないでください。デフォルトのプロジェクトは、コアクラスターコンポーネントを実行するために予約されています。
デフォルトプロジェクトである default
、kube-public
、kube-system
、openshift
、openshift-infra
、openshift-node
、および openshift.io/run-level
ラベルが 0
または 1
に設定されているその他のシステム作成プロジェクトは、高い特権があるとみなされます。Pod セキュリティーアドミッション、Security Context Constraints、クラスターリソースクォータ、イメージ参照解決などのアドミッションプラグインに依存する機能は、高い特権を持つプロジェクトでは機能しません。
ロールの SCC へのアクセスを組み込むには、ロールの作成時に scc
リソースを指定します。
oc create role <role-name> --verb=use --resource=scc --resource-name=<scc-name> -n <namespace>
$ oc create role <role-name> --verb=use --resource=scc --resource-name=<scc-name> -n <namespace>
これにより、以下のロール定義が生成されます。
このようなルールを持つローカルまたはクラスターロールは、ロールバインディングまたはクラスターロールバインディングでこれにバインドされたサブジェクトが scc-name
というユーザー定義の SCC を使用することを許可します。
RBAC はエスカレーションを防ぐように設計されているため、プロジェクト管理者であっても SCC へのアクセスを付与することはできません。デフォルトでは、restricted-v2
SCC を含め、SCC リソースで動詞 use
を使用することは許可されていません。
12.7. Security Context Constraints コマンドのリファレンス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift CLI (oc
) を使用すると、インスタンス内の Security Context Constraints (SCC) を通常の API オブジェクトとして管理できます。
12.7.1. Security Context Constraints の表示 リンクのコピーリンクがクリップボードにコピーされました!
SCC の現在の一覧を取得するには、以下を実行します。
oc get scc
$ oc get scc
出力例
12.7.2. Security Context Constraints の検証 リンクのコピーリンクがクリップボードにコピーされました!
特定の SCC に関する情報 (SCC が適用されるユーザー、サービスアカウントおよびグループを含む) を表示できます。
たとえば、restricted
SCC を検査するには、以下を実行します。
oc describe scc restricted
$ oc describe scc restricted
出力例
第13章 Pod セキュリティーアドミッションの理解と管理 リンクのコピーリンクがクリップボードにコピーされました!
Pod セキュリティーアドミッションは、Kubernetes Pod セキュリティー標準 の実装です。Pod のセキュリティーアドミッションを使用して、Pod の動作を制限します。
13.1. Pod セキュリティーアドミッションについて リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS には、Kubernetes Pod のセキュリティーアドミッション が組み込まれています。グローバルまたは namespace レベルで定義された Pod のセキュリティーアドミッションに準拠していない Pod は、クラスターへの参加が許可されず、実行できません。
グローバルに、privileged
プロファイルが適用され、restricted
プロファイルが警告と監査に使用されます。
Pod のセキュリティーアドミッション設定を namespace レベルで設定することもできます。
デフォルトプロジェクトでワークロードを実行したり、デフォルトプロジェクトへのアクセスを共有したりしないでください。デフォルトのプロジェクトは、コアクラスターコンポーネントを実行するために予約されています。
デフォルトプロジェクトである default
、kube-public
、kube-system
、openshift
、openshift-infra
、openshift-node
、および openshift.io/run-level
ラベルが 0
または 1
に設定されているその他のシステム作成プロジェクトは、高い特権があるとみなされます。Pod セキュリティーアドミッション、Security Context Constraints、クラスターリソースクォータ、イメージ参照解決などのアドミッションプラグインに依存する機能は、高い特権を持つプロジェクトでは機能しません。
13.1.1. Pod のセキュリティーアドミッションモード リンクのコピーリンクがクリップボードにコピーされました!
namespace に対して次の Pod セキュリティーアドミッションモードを設定できます。
Mode | ラベル | 説明 |
---|---|---|
|
| 設定されたプロファイルに準拠していない Pod の受け入れを拒否します。 |
|
| Pod が設定されたプロファイルに準拠していないと、監査イベントをログに記録します。 |
|
| Pod が設定されたプロファイルに準拠していないと警告を表示します。 |
13.1.2. Pod のセキュリティーアドミッションプロファイル リンクのコピーリンクがクリップボードにコピーされました!
各 Pod セキュリティーアドミッションモードを次のプロファイルのいずれかに設定できます。
プロファイル | 説明 |
---|---|
| 最も制限の少ないポリシー。既知の権限昇格が可能になります。 |
| 最小限の制限ポリシー。既知の権限昇格を防止します。 |
| 最も制限的なポリシー。現在の Pod 強化のベストプラクティスに従います。 |
13.1.3. 特権付きの namespace リンクのコピーリンクがクリップボードにコピーされました!
次のシステム namespace は、常に privileged
Pod セキュリティーアドミッションプロファイルに設定されます。
-
default
-
kube-public
-
kube-system
これらの特権付き namespace の Pod セキュリティープロファイルを変更することはできません。
特権付き namespace の設定例
13.1.4. Pod セキュリティーアドミッションおよび Security Context Constraints リンクのコピーリンクがクリップボードにコピーされました!
Pod セキュリティーアドミッションの標準と Security Context Constraints は、2 つの独立したコントローラーによって調整され、適用されます。2 つのコントローラーは独立して機能し、以下のプロセスを使用してセキュリティーポリシーを適用します。
-
Security Context Constraints コントローラーは、Pod に割り当てられた SCC (セキュリティーコンテキスト制約) ごとに、一部のセキュリティーコンテキストフィールドを変更する可能性があります。たとえば seccomp プロファイルが空、または設定されていない場合で、Pod に割り当てられた SCC が
seccompProfiles
フィールドをruntime/default
に強制する場合、コントローラーはデフォルト型をRuntimeDefault
に設定します。 - Security Context Constraints のコントローラーは、一致する SCC に対して Pod のセキュリティーコンテキストを検証します。
- Pod セキュリティーアドミッションのコントローラーは、namespace に割り当てられた Pod セキュリティー標準に対して Pod のセキュリティーコンテキストを検証します。
13.2. Pod セキュリティーアドミッション同期について リンクのコピーリンクがクリップボードにコピーされました!
グローバル Pod セキュリティーアドミッションコントロール設定に加えて、コントローラーは、特定の namespace にあるサービスアカウントの SCC アクセス許可に従って、Pod セキュリティーアドミッションコントロールの warn
および audit
ラベルを namespace に適用します。
コントローラーは ServiceAccount
オブジェクトのアクセス許可を確認して、各 namespace で Security Context Constraints を使用します。Security Context Constraints (SCC) は、フィールド値に基づいて Pod セキュリティープロファイルにマップされます。コントローラーはこれらの変換されたプロファイルを使用します。Pod のセキュリティー許可 warn
と audit
ラベルは、Pod の作成時に警告が表示されたり、監査イベントが記録されたりするのを防ぐために、namespace で最も特権のある Pod セキュリティープロファイルに設定されます。
namespace のラベル付けは、namespace ローカルサービスアカウントの権限を考慮して行われます。
Pod を直接適用すると、Pod を実行するユーザーの SCC 権限が使用される場合があります。ただし、自動ラベル付けではユーザー権限は考慮されません。
13.2.1. Pod のセキュリティーアドミッション同期 namespace の除外 リンクのコピーリンクがクリップボードにコピーされました!
Pod のセキュリティーアドミッション同期は、システムで作成されたほとんどの namespace では永続的に無効になっています。ユーザーが作成した openshift-*
接頭辞が付いた namespace でも、同期は最初は無効になっていますが、後でそれらの同期を有効にすることができます。
Pod セキュリティーアドミッションラベル (pod-security.kubernetes.io/<mode>
) が、ラベル同期された namespace で自動的にラベル付けされた値から手動で変更された場合、そのラベルの同期は無効になります。
必要に応じて、次のいずれかの方法を使用して同期を再度有効にできます。
- 変更された Pod セキュリティーアドミッションラベルを namespace から削除することによって
security.openshift.io/scc.podSecurityLabelSync
ラベルをtrue
に設定することによってこのラベルを追加して同期を強制すると、変更された Pod セキュリティーアドミッションラベルはすべて上書きされます。
永続的に無効化された namespace
クラスターペイロードの一部として定義されている namespace では、Pod セキュリティーアドミッションの同期が完全に無効になっています。次の namespace は永続的に無効になります。
-
default
-
kube-node-lease
-
kube-system
-
kube-public
-
openshift
-
openshift-
という接頭辞が付いたシステム作成の namespace すべて (openshift-operators
を除く)
最初は無効になっている namespace
デフォルトでは、openshift-
接頭辞を持つすべての namespace では、最初は Pod セキュリティーアドミッション同期が無効になっています。ユーザーが作成した openshift-*
namespace と openshift-operators
namespace の同期を有効にできます。
openshift-operators
を除き、システムで作成された openshift-*
namespace の同期を有効にすることはできません。
ユーザーが作成した openshift-*
namespace に Operator がインストールされている場合、namespace にクラスターサービスバージョン (CSV) が作成された後、同期が自動的に有効になります。同期されたラベルは、namespace 内のサービスアカウントのアクセス許可から派生します。
13.3. Pod セキュリティーアドミッションの同期制御 リンクのコピーリンクがクリップボードにコピーされました!
ほとんどの namespace で自動 Pod セキュリティーアドミッションの同期を有効または無効にできます。
システム作成の namespace では、Pod セキュリティーアドミッション同期を有効にすることはできません。詳細は、Pod のセキュリティーアドミッション同期 namespace の除外 を参照してください。
手順
設定する namespace ごとに、
security.openshift.io/scc.podSecurityLabelSync
ラベルの値を設定します。namespace で Pod セキュリティーアドミッションラベルの同期を無効にするには、
security.openshift.io/scc.podSecurityLabelSync
ラベルの値をfalse
に設定します。以下のコマンドを実行します。
oc label namespace <namespace> security.openshift.io/scc.podSecurityLabelSync=false
$ oc label namespace <namespace> security.openshift.io/scc.podSecurityLabelSync=false
Copy to Clipboard Copied! Toggle word wrap Toggle overflow namespace で Pod セキュリティーアドミッションラベルの同期を有効にするには、
security.openshift.io/scc.podSecurityLabelSync
ラベルの値をtrue
に設定します。以下のコマンドを実行します。
oc label namespace <namespace> security.openshift.io/scc.podSecurityLabelSync=true
$ oc label namespace <namespace> security.openshift.io/scc.podSecurityLabelSync=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
注記このラベルが namespace にすでに設定されている場合は、
--overwrite
フラグを使用して値を上書きします。
13.4. namespace の Pod セキュリティーアドミッションの設定 リンクのコピーリンクがクリップボードにコピーされました!
Pod のセキュリティーアドミッション設定を namespace レベルで設定できます。namespace の Pod セキュリティーアドミッションモードごとに、どの Pod セキュリティーアドミッションプロファイルを使用するかを設定できます。
手順
namespace に設定する Pod セキュリティーアドミッションモードごとに、次のコマンドを実行します。
oc label namespace <namespace> \ pod-security.kubernetes.io/<mode>=<profile> \ --overwrite
$ oc label namespace <namespace> \
1 pod-security.kubernetes.io/<mode>=<profile> \
2 --overwrite
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
13.5. Pod セキュリティーアドミッションアラート リンクのコピーリンクがクリップボードにコピーされました!
PodSecurityViolation
アラートがトリガーされるのは、Pod セキュリティーアドミッションコントローラーの監査レベルで Pod が拒否されたことを Kubernetes API サーバーが報告された場合です。このアラートは 1 日間持続します。
Kubernetes API サーバーの監査ログを表示して、トリガーされたアラートを調査します。たとえば、グローバル適用の Pod セキュリティーレベルが restricted
に設定されていると、ワークロードが承認に失敗する可能性があります。
Pod セキュリティーアドミッション違反の監査イベントを特定する方法は、Kubernetes ドキュメントの 監査アノテーション を参照してください。
第14章 LDAP グループの同期 リンクのコピーリンクがクリップボードにコピーされました!
dedicated-admin
ロールを持つ管理者は、グループを使用して、ユーザーの管理、権限の変更、連携の強化を行うことができます。組織ではユーザーグループをすでに作成し、それらを LDAP サーバーに保存している場合があります。Red Hat OpenShift Service on AWS は、これらの LDAP レコードを内部 Red Hat OpenShift Service on AWS レコードと同期できるため、管理者はグループを 1 カ所で管理できます。Red Hat OpenShift Service on AWS は現在、グループメンバーシップを定義するための 3 つの共通スキーマ (RFC 2307、Active Directory、拡張された Active Directory) を使用したグループと LDAP サーバーの同期をサポートしています。
LDAP の設定の詳細は、LDAP アイデンティティープロバイダーの設定 を参照してください。
グループを同期するには、dedicated-admin
権限が必要です。
14.1. LDAP 同期の設定について リンクのコピーリンクがクリップボードにコピーされました!
LDAP 同期を実行するには、同期設定ファイルが必要です。このファイルには、以下の LDAP クライアント設定の詳細が含まれます。
- LDAP サーバーへの接続の設定。
- LDAP サーバーで使用されるスキーマに依存する同期設定オプション。
- Red Hat OpenShift Service on AWS のグループ名を LDAP サーバー内のグループにマッピングする、管理者が定義した名前マッピングのリスト。
設定ファイルの形式は、使用するスキーマ (RFC 2307、Active Directory、または拡張 Active Directory) によって異なります。
- LDAP クライアント設定
- 設定の LDAP クライアント設定セクションでは、LDAP サーバーへの接続を定義します。
設定の LDAP クライアント設定セクションでは、LDAP サーバーへの接続を定義します。
LDAP クライアント設定
url: ldap://10.0.0.0:389 bindDN: cn=admin,dc=example,dc=com bindPassword: <password> insecure: false ca: my-ldap-ca-bundle.crt
url: ldap://10.0.0.0:389
bindDN: cn=admin,dc=example,dc=com
bindPassword: <password>
insecure: false
ca: my-ldap-ca-bundle.crt
- 1
- データベースをホストする LDAP サーバーの接続プロトコル、IP アドレス、および
scheme://host:port
としてフォーマットされる接続先のポートです。 - 2
- バインド DN として使用する任意の識別名 (DN) です。これは、同期操作のエントリーを取得するために昇格された特権が必要な場合、Red Hat OpenShift Service on AWS で使用されます。
- 3
- バインドに使用する任意のパスワードです。これは、同期操作のエントリーを取得するために昇格された特権が必要な場合、Red Hat OpenShift Service on AWS で使用されます。この値は環境変数、外部ファイル、または暗号化されたファイルでも指定できます。
- 4
false
の場合は、セキュアな LDAP (ldaps://
) URL は TLS を使用して接続し、非セキュアな LDAP (ldap://
) URL は TLS にアップグレードされます。true
の場合、サーバーへの TLS 接続は行われません。ldaps://
URL スキームは使用できません。- 5
- 設定された URL のサーバー証明書を検証するために使用する証明書バンドルです。空の場合、Red Hat OpenShift Service on AWS はシステムで信頼されたルートを使用します。
insecure
がfalse
に設定されている場合にのみ、これが適用されます。
- LDAP クエリー定義
- 同期設定は、同期に必要となるエントリーの LDAP クエリー定義で構成されています。LDAP クエリーの特定の定義は、LDAP サーバーにメンバーシップ情報を保存するために使用されるスキーマに依存します。
LDAP クエリー定義
- 1
- すべての検索が開始されるディレクトリーのブランチの識別名 (DN) です。ディレクトリーツリーの上部を指定する必要がありますが、ディレクトリーのサブツリーを指定することもできます。
- 2
- 検索の範囲です。有効な値は
base
、one
、またはsub
です。これを定義しない場合、sub
の範囲が使用されます。範囲オプションは、以下の表で説明されています。 - 3
- LDAP ツリーのエイリアスに関連する検索の動作です。有効な値は
never
、search
、base
、またはalways
です。これを定義しない場合、デフォルトはalways
となり、エイリアスを逆参照します。逆参照の動作は以下の表で説明されています。 - 4
- クライアントによって検索に許可される時間制限です。
0
の値はクライアント側の制限がないことを意味します。 - 5
- 有効な LDAP 検索フィルターです。これを定義しない場合、デフォルトは
(objectClass=*)
になります。 - 6
- LDAP エントリーで測定される、サーバーからの応答ページの任意の最大サイズです。
0
に設定すると、応答ページのサイズ制限はなくなります。クライアントまたはサーバーがデフォルトで許可しているエントリー数より多いエントリーをクエリーが返す場合、ページングサイズの設定が必要となります。
LDAP 検索範囲 | 説明 |
---|---|
| クエリーに対して指定されるベース DN で指定するオブジェクトのみを考慮します。 |
| クエリーについてベース DN とツリー内の同じレベルにあるすべてのオブジェクトを考慮します。 |
| クエリーに指定されるベース DN のサブツリー全体を考慮します。 |
逆参照動作 | 説明 |
---|---|
| LDAP ツリーにあるエイリアスを逆参照しません。 |
| 検索中に見つかったエイリアスのみを逆参照します。 |
| ベースオブジェクトを検索中にエイリアスのみを逆参照します。 |
| LDAP ツリーにあるすべてのエイリアスを常に逆参照します。 |
- ユーザー定義の名前マッピング
- ユーザー定義の名前マッピングは、Red Hat OpenShift Service on AWS グループの名前を、LDAP サーバーでグループを検索する一意の識別子に明示的にマップします。マッピングは通常の YAML 構文を使用します。ユーザー定義のマッピングには LDAP サーバーのすべてのグループのエントリーを含めることも、それらのグループのサブセットのみを含めることもできます。ユーザー定義の名前マッピングを持たないグループが LDAP サーバーにある場合、同期時のデフォルトの動作では、Red Hat OpenShift Service on AWS グループの名前として指定された属性が使用されます。
ユーザー定義の名前マッピング
groupUIDNameMapping: "cn=group1,ou=groups,dc=example,dc=com": firstgroup "cn=group2,ou=groups,dc=example,dc=com": secondgroup "cn=group3,ou=groups,dc=example,dc=com": thirdgroup
groupUIDNameMapping:
"cn=group1,ou=groups,dc=example,dc=com": firstgroup
"cn=group2,ou=groups,dc=example,dc=com": secondgroup
"cn=group3,ou=groups,dc=example,dc=com": thirdgroup
14.1.1. RFC 2307 設定ファイルについて リンクのコピーリンクがクリップボードにコピーされました!
RFC 2307 スキーマでは、ユーザーエントリーとグループエントリーの両方の LDAP クエリー定義と、内部 Red Hat OpenShift Service on AWS レコードでそれらのエントリーを表すのに使用する属性を指定する必要があります。
明確にするために、Red Hat OpenShift Service on AWS で作成するグループでは、ユーザーまたは管理者側のフィールドに識別名以外の属性を可能な限り使用する必要があります。たとえば、Red Hat OpenShift Service on AWS グループのユーザーをメールアドレスで識別し、グループの名前を一般名として使用します。以下の設定ファイルでは、このような関係を作成しています。
ユーザー定義名のマッピングを使用する場合は、設定ファイルが異なります。
RFC 2307 スキーマを使用する LDAP 同期設定: rfc2307_config.yaml
- 1
- このグループのレコードが保存される LDAP サーバーの IP アドレスとホストです。
- 2
false
の場合は、セキュアな LDAP (ldaps://
) URL は TLS を使用して接続し、非セキュアな LDAP (ldap://
) URL は TLS にアップグレードされます。true
の場合、サーバーへの TLS 接続は行われません。ldaps://
URL スキームは使用できません。- 3
- LDAP サーバーのグループを一意に識別する属性です。
groupUIDAttribute
に DN を使用している場合は、groupsQuery
フィルターを指定できません。詳細なフィルターを実行するには、ホワイトリスト/ブラックリストの方法を使用します。 - 4
- グループの名前として使用する属性。
- 5
- メンバーシップ情報を保存するグループの属性です。
- 6
- LDAP サーバーでユーザーを一意に識別する属性です。userUIDAttribute に DN を使用している場合は、
usersQuery
フィルターを指定できません。詳細なフィルターを実行するには、ホワイトリスト/ブラックリストの方法を使用します。 - 7
- Red Hat OpenShift Service on AWS グループレコードでユーザーの名前として使用する属性。
14.1.2. Active Directory 設定ファイルについて リンクのコピーリンクがクリップボードにコピーされました!
Active Directory スキーマでは、ユーザーエントリーの LDAP クエリー定義と、内部 Red Hat OpenShift Service on AWS グループレコードでそれらのエントリーを表すのに使用する属性を指定する必要があります。
明確にするために、Red Hat OpenShift Service on AWS で作成するグループでは、ユーザーまたは管理者側のフィールドに識別名以外の属性を可能な限り使用する必要があります。たとえば、Red Hat OpenShift Service on AWS グループのユーザーをメールアドレスで識別し、グループ名を LDAP サーバーのグループ名で定義します。以下の設定ファイルでは、このような関係を作成しています。
Active Directory スキーマを使用する LDAP 同期設定: active_directory_config.yaml
14.1.3. 拡張された Active Directory 設定ファイルについて リンクのコピーリンクがクリップボードにコピーされました!
拡張された Active Directory スキーマでは、ユーザーエントリーとグループエントリーの両方の LDAP クエリー定義と、内部 Red Hat OpenShift Service on AWS グループレコードでそれらのエントリーを表すのに使用する属性を指定する必要があります。
明確にするために、Red Hat OpenShift Service on AWS で作成するグループでは、ユーザーまたは管理者側のフィールドに識別名以外の属性を可能な限り使用する必要があります。たとえば、Red Hat OpenShift Service on AWS グループのユーザーをメールアドレスで識別し、グループの名前を一般名として使用します。以下の設定ファイルではこのような関係を作成しています。
拡張された Active Directory スキーマを使用する LDAP 同期設定: augmented_active_directory_config.yaml
14.2. LDAP 同期の実行 リンクのコピーリンクがクリップボードにコピーされました!
同期設定ファイルを作成後、同期を開始できます。Red Hat OpenShift Service on AWS では、管理者は同じサーバーを使用して多数の異なる同期タイプを実行できます。
14.2.1. LDAP サーバーと Red Hat OpenShift Service on AWS の同期 リンクのコピーリンクがクリップボードにコピーされました!
LDAP サーバーのすべてのグループを Red Hat OpenShift Service on AWS と同期できます。
前提条件
- 同期設定ファイルを作成している。
-
dedicated-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
LDAP サーバーのすべてのグループを Red Hat OpenShift Service on AWS と同期するには、以下を実行します。
oc adm groups sync --sync-config=config.yaml --confirm
$ oc adm groups sync --sync-config=config.yaml --confirm
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記デフォルトでは、すべてのグループ同期操作がドライランされるため、Red Hat OpenShift Service on AWS グループレコードを変更するには、
oc adm groups sync
コマンドで--confirm
フラグを設定する必要があります。
14.2.2. Red Hat OpenShift Service on AWS グループと LDAP サーバーの同期 リンクのコピーリンクがクリップボードにコピーされました!
設定ファイルで指定した LDAP サーバー内のグループに対応する、Red Hat OpenShift Service on AWS 内のすべてのグループを同期できます。
前提条件
- 同期設定ファイルを作成している。
-
dedicated-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
Red Hat OpenShift Service on AWS グループを LDAP サーバーと同期するには、以下を実行します。
oc adm groups sync --type=openshift --sync-config=config.yaml --confirm
$ oc adm groups sync --type=openshift --sync-config=config.yaml --confirm
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記デフォルトでは、すべてのグループ同期操作がドライランされるため、Red Hat OpenShift Service on AWS グループレコードを変更するには、
oc adm groups sync
コマンドで--confirm
フラグを設定する必要があります。
14.2.3. LDAP サーバーのサブグループと Red Hat OpenShift Service on AWS の同期 リンクのコピーリンクがクリップボードにコピーされました!
LDAP グループのサブセットを、ホワイトリストファイル、ブラックリストファイル、またはその両方を使用して、Red Hat OpenShift Service on AWS と同期できます。
ブラックリストファイル、ホワイトリストファイル、またはホワイトリストのリテラルの組み合わせを使用できます。ホワイトリストおよびブラックリストのファイルには 1 行ごとに 1 つの固有のグループ識別子を含める必要があり、ホワイトリストのリテラルはコマンド自体に直接含めることができます。これらのガイドラインは、Red Hat OpenShift Service on AWS にすでに存在するグループだけでなく、LDAP サーバー上にあるグループにも適用されます。
前提条件
- 同期設定ファイルを作成している。
-
dedicated-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
LDAP グループのサブセットを Red Hat OpenShift Service on AWS と同期するには、次のコマンドのいずれかを使用します。
oc adm groups sync --whitelist=<whitelist_file> \ --sync-config=config.yaml \ --confirm
$ oc adm groups sync --whitelist=<whitelist_file> \ --sync-config=config.yaml \ --confirm
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm groups sync --blacklist=<blacklist_file> \ --sync-config=config.yaml \ --confirm
$ oc adm groups sync --blacklist=<blacklist_file> \ --sync-config=config.yaml \ --confirm
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm groups sync <group_unique_identifier> \ --sync-config=config.yaml \ --confirm
$ oc adm groups sync <group_unique_identifier> \ --sync-config=config.yaml \ --confirm
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm groups sync <group_unique_identifier> \ --whitelist=<whitelist_file> \ --blacklist=<blacklist_file> \ --sync-config=config.yaml \ --confirm
$ oc adm groups sync <group_unique_identifier> \ --whitelist=<whitelist_file> \ --blacklist=<blacklist_file> \ --sync-config=config.yaml \ --confirm
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm groups sync --type=openshift \ --whitelist=<whitelist_file> \ --sync-config=config.yaml \ --confirm
$ oc adm groups sync --type=openshift \ --whitelist=<whitelist_file> \ --sync-config=config.yaml \ --confirm
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記デフォルトでは、すべてのグループ同期操作がドライランされるため、Red Hat OpenShift Service on AWS グループレコードを変更するには、
oc adm groups sync
コマンドで--confirm
フラグを設定する必要があります。
14.3. グループのプルーニングジョブの実行 リンクのコピーリンクがクリップボードにコピーされました!
グループを作成した LDAP サーバーのレコードが存在しなくなった場合、管理者は Red Hat OpenShift Service on AWS レコードからグループを削除することもできます。プルーニングジョブは、同期ジョブに使用されるものと同じ同期設定ファイルおよびホワイトリストまたはブラックリストを受け入れます。
以下に例を示します。
oc adm prune groups --sync-config=/path/to/ldap-sync-config.yaml --confirm
$ oc adm prune groups --sync-config=/path/to/ldap-sync-config.yaml --confirm
oc adm prune groups --whitelist=/path/to/whitelist.txt --sync-config=/path/to/ldap-sync-config.yaml --confirm
$ oc adm prune groups --whitelist=/path/to/whitelist.txt --sync-config=/path/to/ldap-sync-config.yaml --confirm
oc adm prune groups --blacklist=/path/to/blacklist.txt --sync-config=/path/to/ldap-sync-config.yaml --confirm
$ oc adm prune groups --blacklist=/path/to/blacklist.txt --sync-config=/path/to/ldap-sync-config.yaml --confirm
14.4. LDAP グループの同期の例 リンクのコピーリンクがクリップボードにコピーされました!
このセクションには、RFC 2307、Active Directory、および拡張 Active Directory スキーマに関する例が記載されています。
これらの例では、すべてのユーザーがそれぞれのグループの直接的なメンバーであることを想定しています。とくに、グループには他のグループがメンバーとして含まれません。ネスト化されたグループを同期する方法の詳細は、ネスト化されたメンバーシップ同期の例を参照してください。
14.4.1. RFC 2307 スキーマの使用によるグループの同期 リンクのコピーリンクがクリップボードにコピーされました!
RFC 2307 スキーマの場合、以下の例では 2 名のメンバー (Jane
と Jim
) を持つ admins
というグループを同期します。以下に例を示します。
- グループとユーザーが LDAP サーバーに追加される方法。
- 同期後に生成される Red Hat OpenShift Service on AWS のグループレコード。
これらの例では、すべてのユーザーがそれぞれのグループの直接的なメンバーであることを想定しています。とくに、グループには他のグループがメンバーとして含まれません。ネスト化されたグループを同期する方法の詳細は、ネスト化されたメンバーシップ同期の例を参照してください。
RFC 2307 スキーマでは、ユーザー (Jane と Jim) とグループの両方がファーストクラスエントリーとして LDAP サーバーに存在し、グループメンバーシップはグループの属性に保存されます。以下の ldif
のスニペットでは、このスキーマのユーザーとグループを定義しています。
RFC 2307 スキーマを使用する LDAP エントリー: rfc2307.ldif
前提条件
- 設定ファイルを作成している。
-
dedicated-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
rfc2307_config.yaml
ファイルと同期します。oc adm groups sync --sync-config=rfc2307_config.yaml --confirm
$ oc adm groups sync --sync-config=rfc2307_config.yaml --confirm
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Red Hat OpenShift Service on AWS は、上記の同期操作の結果として次のグループレコードを作成します。
rfc2307_config.yaml
ファイルを使用して作成される Red Hat OpenShift Service on AWS グループCopy to Clipboard Copied! Toggle word wrap Toggle overflow
14.4.2. ユーザー定義の名前マッピングに関する RFC2307 スキーマを使用したグループの同期 リンクのコピーリンクがクリップボードにコピーされました!
グループとユーザー定義の名前マッピングを同期する場合、設定ファイルは、以下に示すこれらのマッピングが含まれるように変更されます。
ユーザー定義の名前マッピングに関する RFC 2307 スキーマを使用する LDAP 同期設定: rfc2307_config_user_defined.yaml
- 1
- ユーザー定義の名前マッピングです。
- 2
- ユーザー定義の名前マッピングでキーに使用される固有の識別属性です。groupUIDAttribute に DN を使用している場合は
groupsQuery
フィルターを指定できません。詳細なフィルターを実行するには、ホワイトリスト/ブラックリストの方法を使用します。 - 3
- Red Hat OpenShift Service on AWS グループの固有の識別子がユーザー定義の名前マッピングにない場合に、Red Hat OpenShift Service on AWS グループに名前を付けるための属性。
- 4
- LDAP サーバーでユーザーを一意に識別する属性です。userUIDAttribute に DN を使用している場合は、
usersQuery
フィルターを指定できません。詳細なフィルターを実行するには、ホワイトリスト/ブラックリストの方法を使用します。
前提条件
- 設定ファイルを作成している。
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
rfc2307_config_user_defined.yaml
ファイルとの同期を実行します。oc adm groups sync --sync-config=rfc2307_config_user_defined.yaml --confirm
$ oc adm groups sync --sync-config=rfc2307_config_user_defined.yaml --confirm
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Red Hat OpenShift Service on AWS は、上記の同期操作の結果として次のグループレコードを作成します。
rfc2307_config_user_define.yaml
ファイルを使用して作成される Red Hat OpenShift Service on AWS グループCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ユーザー定義の名前マッピングが指定するグループ名です。
14.4.3. ユーザー定義のエラートレランスに関する RFC 2307 の使用によるグループの同期 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、同期されるグループにメンバークエリーで定義された範囲外にあるエントリーを持つメンバーが含まれる場合、グループ同期は以下のエラーを出して失敗します。
Error determining LDAP group membership for "<group>": membership lookup for user "<user>" in group "<group>" failed because of "search for entry with dn="<user-dn>" would search outside of the base dn specified (dn="<base-dn>")".
Error determining LDAP group membership for "<group>": membership lookup for user "<user>" in group "<group>" failed because of "search for entry with dn="<user-dn>" would search outside of the base dn specified (dn="<base-dn>")".
これは usersQuery
フィールドの baseDN
の設定が間違っていることを示していることがよくあります。ただし、baseDN
にグループの一部のメンバーが意図的に含まれていない場合、tolerateMemberOutOfScopeErrors: true
を設定することでグループ同期が継続されます。範囲外のメンバーは無視されます。
同様に、グループ同期プロセスでグループのメンバーの検出に失敗した場合、同期はエラーを出して失敗します。
Error determining LDAP group membership for "<group>": membership lookup for user "<user>" in group "<group>" failed because of "search for entry with base dn="<user-dn>" refers to a non-existent entry". Error determining LDAP group membership for "<group>": membership lookup for user "<user>" in group "<group>" failed because of "search for entry with base dn="<user-dn>" and filter "<filter>" did not return any results".
Error determining LDAP group membership for "<group>": membership lookup for user "<user>" in group "<group>" failed because of "search for entry with base dn="<user-dn>" refers to a non-existent entry".
Error determining LDAP group membership for "<group>": membership lookup for user "<user>" in group "<group>" failed because of "search for entry with base dn="<user-dn>" and filter "<filter>" did not return any results".
これは usersQuery
フィールドの設定が間違っていることを示していることがよくあります。ただし、グループに欠落していると認識されているメンバーエントリーが含まれる場合、tolerateMemberNotFoundErrors: true
を設定することでグループ同期が継続されます。問題のあるメンバーは無視されます。
LDAP グループ同期のエラートレランスを有効にすると、同期プロセスは問題のあるメンバーエントリーを無視します。LDAP グループ同期が正しく設定されていない場合、同期された Red Hat OpenShift Service on AWS グループのメンバーが欠落する可能性があります。
問題のあるグループメンバーシップに関する RFC 2307 スキーマを使用する LDAP エントリー: rfc2307_problematic_users.ldif
上記の例でエラーを許容するには、以下を同期設定ファイルに追加する必要があります。
エラーを許容する RFC 2307 スキーマを使用した LDAP 同期設定: rfc2307_config_tolerating.yaml
- 1
- LDAP サーバーでユーザーを一意に識別する属性です。userUIDAttribute に DN を使用している場合は、
usersQuery
フィルターを指定できません。詳細なフィルターを実行するには、ホワイトリスト/ブラックリストの方法を使用します。 - 2
true
の場合、同期ジョブは一部のメンバーが見つからなかったグループを許容し、LDAP エントリーが見つからなかったメンバーは無視されます。グループのメンバーが見つからないと、同期ジョブのデフォルト動作が失敗します。- 3
true
の場合、同期ジョブは、一部のメンバーがusersQuery
ベース DN で指定されるユーザー範囲外にいるグループを許容し、メンバークエリー範囲外のメンバーは無視されます。グループのメンバーが範囲外にあると、同期ジョブのデフォルト動作が失敗します。
前提条件
- 設定ファイルを作成している。
-
dedicated-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
rfc2307_config_tolerating.yaml
ファイルを使用して同期を実行します。oc adm groups sync --sync-config=rfc2307_config_tolerating.yaml --confirm
$ oc adm groups sync --sync-config=rfc2307_config_tolerating.yaml --confirm
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Red Hat OpenShift Service on AWS は、上記の同期操作の結果として次のグループレコードを作成します。
rfc2307_config.yaml
ファイルを使用して作成される Red Hat OpenShift Service on AWS グループCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 同期ファイルで指定されるグループのメンバーのユーザーです。検索中に許容されるエラーがないメンバーです。
14.4.4. Active Directory スキーマの使用によるグループの同期 リンクのコピーリンクがクリップボードにコピーされました!
Active Directory スキーマでは、両方のユーザー (Jane と Jim) がファーストクラスエントリーとして LDAP サーバーに存在し、グループメンバーシップはユーザーの属性に保存されます。以下の ldif
のスニペットでは、このスキーマのユーザーとグループを定義しています。
Active Directory スキーマを使用する LDAP エントリー: active_directory.ldif
- 1
- ユーザーのグループメンバーシップはユーザーの属性としてリスト表示され、グループはサーバー上にエントリーとして存在しません。
memberOf
属性は、ユーザーのリテラル属性である必要はありません。一部の LDAP サーバーでは、検索中に作成され、クライアントに返されますが、データベースにはコミットされません。
前提条件
- 設定ファイルを作成している。
-
dedicated-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
active_directory_config.yaml
ファイルを使用して同期を実行します。oc adm groups sync --sync-config=active_directory_config.yaml --confirm
$ oc adm groups sync --sync-config=active_directory_config.yaml --confirm
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Red Hat OpenShift Service on AWS は、上記の同期操作の結果として次のグループレコードを作成します。
active_directory_config.yaml
ファイルを使用して作成される Red Hat OpenShift Service on AWS グループCopy to Clipboard Copied! Toggle word wrap Toggle overflow
14.4.5. 拡張された Active Directory スキーマの使用によるグループの同期 リンクのコピーリンクがクリップボードにコピーされました!
拡張された Active Directory スキーマでは、両方のユーザー (Jane と Jim) とグループがファーストクラスエントリーとして LDAP サーバーに存在し、グループメンバーシップはユーザーの属性に保存されます。以下の ldif
のスニペットでは、このスキーマのユーザーとグループを定義しています。
拡張された Active Directory スキーマを使用する LDAP エントリー: augmented_active_directory.ldif
前提条件
- 設定ファイルを作成している。
-
dedicated-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
augmented_active_directory_config.yaml
ファイルを使用して同期を実行します。oc adm groups sync --sync-config=augmented_active_directory_config.yaml --confirm
$ oc adm groups sync --sync-config=augmented_active_directory_config.yaml --confirm
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Red Hat OpenShift Service on AWS は、上記の同期操作の結果として次のグループレコードを作成します。
augmented_active_directory_config.yaml
ファイルを使用して作成される Red Hat OpenShift Service on AWS グループCopy to Clipboard Copied! Toggle word wrap Toggle overflow
14.4.5.1. LDAP のネスト化されたメンバーシップ同期の例 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS のグループはネストされません。LDAP サーバーはデータが使用される前にグループメンバーシップを平坦化する必要があります。Microsoft の Active Directory Server は、LDAP_MATCHING_RULE_IN_CHAIN
ルールによりこの機能をサポートしており、これには OID 1.2.840.113556.1.4.1941
が設定されています。さらに、このマッチングルールを使用すると、明示的にホワイトリスト化されたグループのみを同期できます。
このセクションでは、拡張された Active Directory スキーマの例を取り上げ、1 名のユーザー Jane
と 1 つのグループ otheradmins
をメンバーとして持つ admins
というグループを同期します。otheradmins
グループには 1 名のユーザーメンバー Jim
が含まれます。この例では以下のことを説明しています。
- グループとユーザーが LDAP サーバーに追加される方法。
- LDAP 同期設定ファイルの概観。
- 同期後に生成される Red Hat OpenShift Service on AWS のグループレコード。
拡張された Active Directory スキーマでは、ユーザー (Jane
と Jim
) とグループの両方がファーストクラスエントリーとして LDAP サーバーに存在し、グループメンバーシップはユーザーまたはグループの属性に保存されます。以下の ldif
のスニペットはこのスキーマのユーザーとグループを定義します。
ネスト化されたメンバーを持つ拡張された Active Directory スキーマを使用する LDAP エントリー: augmented_active_directory_nested.ldif
ネストされたグループを Active Directory と同期する場合、ユーザーエントリーとグループエントリーの両方の LDAP クエリー定義と、内部 Red Hat OpenShift Service on AWS グループレコードでそれらのエントリーを表すのに使用する属性を指定する必要があります。さらに、この設定では特定の変更が必要となります。
-
oc adm groups sync
コマンドはグループを明示的にホワイトリスト化する必要があります。 -
LDAP_MATCHING_RULE_IN_CHAIN
ルールに準拠するために、ユーザーのgroupMembershipAttributes
に"memberOf:1.2.840.113556.1.4.1941:"
を追加する必要があります。 -
groupUIDAttribute
をdn
に設定する必要があります。 groupsQuery
:-
filter
を設定しないでください。 -
有効な
derefAliases
を設定する必要があります。 -
baseDN
を設定しないでください。この値は無視されます。 -
scope
を設定しないでください。この値は無視されます。
-
明確にするために、Red Hat OpenShift Service on AWS で作成するグループでは、ユーザーまたは管理者側のフィールドに識別名以外の属性を可能な限り使用する必要があります。たとえば、Red Hat OpenShift Service on AWS グループのユーザーをメールアドレスで識別し、グループの名前を一般名として使用します。以下の設定ファイルでは、このような関係を作成しています。
ネスト化されたメンバーを持つ拡張された Active Directory スキーマを使用する LDAP 同期設定です。augmented_active_directory_config_nested.yaml
- 1
groupsQuery
フィルターは指定できません。groupsQuery
ベース DN およびスコープの値は無視されます。groupsQuery
では有効なderefAliases
を設定する必要があります。- 2
- LDAP サーバーのグループを一意に識別する属性です。
dn
に設定される必要があります。 - 3
- グループの名前として使用する属性。
- 4
- Red Hat OpenShift Service on AWS グループレコードでユーザーの名前として使用する属性。ほとんどのインストールでは、
mail
またはsAMAccountName
を使用することが推奨されます。 - 5
- メンバーシップ情報を保存するユーザーの属性です。
LDAP_MATCHING_RULE_IN_CHAIN
. を使用することに注意してください。
前提条件
- 設定ファイルを作成している。
-
dedicated-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
augmented_active_directory_config_nested.yaml
ファイルを使用して同期を実行します。oc adm groups sync \ 'cn=admins,ou=groups,dc=example,dc=com' \ --sync-config=augmented_active_directory_config_nested.yaml \ --confirm
$ oc adm groups sync \ 'cn=admins,ou=groups,dc=example,dc=com' \ --sync-config=augmented_active_directory_config_nested.yaml \ --confirm
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記cn=admins,ou=groups,dc=example,dc=com
グループを明示的にホワイトリスト化する必要があります。Red Hat OpenShift Service on AWS は、上記の同期操作の結果として次のグループレコードを作成します。
augmented_active_directory_config_nested.yaml
ファイルを使用して作成される Red Hat OpenShift Service on AWS グループCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- この Red Hat OpenShift Service on AWS グループが LDAP サーバーと最後に同期された時刻 (ISO 6801 形式)。
- 2
- LDAP サーバーのグループの固有識別子です。
- 3
- このグループのレコードが保存される LDAP サーバーの IP アドレスとホストです。
- 4
- 同期ファイルが指定するグループ名です。
- 5
- グループのメンバーのユーザーです。同期ファイルで指定される名前が使用されます。グループメンバーシップは Microsoft Active Directory Server によって平坦化されているため、ネスト化されたグループのメンバーが含まれることに注意してください。
14.5. LDAP 同期設定の仕様 リンクのコピーリンクがクリップボードにコピーされました!
設定ファイルのオブジェクト仕様は以下で説明されています。スキーマオブジェクトにはそれぞれのフィールドがあることに注意してください。たとえば、v1.ActiveDirectoryConfig には groupsQuery
フィールドがありませんが、v1.RFC2307Config と v1.AugmentedActiveDirectoryConfig の両方にこのフィールドがあります。
バイナリー属性はサポートされていません。LDAP サーバーの全属性データは、UTF-8 エンコード文字列の形式である必要があります。たとえば、ID 属性として、バイナリー属性を使用することはできません (例: objectGUID
)。代わりに sAMAccountName
、userPrincipalName
などの文字列属性を使用する必要があります。
14.5.1. v1.LDAPSyncConfig リンクのコピーリンクがクリップボードにコピーされました!
LDAPSyncConfig
は、LDAP グループ同期を定義するために必要な設定オプションを保持します。
名前 | 説明 | スキーマ |
---|---|---|
| このオブジェクトが表す REST リソースを表す文字列の値です。サーバーはクライアントが要求を送信するエンドポイントからこれを推測できることがあります。これは更新できません。CamelCase を使用します。詳細は、https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#types-kinds を参照してください。 | string |
| オブジェクトのこの表現のバージョンスキーマを定義します。サーバーは認識されたスキーマを最新の内部値に変換し、認識されない値は拒否することがあります。詳細は、https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#resources を参照してください。 | string |
|
ホストは接続先の LDAP サーバーのスキーム、ホストおよびポートになります ( | string |
| LDAP サーバーをバインドする任意の DN です。 | string |
| 検索フェーズでバインドする任意のパスワードです。 | v1.StringSource |
|
| boolean |
| サーバーへ要求を行う際に使用する任意の信頼された認証局バンドルです。空の場合は、デフォルトのシステムルートが使用されます。 | string |
| LDAP グループ UID から Red Hat OpenShift Service on AWS グループ名への直接マッピングです (省略可能)。 | オブジェクト |
| RFC2307 と同じ方法でセットアップされた LDAP サーバーからデータを抽出するための設定を保持します。ファーストクラスグループとユーザーエントリーを抽出し、グループメンバーシップはメンバーをリスト表示するグループエントリーの複数値の属性によって決定されます。 | v1.RFC2307Config |
| Active Directory に使用されるのと同じ方法でセットアップされた LDAP サーバーからデータを抽出するための設定を保持します。ファーストクラスユーザーエントリーを抽出し、グループメンバーシップはメンバーが属するグループをリスト表示するメンバーの複数値の属性によって決定されます。 | v1.ActiveDirectoryConfig |
| 上記の Active Directory で使用されるのと同じ方法でセットアップされた LDAP サーバーからデータを抽出するための設定を保持します。1 つの追加として、ファーストクラスグループエントリーが存在し、それらはメタデータを保持するために使用されますが、グループメンバーシップは設定されません。 | v1.AugmentedActiveDirectoryConfig |
14.5.2. v1.StringSource リンクのコピーリンクがクリップボードにコピーされました!
StringSource
によって文字列インラインを指定できます。または環境変数またはファイルを使用して外部から指定することもできます。文字列の値のみを含む場合は、単純な JSON 文字列にマーシャルします。
名前 | 説明 | スキーマ |
---|---|---|
|
クリアテキスト値、または | string |
|
クリアテキスト値、または | string |
|
クリアテキスト値、または | string |
| 値を復号化するために使用するキーを含むファイルを参照します。 | string |
14.5.3. v1.LDAPQuery リンクのコピーリンクがクリップボードにコピーされました!
LDAPQuery
は LDAP クエリーの作成に必要なオプションを保持します。
名前 | 説明 | スキーマ |
---|---|---|
| すべての検索が開始されるディレクトリーのブランチの DN です。 | string |
|
検索の任意の範囲です。 | string |
|
エイリアスに関する検索の任意の動作です。 | string |
|
応答の待機を中止するまでにサーバーへの要求を未処理のままにする時間制限 (秒単位) を保持します。これを | integer |
| ベース DN を持つ LDAP サーバーから関連するすべてのエントリーを取得する有効な LDAP 検索フィルターです。 | string |
|
LDAP エントリーで測定される、推奨される最大ページサイズです。ページサイズを | integer |
14.5.4. v1.RFC2307Config リンクのコピーリンクがクリップボードにコピーされました!
RFC2307Config
は、RFC2307 スキーマを使用してどのように LDAP グループ同期が LDAP サーバーに相互作用するかを定義するために必要な設定オプションを保持します。
名前 | 説明 | スキーマ |
---|---|---|
| グループエントリーを返す LDAP クエリーのテンプレートを保持します。 | v1.LDAPQuery |
|
LDAP グループエントリーのどの属性を固有の識別子として解釈するかを定義します ( | string |
| LDAP グループエントリーのどの属性を Red Hat OpenShift Service on AWS グループに使用する名前として解釈するかを定義します。 | string array |
|
LDAP グループエントリーのどの属性をメンバーとして解釈するかを定義します。それらの属性に含まれる値は | string array |
| ユーザーエントリーを返す LDAP クエリーのテンプレートを保持します。 | v1.LDAPQuery |
|
LDAP ユーザーエントリーのどの属性を固有の識別子として解釈するかを定義します。 | string |
|
LDAP ユーザーエントリーのどの属性を Red Hat OpenShift Service on AWS ユーザー名として順番に使用するかを定義します。空でない値を持つ最初の属性が使用されます。これは | string array |
|
ユーザーエントリーがない場合の LDAP 同期ジョブの動作を決定します。 | boolean |
|
範囲外のユーザーエントリーが検出される場合の LDAP 同期ジョブの動作を決定します。 | boolean |
14.5.5. v1.ActiveDirectoryConfig リンクのコピーリンクがクリップボードにコピーされました!
ActiveDirectoryConfig
は必要な設定オプションを保持し、どのように LDAP グループ同期が Active Directory スキーマを使用して LDAP サーバーと相互作用するかを定義します。
名前 | 説明 | スキーマ |
---|---|---|
| ユーザーエントリーを返す LDAP クエリーのテンプレートを保持します。 | v1.LDAPQuery |
|
LDAP ユーザーエントリーのどの属性を Red Hat OpenShift Service on AWS ユーザー名として解釈するかを定義します。Red Hat OpenShift Service on AWS グループレコードでユーザーの名前として使用する属性。ほとんどのインストールでは、 | string array |
| LDAP ユーザーのどの属性をメンバーの属するグループとして解釈するかを定義します。 | string array |
14.5.6. v1.AugmentedActiveDirectoryConfig リンクのコピーリンクがクリップボードにコピーされました!
AugmentedActiveDirectoryConfig
は必要な設定オプションを保持し、どのように LDAP グループ同期が拡張された Active Directory スキーマを使用して LDAP サーバーに相互作用するかを定義します。
名前 | 説明 | スキーマ |
---|---|---|
| ユーザーエントリーを返す LDAP クエリーのテンプレートを保持します。 | v1.LDAPQuery |
|
LDAP ユーザーエントリーのどの属性を Red Hat OpenShift Service on AWS ユーザー名として解釈するかを定義します。Red Hat OpenShift Service on AWS グループレコードでユーザーの名前として使用する属性。ほとんどのインストールでは、 | string array |
| LDAP ユーザーのどの属性をメンバーの属するグループとして解釈するかを定義します。 | string array |
| グループエントリーを返す LDAP クエリーのテンプレートを保持します。 | v1.LDAPQuery |
|
LDAP グループエントリーのどの属性を固有の識別子として解釈するかを定義します ( | string |
| LDAP グループエントリーのどの属性を Red Hat OpenShift Service on AWS グループに使用する名前として解釈するかを定義します。 | string array |
Legal Notice
リンクのコピーリンクがクリップボードにコピーされました!
Copyright © 2025 Red Hat
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.