Red Hat SummitThis documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.第4章 追加の概念
4.1. 認証
4.1.1. 概要
認証層は、OpenShift Container Platform API への要求に関連付けられたユーザーを識別します。次に、認証層は要求が許可されるかどうかを判別するために要求側のユーザーについての情報を使用します。
管理者は、「マスター設定ファイル」を使用して、「認証の設定」を実行できます。
4.1.2. ユーザーとグループ
OpenShift Container Platform の ユーザー は、OpenShift Container Platform API に要求できるエンティティーです。通常、これは OpenShift Container Platform と対話している開発者または管理者のアカウントを表します。
ユーザーは 1 つ以上の グループ に割り当てることができます。それぞれのグループはユーザーの特定のセットを表します。グループは、「承認ポリシーを管理」し、パーミッションを一度に複数ユーザーに付与する場合などに役立ちます。この例としては、アクセス権限をユーザーに別々に付与するのではなく、プロジェクト内のオブジェクトへのアクセスを許可する場合などがあります。
明示的に定義されたグループのほかにも、OpenShift で自動的にプロビジョニングされるシステムグループまたは 仮想グループ があります。このようなグループは、「クラスターのバインディングを表示」すると確認できます。
仮想グループのデフォルトセットでは、とくに以下の点に留意してください。
| 仮想グループ | 説明 |
|---|---|
|
system:authenticated |
認証されたユーザーに自動的に関連付けられます。 |
|
system:authenticated:oauth |
OAuth アクセストークンで認証されたすべてのユーザーに自動的に関連付けられます。 |
|
system:unauthenticated |
認証されていないすべてのユーザーに自動的に関連付けられます。 |
4.1.3. API 認証
OpenShift Container Platform API への要求は以下の方法で認証されます。
- OAuth アクセストークン
-
<master>/oauth/authorizeおよび<master>/oauth/tokenエンドポイントを使用して OpenShift Container Platform OAuth サーバーから取得されます。 -
Authorization: Bearer…ヘッダーとして送信されます。 -
OpenShift Container Platform server version 3.6 よりも前のバージョンでは、websocket 要求の
access_token=…クエリーパラメーターとして送信されます。 -
OpenShift Container Platform サーバーのバージョン 3.6 以降で、websocket 要求の
base64url.bearer.authorization.k8s.io.<base64url-encoded-token>形式で websocket サブプロトコルヘッダーとして送信されます。
-
- X.509 クライアント証明書
- API サーバーへの HTTPS 接続を要求します。
- 信頼される認証局バンドルに対して API サーバーによって検証されます。
- API サーバーは証明書を作成し、これをコントローラーに配布してそれらを認証できるようにします。
無効なアクセストークンまたは無効な証明書での要求は認証層によって拒否され、401 エラーが出されます。
アクセストークンまたは証明書が提供されない場合、認証層は system:anonymous 仮想ユーザーおよび system:unauthenticated 仮想グループを要求に割り当てます。これにより、認証層は匿名ユーザーが実行できる要求 (ある場合) を決定できます。
4.1.3.1. 権限の借用
OpenShift Container Platform API への要求いは、要求側が要求を指定されたユーザーからのものであるかのように処理されることを希望することを示す、Impersonate-User ヘッダーが含まれる場合があります。このユーザーのなりすましは、--as=<user> フラグを要求に追加して実行できます。
ユーザー A がユーザー B の権限を借用できるのは、ユーザー A が認証されてからです。ユーザー A がユーザー B という名前のユーザーの権限を借用できるように、認証チェックが行われます。ユーザー A が、サービスアカウント system:serviceaccount:namespace:name の権限借用を要求する場合には、OpenShift Container Platform は、ユーザー A が namespace の name という名前の serviceaccount の権限を借用できることを確認します。チェックに失敗すると、この要求は 403 (Forbidden) エラーコードで失敗します。
デフォルトで、プロジェクト管理者およびエディターは、その namespace に含まれるサービスアカウントの権限を借用できます。ユーザーは、sudoer ロールを使用して、system:admin の権限を借用できるので、クラスター管理者のパーミッションが使えるようになります。system:admin の権限を借用できることで、誤植の発生を防ぐことはできますが、クラスターの管理者に対してセキュリティーを確保するわけではありません。たとえば、oc delete nodes --all を実行すると失敗するにも拘わらず、oc delete nodes --all --as=system:admin を実行すると成功します。以下のコマンドを実行してユーザーにこのパーミッションを付与できます。
oc create clusterrolebinding <any_valid_name> --clusterrole=sudoer --user=<username>
$ oc create clusterrolebinding <any_valid_name> --clusterrole=sudoer --user=<username>
ユーザーの代わりにプロジェクトの要求を作成する必要がある場合、--as=<user> --as-group=<group1> --as-group=<group2> フラグをコマンドに組み込みます。system:authenticated:oauth はプロジェクト要求を作成できる唯一のブートストラップグループであるため、そのグループを以下の例に示されるようになりすます必要があります。
oc new-project <project> --as=<user> \ --as-group=system:authenticated --as-group=system:authenticated:oauth
$ oc new-project <project> --as=<user> \
--as-group=system:authenticated --as-group=system:authenticated:oauth4.1.4. OAuth
OpenShift Container Platform マスターには、ビルトイン OAuth サーバーが含まれます。ユーザーは OAuth アクセストークンを取得して、API に対して認証を実行します。
新規の OAuth トークンが要求されると、OAuth サーバーは設定された「アイデンティティープロバイダー」を使用して要求したユーザーのアイデンティティーを判別します。
次に、そのアイデンティティーがマップするユーザーを判別し、そのユーザーのアクセスユーザーを作成し、使用できるようにトークンを返します。
4.1.4.1. OAuth クライアント
OAuth トークンのすべての要求は、トークンを受信し、使用する OAuth クライアントを指定する必要があります。以下の OAuth クライアントは、OpenShift Container Platform API の起動時に自動的に作成されます。
| OAuth クライアント | 使用法 |
|---|---|
|
openshift-web-console |
Web コンソールのトークンを要求します。 |
|
openshift-browser-client |
対話式ログインを処理できるユーザーエージェントで |
|
openshift-challenging-client |
|
追加のクライアントを登録するには、以下を実行します。
- 1
<master>/oauth/authorizeおよび<master>/oauth/tokenへの要求を実行する際には、OAuth クライアントのnameがclient_idパラメーターとして使用されます。- 2
<master>/oauth/tokenへの要求の実行時に、secretはclient_secretパラメーターとして使用されます。- 3
<master>/oauth/authorizeおよび<master>/oauth/tokenへの要求で指定されるredirect_uriパラメーターは、redirectURIsのいずれかに等しい (またはこれによってプレフィックスが付けられた) 状態でなければなりません。- 4
grantMethodは、このクライアントがトークンを要求する際に実行するアクションを決定しますが、ユーザーによるアクセスは付与されていません。「Grant Options」に表示されるものと同じ値を使用します。
4.1.4.2. OAuth クライアントとしてのサービスアカウント
サービスアカウントは、OAuth クライアントの制限されたフォームで使用できます。サービスアカウントは一部の基本ユーザー情報へのアクセスを許可するスコープのサブセットと、サービスアカウント自体の namespace 内のロールベースの権限のみを要求できます。
-
user:info -
user:check-access -
role:<any_role>:<serviceaccount_namespace> -
role:<any_role>:<serviceaccount_namespace>:!
サービスアカウントを OAuth クライアントとして使用する場合:
-
client_idはsystem:serviceaccount:<serviceaccount_namespace>:<serviceaccount_name>になります。 client_secretには、サービスアカウントの API トークンのいずれかを指定できます。以下は例になります。oc sa get-token <serviceaccount_name>
$ oc sa get-token <serviceaccount_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
WWW-Authenticateチャレンジを取得するには、サービスアカウントのserviceaccounts.openshift.io/oauth-want-challengesアノテーションを true に設定します。 -
redirect_uriはサービスアカウントのアノテーションに一致する必要があります。詳細は、「OAuth クライアントとしてのサービスアカウントの URI のリダイレクト」を参照してください。
4.1.4.3. 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"4.1.4.3.1. OAuth の API イベント
API サーバーは、API マスターログへの直接的なアクセスがないとデバッグが困難な unexpected condition のエラーメッセージを返すことがあります。このエラーの根本的な理由は意図的に非表示にされます。認証されていないユーザーにサーバーの状態についての情報を提供することを避けるためです。
これらのエラーのサブセットは、サービスアカウントの OAuth 設定の問題に関連するものです。これらの問題は、管理者以外のユーザーが確認できるイベントでキャプチャーされます。unexpected condition というサーバーエラーが OAuth の実行時に発生する場合、oc get events を実行し、これらのイベントについて ServiceAccount で確認します。
以下の例では、適切な OAuth リダイレクト URI がないサービスアカウントに対して警告を出しています。
oc get events | grep ServiceAccount
$ oc get events | grep ServiceAccount
1m 1m 1 proxy ServiceAccount Warning NoSAOAuthRedirectURIs service-account-oauth-client-getter system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>
oc describe sa/<service-account-name> を実行すると、指定のサービスアカウント名に関連付けられた OAuth イベントが報告されます。
oc describe sa/proxy | grep -A5 Events
$ oc describe sa/proxy | grep -A5 Events
Events:
FirstSeen LastSeen Count From SubObjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
3m 3m 1 service-account-oauth-client-getter Warning NoSAOAuthRedirectURIs system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>以下は生じる可能性のあるイベントエラーの一覧です。
No redirect URI annotations or an invalid URI is specified
Reason Message NoSAOAuthRedirectURIs system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>
Reason Message
NoSAOAuthRedirectURIs system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>Invalid route specified
Reason Message NoSAOAuthRedirectURIs [routes.route.openshift.io "<name>" not found, system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]
Reason Message
NoSAOAuthRedirectURIs [routes.route.openshift.io "<name>" not found, system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]Invalid reference type specified
Reason Message NoSAOAuthRedirectURIs [no kind "<name>" is registered for version "v1", system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]
Reason Message
NoSAOAuthRedirectURIs [no kind "<name>" is registered for version "v1", system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]Missing SA tokens
Reason Message NoSAOAuthTokens system:serviceaccount:myproject:proxy has no tokens
Reason Message
NoSAOAuthTokens system:serviceaccount:myproject:proxy has no tokens4.1.4.3.1.1. 誤設定の場合に引き起こされる API イベントのサンプル
以下の手順は、ユーザーが破損状態に入る 1 つの経緯とこの問題の解決方法を示しています。
サービスアカウントを OAuth クライアントとして利用するプロジェクトを作成します。
プロキシーサービスアカウントオブジェクトの YAML を作成し、これがルートの
proxyを使用することを確認します。vi serviceaccount.yaml
vi serviceaccount.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のサンプルコードを追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow プロキシーへのセキュアな接続を作成するために、ルートオブジェクトの YAML を作成します。
vi route.yaml
vi route.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のサンプルコードを追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow プロキシーをサイドカーとして起動するために、デプロイメント設定の YAML を作成します。
vi proxysidecar.yaml
vi proxysidecar.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のサンプルコードを追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オブジェクトを作成します。
oc create -f serviceaccount.yaml oc create -f route.yaml oc create -f proxysidecar.yaml
oc create -f serviceaccount.yaml oc create -f route.yaml oc create -f proxysidecar.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
oc edit sa/proxyを実行してサービスアカウントを編集し、serviceaccounts.openshift.io/oauth-redirectreferenceアノテーションを、存在しないルートにポイントするように変更します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow OAuth ログでサービスを確認し、サーバーエラーを見つけます。
承認サーバーに、要求を満たすことを阻む予期しないエラーが発生しました。
承認サーバーに、要求を満たすことを阻む予期しないエラーが発生しました。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get eventsを実行してServiceAccountイベントを表示します。oc get events | grep ServiceAccount 23m 23m 1 proxy ServiceAccount Warning NoSAOAuthRedirectURIs service-account-oauth-client-getter [routes.route.openshift.io "notexist" not found, system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]
oc get events | grep ServiceAccount 23m 23m 1 proxy ServiceAccount Warning NoSAOAuthRedirectURIs service-account-oauth-client-getter [routes.route.openshift.io "notexist" not found, system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.1.4.4. 統合
OAuth トークンのすべての要求には、<master>/oauth/authorize への要求が関係します。ほとんどの認証統合は、認証プロキシーをこのエンドポイントの前に配置するか、または OpenShift Container Platform を、サポートする「アイデンティティープロバイダー」に対して認証情報を検証するように設定します。<master>/oauth/authorize の要求は、CLI などの対話式ログインページを表示できないユーザーエージェントから送られる場合があります。そのため、OpenShift Container Platform は、対話式ログインフローのほかにも WWW-Authenticate チャレンジを使用した認証をサポートします。
認証プロキシーが <master>/oauth/authorize エンドポイントの前に配置される場合、対話式ログインページを表示したり、対話式ログインフローにリダイレクトする代わりに、認証されていない、ブラウザー以外のユーザーエージェントの WWW-Authenticate チャレンジを送信します。
ブラウザークライアントに対するクロスサイトリクエストフォージェリー (CSRF) 攻撃を防止するため、基本的な認証チャレンジは X-CSRF-Token ヘッダーが要求に存在する場合にのみ送信されます。基本的な WWW-Authenticate チャレンジを受信する必要があるクライアントでは、このヘッダーを空でない値に設定する必要があります。
認証プロキシーが WWW-Authenticate チャレンジをサポートしないか、または OpenShift Container Platform が WWW-Authenticate チャレンジをサポートしないアイデンティティープロバイダーを使用するように設定されている場合、ユーザーはブラウザーで <master>/oauth/token/request にアクセスし、アクセストークンを手動で取得できます。
4.1.4.5. OAuth サーバーメタデータ
OpenShift Container Platform で実行されているアプリケーションは、ビルトイン OAuth サーバーについての情報を検出する必要がある場合があります。たとえば、それらは <master> サーバーのアドレスを手動の設定なしで検出する必要があります。これを支援するために、OpenShift Container Platform は IETF OAuth 2.0 Authorization Server Metadata のドラフト仕様を実装しています。
そのため、クラスター内で実行されているすべてのアプリケーションは、https://openshift.default.svc/.well-known/oauth-authorization-server に対して GET 要求を実行し、以下の情報を取得できます。
- 1
httpsスキームを使用し、クエリーまたはフラグメントコンポーネントがない承認サーバーの発行者 IDです。これは、承認サーバーについての情報が含まれる.well-knownRFC 5785 リソースが公開される場所です。- 2
- 承認サーバーの承認エンドポートの URL です。RFC 6749 を参照してください。
- 3
- 承認サーバーのトークンエンドポイントの URL です。RFC 6749 を参照してください。
- 4
- この承認サーバーがサポートする OAuth 2.0 RFC 6749 スコープの値の一覧を含む JSON 配列です。サポートされるスコープの値すべてが公開される訳ではないことに注意してください。
- 5
- この承認サーバーがサポートする OAuth 2.0
response_type値の一覧を含む JSON 配列です。使用される配列の値は、RFC 7591 の OAuth 2.0 Dynamic Client Registration Protocol で定義されるresponse_typesパラメーターで使用されるものと同じです。 - 6
- この承認サーバーがサポートする OAuth 2.0 grant type の値の一覧が含まれる JSON 配列です。使用される配列の値は、RFC 7591 の OAuth 2.0 Dynamic Client Registration Protocol で定義される
grant_typesパラメーターで使用されるものと同じです。 - 7
- この承認サーバーでサポートされる PKCE RFC 7636 コードのチャレンジメソッドの一覧が含まれる JSON 配列です。コードのチャレンジメソッドの値は、RFC 7636 のセクション 4.3 で定義される
code_challenge_methodパラメーターで使用されます。有効なコードのチャレンジメソッドの値は、IANA PKCE Code Challenge Method レジストリーで登録される値です。「IANA OAuth パラメーター」を参照してください。
4.1.4.6. OAuth トークンの取得
OAuth サーバーは、標準的な Authorization Code Grant (認可コードによるグラント) および Implicit Grant (暗黙的グラント)の OAuth 認証フローをサポートします。
OAuth トークンを、 (openshift-challenging-client などの) WWW-Authenticate challenge を要求するように設定された client_id で Implicit Grant (暗黙的グラント) フロー (response_type=token) を使用して要求する場合、以下が /oauth/authorize から送られる可能性のあるサーバー応答、およびそれらの処理方法になります。
| ステータス | 内容 | クライアント応答 |
|---|---|---|
|
302 |
URL フラグメントに |
|
|
302 |
|
失敗します。オプションで |
|
302 |
他の |
これらのルールを使用してリダイレクトに従い、結果を処理します。 |
|
401 |
|
タイプ ( |
|
401 |
|
チャレンジの承認ができません。失敗し、応答本体を表示します (これには、OAuth トークンを取得する別の方法についてのリンクまたは詳細が含まれる可能性があります) |
|
その他 |
その他 |
失敗し、オプションでユーザーに応答本体を提示します。 |
4.1.4.7. Prometheus の認証メトリクス
OpenShift Container Platform は認証の試行中に以下の Prometheus システムメトリクスをキャプチャーします。
-
openshift_auth_basic_password_countはoc loginユーザー名およびパスワードの試行回数をカウントします。 -
openshift_auth_basic_password_count_resultはoc loginユーザー名および結果 (成功またはエラー) で試行されるパスワードの回数をカウントします。 -
openshift_auth_form_password_countは Web コンソールのログイン試行回数をカウントします。 -
openshift_auth_form_password_count_resultは結果 (成功またはエラー) による Web コンソールのログイン試行回数をカウントします。 -
openshift_auth_password_totalはoc loginおよび Web コンソールのログイン試行回数をカウントします。
4.2. 承認
4.2.1. 概要
Role-based Access Control (RBAC) オブジェクトは、ユーザーがプロジェクト内の所定のアクションを実行することが許可されるかどうかを決定します。
これにより、プラットフォーム管理者はクラスターロールおよびバインディングを使用して、OpenShift Container Platform プラットフォーム自体およびすべてのプロジェクトへの各種のアクセスレベルを持つユーザーを制御できます。
これにより、開発者はローカルロールおよびバインディングを使用し、それらのプロジェクトへのアクセスを持つユーザーを制御します。承認は認証とは異なる手順であることに注意してください。認証は、アクションを実行するユーザーのアイデンティティーの判別により関連性があります。
承認は以下を使用して管理されます。
|
ルール |
オブジェクトのセットで許可された動詞を設定します。たとえば、何かが Pod の |
|
ロール |
ルールのコレクションです。ユーザーおよびグループは、同時に複数のロールに関連付けられるか、または バインド できます。 |
|
バインディング |
ロールを使ったユーザーおよび/グループ間の関連付けです。 |
クラスター管理者は、「CLI を使用」して、ルール、ロールおよびバインディングを可視化できます。
たとえば、admin および basic-user の デフォルトクラスターロールのルールセットを示す以下の抜粋を考慮してみましょう。
oc describe clusterrole.rbac admin basic-user
$ oc describe clusterrole.rbac admin basic-userローカルロールバインディングを表示して得られる以下の概要は、各種のユーザーおよびグループにバインドされた上記のロールを示しています。
oc describe rolebinding.rbac admin basic-user -n alice-project
oc describe rolebinding.rbac admin basic-user -n alice-projectクラスターロール、クラスターロールのバインディング、ローカルロールのバインディング、ユーザー、グループおよびサービスアカウントの関係は以下に説明されています。
4.2.2. 承認の評価
OpenShift Container Platform が承認を評価する際、いくつかの要因が組み合わさって決定が行われます。
|
アイデンティティー |
承認のコンテキストでは、ユーザー名およびユーザーが属するグループの一覧になります。 | ||||||
|
アクション |
実行されるアクションです。ほとんどの場合、これは以下で構成されます。
| ||||||
|
バインディング |
バインディングの詳細一覧です。 |
OpenShift Container Platform は以下の手順を使って承認を評価します。
- アイデンティティーおよびプロジェクトでスコープ設定されたアクションは、ユーザーおよびそれらのグループに適用されるすべてのバインディングを検索します。
- バインディングは、適用されるすべてのロールを見つけるために使用されます。
- ロールは、適用されるすべてのルールを見つけるために使用されます。
- 一致を見つけるために、アクションが各ルールに対してチェックされます。
- 一致するルールが見つからない場合、アクションはデフォルトで拒否されます。
4.2.3. クラスターおよびローカル RBAC
承認を制御する 2 つのレベルの RBAC ロールおよびバインディングがあります。
|
クラスター RBAC |
すべてのプロジェクトで適用可能なロールおよびバインディングです。クラスター全体で存在するロールはクラスターロールと見なされます。クラスターロール」のバインディングはクラスターロールのみを参照できます。 |
|
ローカル RBAC |
所定のプロジェクトにスコープ設定されているロールおよびバインディングです。プロジェクトにのみ存在するロールは ローカルロール とみなされます。ローカルロールのバインディングはクラスターロールおよびローカルロールの両方を参照できます。 |
この 2 つのレベルからなる階層により、ローカルロールでの個別プロジェクト内のカスタマイズが可能になる一方で、クラスターロールによる複数プロジェクト間での再利用が可能になります。
評価時に、クラスターロールのバインディングおよびローカルロールのバインディングが使用されます。以下は例になります。
- クラスター全体の「allow」ルールがチェックされます。
- ローカルにバインドされた「allow」ルールがチェックされます。
- デフォルトで拒否します。
4.2.4. クラスターロールおよびローカルロール
ロールはポリシールールのコレクションであり、一連のリソースで実行可能な一連の許可された動詞です。OpenShift Container Platform には、クラスター全体またはローカルで、ユーザーおよびグループにバインドできるデフォルトのクラスターロールのセットが含まれます。
| デフォルトのクラスターロール | 説明 |
|---|---|
|
admin |
プロジェクトマネージャーです。ローカルバインディングで使用されている場合、admin ユーザーにはプロジェクトのリソースを閲覧し、クォータを除くプロジェクトのすべてのリソースを変更する権限があります。 |
|
basic-user |
プロジェクトおよびユーザーについての基本的な情報を取得できるユーザーです。 |
|
cluster-admin |
どのプロジェクトでもすべてのアクションを実行可能なスーパーユーザー。ローカルバインディングでバインドされているユーザーの場合は、対象のプロジェクトに含まれる全リソースのクォータや全アクションに対して「フルコントロール」があります。 |
|
cluster-status |
基本的なクラスターのステータス情報を取得できるユーザーです。 |
|
edit |
プロジェクトのほとんどのプロジェクトを変更できるが、ロールまたはバインディングを表示したり、変更したりする機能を持たないユーザーです。 |
|
self-provisioner |
独自のプロジェクトを作成できるユーザーです。 |
|
view |
変更できないものの、プロジェクトでほとんどのオブジェクトを確認できるユーザーです。それらはロールまたはバインディングを表示したり、変更したりできません。 |
ユーザーおよびグループは複数のロールに同時に関連付けたり、バインド できることに注意してください。
プロジェクト管理者は、CLI を使用してそれぞれが関連付けられる動詞およびリソースのマトリックスなど、ロールを可視化し、 「ローカルロールやバインディングを表示」できます。
プロジェクト管理者にバインドされるクラスターロールは、「ローカルバインディング」によってプロジェクトに制限されます。これは、cluster-admin または system:admin に付与されるクラスターロールの場合のように「クラスター全体」でバインドされる訳ではありません。
クラスターロールは、クラスターレベルで定義されるロールですが、クラスターレベルまたはプロジェクトレベルのいずれかでバインドできます。
「プロジェクトのローカルロールの作成方法についてはこちら」を参照してください。
4.2.4.1. クラスターロールの更新
「OpenShift Container Platform のクラスターをアップグレードした後に」、デフォルトのロールが更新され、サーバーの起動時に自動調整されます。調整時に、デフォルトのロールで足りないパーミッションは追加されます。ロールに別途パーミッションを追加していた場合には、削除されます。
デフォルトのロールをカスタマイズし、自動的にロールを調節されないように設定していた場合には、OpenShift Container Platform のアップグレード時に、手動でポリシー定義を更新する必要があります。
4.2.4.2. カスタムロールおよびパーミッションの適用
カスタムロールおよびパーミッションを追加するか、または更新するには、以下のコマンドを使用することを強く推奨します。
oc auth reconcile -f FILE
# oc auth reconcile -f FILEこのコマンドは、他のクライアントを切断しない方法で新規パーミッションが適切に適用されるようにします。
4.2.4.3. クラスターロールの集計
デフォルトのクラスターの管理、編集および表示ロールは、クラスターロールの集計をサポートします。ここでは、各ロールのクラスタールールは新規ルールの作成時に動的に更新されます。この機能は、「カスタムリソースを作成」して Kubernetes API を拡張する場合にのみ該当します。
「クラスターロールの集計の使用方法についてはこちら」を参照してください。
4.2.5. SCC (Security Context Constraints)
ユーザーの実行できる内容を制御する「RBAC リソース」のほかに、OpenShift Container Platform には Pod が実行できる内容および Pod がアクセスできる内容を制御する SCC (security context constraints) が含まれます。管理者は CLI を使用して SCC を管理することができます。
SCC は永続ストレージへのアクセスを管理する場合にも非常に便利です。
SCC は、システムで許可されるために Pod の実行時に必要となる一連の条件を定義するオブジェクトです。管理者は以下を制御できます。
- 「特権付きコンテナー」 の実行
- コンテナーが要求できる機能の追加
- ホストディレクトリーのボリュームとしての使用
- コンテナーの SELinux コンテキスト
- ユーザー ID。
- ホストの namespace およびネットワークの使用
-
Pod のボリュームを所有する
FSGroupの割り当て - 許可される補助グループの設定
- 読み取り専用のルートファイルシステムの要求
- ボリュームタイプの使用の制御
- 許可される seccomp プロファイルの設定
デフォルトでは、7 つの SCC がクラスターに追加され、クラスター管理者は CLI を使用してそれらを表示できます。
デフォルトの SCC を変更しないでください。デフォルトの SCC をカスタマイズすると、OpenShift Container Platform のアップグレード時に問題が発生する可能性があります。その代わりに、「新規 SCC を作成」します。
各 SCC の定義についても、クラスター管理者は CLI を使用して表示できます。たとえば、特権付き SCC の場合は、以下のようになります。
- 1
- Pod で要求できる要求の一覧です。特殊な記号
*は任意の機能を許可しますが、一覧が空の場合は、いずれの機能も要求できないことを意味します。 - 2
- Pod に含める追加機能の一覧です。
- 3
- セキュリティーコンテキストの許可される値を定める
FSGroupストラテジータイプです。 - 4
- この SCC へのアクセスを持つグループです。
- 5
- Pod からドロップされる機能の一覧です。
- 6
- セキュリティーコンテキストの許可される値を定める run as user ストラテジータイプです。
- 7
- セキュリティーコンテキストの許可される値を定める SELinux コンテキストストラテジータイプです。
- 8
- セキュリティーコンテキストの許可される補助グループを定める補助グループストラテジーです。
- 9
- この SCC へのアクセスを持つユーザーです。
SCC の users および groups フィールドは使用できる SCC を制御します。デフォルトで、クラスター管理者、ノードおよびビルドコントローラーには特権付き SCC へのアクセスが付与されます。認証されるすべてのユーザーには制限付き SCC へのアクセスが付与されます。
Docker には、Pod の各コンテナーについて許可されるデフォルトの機能一覧があります。コンテナーはこれらの機能をデフォルト一覧から使用しますが、Pod マニフェストの作成者は追加機能を要求したり、デフォルトから一部をドロップしてこの一覧を変更できます。allowedCapabilities、defaultAddCapabilities、および requiredDropCapabilities フィールドは Pod からのこのような要求を制御し、要求できる機能を決定し、各コンテナーに追加するものや禁止する必要のあるものを決定するために使用されます。
特権付き SCC:
- 特権付き Pod を許可します。
- ホストディレクトリーのボリュームとしてのマウントを許可します。
- Pod の任意ユーザーとしての実行を許可します。
- Pod の MCS ラベルを使った実行を許可します。
- Pod がホストの IPC namespace を使用することを許可します。
- Pod がホストの PID namespace を使用することを許可します。
- Pod が FSGroup を使用することを許可します。
- Pod が補助グループを使用することを許可します。
- Pod が seccomp プロファイルを使用することを許可します。
- Pod が任意の機能を要求することを許可します。
制限付き SCC:
- Pod が特権付きとして実行できないようにします。
- Pod がホストディレクトリーボリュームを使用できないようにします。
- Pod が事前に割り当てられた UID の範囲でユーザーとして実行されることを要求します。
- Pod が事前に割り当てられた MCS ラベルで実行されることを要求します。
- Pod が FSGroup を使用することを許可します。
- Pod が補助グループを使用することを許可します。
各 SCC の詳細は、SCC で利用可能な kubernetes.io/description アノテーションを参照してください。
SCC は Pod がアクセスできるセキュリティー機能を制限する各種の設定およびストラテジーで構成されています。これらの設定は以下のカテゴリーに分類されます。
|
ブール値による制御 |
このタイプのフィールドはデフォルトで最も制限のある値に設定されます。たとえば、 |
|
許可されるセットによる制御 |
このタイプのフィールドはセットに対してチェックされ、それらの値が許可されることを確認します。 |
|
ストラテジーによる制御 |
値を生成するストラテジーを持つ項目は以下を提供します。
|
4.2.5.1. SCC ストラテジー
4.2.5.1.1. RunAsUser
-
MustRunAs -
runAsUserが設定されることを要求します。デフォルトで設定済みのrunAsUserを使用します。設定済みのrunAsUserに対して検証します。 - MustRunAsRange - 事前に割り当てられた値を使用していない場合に、最小および最大値が定義されることを要求します。デフォルトでは最小値を使用します。許可される範囲全体に対して検証します。
-
MustRunAsNonRoot - Pod がゼロ以外の
runAsUserで送信されること、またはUSERディレクティブをイメージに定義することを要求します。デフォルトは指定されません。 -
RunAsAny - デフォルトは指定されません。
runAsUserの指定を許可します。
4.2.5.1.2. SELinuxContext
-
MustRunAs - 事前に割り当てられた値を使用していない場合に
seLinuxOptionsが設定されることを要求します。デフォルトとしてseLinuxOptionsを使用します。seLinuxOptionsに対して検証します。 -
RunAsAny - デフォルトは指定されません。
seLinuxOptionsの指定を許可します。
4.2.5.1.3. SupplementalGroups
- MustRunAs - 事前に割り当てられた値を使用していない場合に、少なくとも 1 つの範囲が指定されることを要求します。デフォルトとして最初の範囲の最小値を使用します。すべての範囲に対して検証します。
-
RunAsAny - デフォルトは指定されません。
supplementalGroupsの指定を許可します。
4.2.5.1.4. FSGroup
- MustRunAs - 事前に割り当てられた値を使用していない場合に、少なくとも 1 つの範囲が指定されることを要求します。デフォルトとして最初の範囲の最小値を使用します。最初の範囲の最初の ID に対して検証します。
-
RunAsAny - デフォルトは指定されません。
fsGroupID の指定を許可します。
4.2.5.2. ボリュームの制御
特定のボリュームタイプの使用は、SCC の volumes フィールドを設定して制御できます。このフィールドの許容値は、ボリュームの作成時に定義されるボリュームソースに対応します。
- azureFile
- azureDisk
- flocker
- flexVolume
- hostPath
- emptyDir
- gcePersistentDisk
- awsElasticBlockStore
- gitRepo
- secret
- nfs
- iscsi
- glusterfs
- persistentVolumeClaim
- rbd
- cinder
- cephFS
- downwardAPI
- fc
- configMap
- vsphereVolume
- quobyte
- photonPersistentDisk
- projected
- portworxVolume
- scaleIO
- storageos
- * (すべてのボリュームタイプの使用を許可する特殊な値)
- none (すべてのボリュームタイプの使用を無効にする特殊な値。後方互換の場合にのみ存在します)
新規 SCC の許可されるボリュームの推奨される最小セットは configMap、downwardAPI、emptyDir、persistentVolumeClaim、secret、および projected です。
許可されるボリュームタイプの一覧は、新規タイプが OpenShift Container Platform の各リリースと共に追加されるため、網羅的な一覧である必要はありません。
後方互換性のために、allowHostDirVolumePlugin の使用は volumes フィールドの設定を上書きします。たとえば、allowHostDirVolumePlugin が false に設定されるが、volumes フィールドで許可される場合、hostPath 値は volumes から削除されます。
4.2.5.3. FlexVolume へのアクセスの制限
OpenShift Container Platform は、それらのドライバーに基づいて FlexVolume の追加の制御を提供します。SCC が FlexVolume の使用を許可する場合、Pod は任意の FlexVolume を要求できます。ただし、クラスター管理者が AllowedFlexVolumes フィールドでドライバー名を指定する場合、Pod はこれらのドライバーでのみ FlexVolumes を使用する必要があります。
アクセスを 2 つの FlexVolume のみに制限する例
volumes: - flexVolume allowedFlexVolumes: - driver: example/lvm - driver: example/cifs
volumes:
- flexVolume
allowedFlexVolumes:
- driver: example/lvm
- driver: example/cifs4.2.5.4. Seccomp
SeccompProfiles は、Pod またはコンテナーの seccomp アノテーションに設定できる許可されるプロファイルを一覧表示します。未使用 (nil) または空の値は、プロファイルが Pod またはコンテナーで指定されないことを意味します。ワイルドカード * を使用してすべてのプロファイルを許可します。Pod の値を生成するために使用される場合、最初のワイルドカード以外のプロファイルがデフォルトとして使用されます。
カスタムプロファイルの設定および使用についての詳細は、「seccomp についての説明」を参照してください。
4.2.5.5. 受付
SCC が設定された 受付制御 により、ユーザーに付与された機能に基づいてリソースの作成に対する制御が可能になります。
SCC の観点では、これは受付コントローラーが、SCC の適切なセットを取得するためにコンテキストで利用可能なユーザー情報を検査できることを意味します。これにより、Pod はその運用環境についての要求を行ったり、Pod に適用する一連の制約を生成したりする権限が与えられます
受付が Pod を許可するために使用する SCC のセットはユーザーアイデンティティーおよびユーザーが属するグループによって決定されまます。さらに、Pod がサービスアカウントを指定する場合、許可される SCC のセットには、サービスアカウントでアクセスできる制約が含まれます。
受付は以下の方法を使用して、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 を失敗させる可能性があることに注意してください。
4.2.5.5.1. SCC の優先度設定
SCC には、受付コントローラーによる要求の検証を試行する際の順序に影響を与える優先度フィールドがあります。優先度の高い SCC は並び替える際にセットの先頭に移動します。利用可能な SCC の完全なセットが決定されると、それらは以下に戻づいて順序付けられます。
- 優先度が高い順。nil は優先度 0 とみなされます。
- 優先度が等しい場合、SCC は最も制限の多いものから少ないものの順に並べ替えられます。
- 優先度と制限のどちらも等しい場合、SCC は名前順に並べ替えられます。
デフォルトで、クラスター管理者に付与される anyuid SCC には SCC セットの優先度が指定されます。これにより、クラスター管理者は Pod の SecurityContext で RunAsUser を指定しなくても Pod を任意のユーザーとして実行できます。管理者は、希望する場合は依然として RunAsUser を指定できます。
4.2.5.5.2. 事前に割り当てられた値および SCC (Security Context Constraints) について
受付コントローラーは、これが namespace の事前に設定された値を検索し、Pod の処理前に SCC (Security Context Constraints) を設定するようにトリガーする 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 アノテーションは単一ブロックのみを受け入れます。
4.2.6. 認証済みのユーザーとして何が実行できるのかを判断する方法
OpenShift Container Platform プロジェクト内で、namespace でスコープ設定されたすべてのリソース (サードパーティーのリソースを含む) に対して実行できる動詞を判別します。以下を実行します。
oc policy can-i --list --loglevel=8
$ oc policy can-i --list --loglevel=8この出力で、情報収集のために実行する必要のある API 要求を判断しやすくなります。
ユーザーが判読可能な形式で情報を取得し直すには、以下を実行します。
oc policy can-i --list
$ oc policy can-i --listこの出力により、詳細な一覧が表示されます。
特定の動詞が実行可能かどうかを判断するには、以下を実行します。
oc policy can-i <verb> <resource>
$ oc policy can-i <verb> <resource>「ユーザースコープ」では、指定のスコープについて詳しく説明しています。以下に例を示します。
oc policy can-i <verb> <resource> --scopes=user:info
$ oc policy can-i <verb> <resource> --scopes=user:info4.3. 永続ストレージ
4.3.1. 概要
ストレージの管理は、コンピュートリソースの管理とは異なります。OpenShift Container Platform は Kubernetes 永続ボリューム (PV) フレームワークを使用してクラスター管理者がクラスターの永続ストレージのプロビジョニングを実行できるようにします。開発者は、Persistent Volume Claims (PVC、永続ボリューム要求) を使用して、基礎となるストレージインフラストラクチャーについての特定の知識なしに PV リソースを要求できます。
PVC はプロジェクト固有のもので、開発者が PV を使用する手段として作成し、使用します。PV リソース自体はいずれの単一プロジェクトにもスコープ設定されず、それらは OpenShift Container Platform クラスターで共有でき、任意のプロジェクトから要求できますが、PV が PVC に バインド された後は、その PV は追加の PVC にバインドできなくなります。これにはバインドされた PV を単一の namespace (バインディングプロジェクトの namespace) にスコープ設定する作用があります。
PV は、クラスター管理者によってプロビジョニングされるクラスターの既存のネットワーク設定されたストレージの一部を表す PersistentVolume API オブジェクトで定義されます。これは、ノードがクラスターリソースであるのと同様にクラスター内のリソースです。PV は Volumes のようなボリュームプラグインですが、PV を使用する個々の Pod から独立したライフサイクルを持ちます。PV オブジェクトは、NFS、iSCSI、またはクラウドプロバイダー固有のストレージシステムのいずれの場合でも、ストレージの実装の詳細をキャプチャーします。
インフラストラクチャーにおけるストレージの高可用性は、基礎となるストレージのプロバイダーに委ねられています。
PVC は、開発者によるストレージの要求を表す PersistentVolumeClaim API オブジェクトによって定義されます。これは Pod がノードリソースを消費する点で Pod に似ており、PVC は PV リソースを消費します。たとえば、Pod は特定のレベルのリソース (CPU およびメモリーなど) を要求し、PVC は特定のストレージ容量およびアクセスモードを要求できます (たとえば、それらは読み取り/書き込みで 1 回、読み取り専用で複数回マウントできます)。
4.3.2. ボリュームおよび要求のライフサイクル
PV はクラスターのリソースです。PVC はそれらのリソースの要求であり、リソースに対する要求チェックとして機能します。PV と PVC 間の相互作用には以下のライフサイクルが設定されます。
4.3.2.1. ストレージのプロビジョニング
PVC で定義される開発者からの要求に対応し、クラスター管理者はストレージおよび一致する PV をプロビジョニングする 1 つ以上の動的プロビジョナーを設定します。
または、クラスター管理者は、使用可能な実際のストレージの詳細を保持する多数の PV を前もって作成できます。PV は API に存在し、利用可能な状態になります。
4.3.2.2. 要求のバインド
PVC の作成時に、ストレージの特定容量の要求、必要なアクセスモードの指定のほか、ストレージクラスを作成してストレージの記述や分類を行います。マスターのコントロールループは新規 PVC の有無を監視し、新規 PVC を適切な PV にバインドします。適切な PV がない場合には、ストレージクラスのプロビジョナーが PV を作成します。
PV ボリュームは、要求したボリュームを上回る可能性がありますが、これは、手動でプロビジョニングされた PV の場合に特にそう言えます。超過を最小限にするために、OpenShift Container Platform は他のすべての条件に一致する最小の PV にバインドします。
要求は、一致するボリュームが存在しないか、ストレージクラスを提供するいずれの利用可能なプロビジョナーで作成されない場合には無期限にバインドされないままになります。要求は、一致するボリュームが利用可能になるとバインドされます。たとえば、多数の手動でプロビジョニングされた 50Gi ボリュームを持つクラスターは 100Gi を要求する PVC に一致しません。PVC は 100Gi PV がクラスターに追加されるとバインドされます。
4.3.2.3. Pod および要求した PV の使用
Pod は要求をボリュームとして使用します。クラスターは要求を検査して、バインドされたボリュームを検索し、Pod にそのボリュームをマウントします。複数のアクセスモードをサポートするボリュームの場合、要求を Pod のボリュームとして使用する際に適用するモードを指定する必要があります。
要求が存在し、その要求がバインドされている場合、バインドされた PV は必要な限り所属させることができます。Pod のスケジュールおよび要求された PV のアクセスは、persistentVolumeClaim を Pod のボリュームブロックに組み込んで実行できます。構文の詳細については、以下を参照してください。
4.3.2.4. PVC 保護
デフォルトでは、PVC 保護は有効になっています。
4.3.2.5. ボリュームの開放
ボリュームの処理が終了したら、API から PVC オブジェクトを削除できます。これにより、リソースをまた要求できるようになります。ボリュームは要求の削除時に「開放 (リリース)」されたものとみなされますが、別の要求で利用できる状態にはありません。以前の要求者のデータはボリューム上に残るので、ポリシーに基づいて処理される必要があります。
4.3.2.6. ボリュームの回収
PersistentVolume の回収ポリシーは、クラスターに対してリリース後のボリュームの処理方法について指示します。ボリュームの回収ポリシーは、Retained、Recycled、または Deleted のいずれかにすることができます。
Retained 回収ポリシーにより、これをサポートするボリュームプラグインについてのリソースの手動による回収を可能にします。Deleted 回収ポリシーは、OpenShift Container Platform の PersistentVolume オブジェクトと、および AWS EBS、GCE PD、または Cinder ボリュームなどの外部インフラストラクチャーの関連ストレージアセットの両方を削除します。
動的にプロビジョニングされたボリュームは常に削除されます。
4.3.2.6.1. ボリュームのリサイクル
適切なボリュームプラグインでサポートされる場合、リサイクルはボリュームの基本的なスクラブを実行 (rm -rf /thevolume/*) し、これを新規の要求で再び利用できるようにします。
OpenShift Container Platform 3.6 で導入された動的プロビジョニングが優先的に使用されるようになったため、recycle の回収ポリシーは非推奨になり、削除されました。
「ControllerArguments」のセクションで説明されているように、コントローラーマネージャーのコマンドライン引数を使用してカスタムのリサイクラー Pod テンプレートを設定できます。カスタムのリサイクラー Pod テンプレートには、以下の例のような volumes 仕様が含まれます。
カスタムのリサイクラー Pod テンプレート例
- 1
- リサイクラー Pod が実行される namespace です。
openshift-infraには、ボリュームをリサイクルできるpv-recycler-controllerサービスアカウントがすでに含まれているため、これは推奨される namespace になります。 - 2
- NFS ボリュームのマウントが許可されるサービスアカウントの名前です。これは指定された namespace に存在している必要があります。
pv-recycler-controllerアカウントは、openshift-infranamespace に自動作成され、必要なすべてのパーミッションを含むため、推奨されるアカウントになります。 - 3 4
- カスタムリサイクラー Pod テンプレートの
volumes部分に指定される特定のserverおよびpath値は、リサイクルされる PV の特定の対応する値に置き換えられます。
4.3.3. 永続ボリューム
各 PV には、以下の例のように、ボリュームの仕様およびステータスである spec および status が含まれます。
PV オブジェクト定義例
4.3.3.1. PV の種類
OpenShift Container Platform は以下の PersistentVolume プラグインをサポートします。
4.3.3.2. 容量
通常、PV には特定のストレージ容量があります。これは PV の capacity 属性を使用して設定されます。
現時点で、ストレージ容量は、設定または要求できる唯一のリソースです。今後の属性には IOPS、スループットなどが含まれる可能性があります。
4.3.3.3. アクセスモード
PersistentVolume はリソースプロバイダーでサポートされるすべての方法でホストにマウントできます。プロバイダーには各種の機能があり、それぞれの PV のアクセスモードは特定のボリュームでサポートされる特定のモードに設定されます。たとえば、NFS は複数の読み取り/書き込みクライアントをサポートしますが、特定の NFS PV は読み取り専用としてサーバー上でエクスポートされる可能性があります。それぞれの PV は、その特定の PV の機能について記述するアクセスモードの独自のセットを取得します。
要求は、同様のアクセスモードのボリュームに一致します。一致する条件はアクセスモードとサイズの 2 つの条件のみです。要求のアクセスモードは要求 (request) を表します。そのため、より多くのアクセスを付与することはできますが、アクセスを少なくすることはできません。たとえば、要求により RWO が要求されるものの、利用できる唯一のボリュームが NFS PV (RWO+ROX+RWX) の場合に、要求は RWO をサポートする NFS に一致します。
常に直接一致が最初に試行されます。ボリュームのモードは、要求モードと一致するか、要求した内容以上のものを含む必要があります。また、サイズは期待値以上である必要があります。2 つのタイプのボリューム (NFS および iSCSI など) に同じアクセスモードセットがある場合には、いずれかをこれらのモードを含む要求と一致させることができます。ボリュームのタイプの中で順番はなく、どちらかを優先して選択する手段はありません。
同じモードが含まれるボリュームはすべて分類され、サイズ別 (一番小さいものから一番大きいもの順) に分類されます。バインダーは一致するモードのグループを取得し、1 つのサイズが一致するまでそれぞれを (サイズの順序で) 繰り返し処理します。
以下の表では、アクセスモードをまとめています。
| アクセスモード | CLI の省略形 | 説明 |
|---|---|---|
|
ReadWriteOnce |
|
ボリュームは単一ノードで読み取り/書き込みとしてマウントできます。 |
|
ReadOnlyMany |
|
ボリュームは数多くのノードで読み取り専用としてマウントできます。 |
|
ReadWriteMany |
|
ボリュームは数多くのノードで読み取り/書き込みとしてマウントできます。 |
ボリュームの AccessModes は、ボリュームの機能の記述子です。それらは施行されている制約ではありません。ストレージプロバイダーはリソースの無効な使用から生じるランタイムエラーに対応します。
たとえば、Ceph は ReadWriteOnce アクセスモードを提供します。ボリュームの ROX 機能を使用する必要がある場合は、要求に read-only のマークを付ける必要があります。プロバイダーのエラーは、マウントエラーとしてランタイム時に表示されます。
iSCSI およびファイバーチャネルボリュームには現在、フェンシングメカニズムがありません。ボリュームが一度に 1 つのノードでのみ使用されるようにする必要があります。ノードのドレイン (解放) などの特定の状況では、ボリュームは 2 つのノードで同時に使用できます。ノードをドレイン (解放) する前に、まずこれらのボリュームを使用する Pod が削除されていることを確認してください。
以下の表では、異なる PV でサポートされるアクセスモードが表示されています。
| ボリュームプラグイン | ReadWriteOnce | ReadOnlyMany | ReadWriteMany |
|---|---|---|---|
|
AWS EBS |
✅ |
- |
- |
|
Azure File |
✅ |
✅ |
✅ |
|
Azure Disk |
✅ |
- |
- |
|
Ceph RBD |
✅ |
✅ |
- |
|
ファイバーチャネル |
✅ |
✅ |
- |
|
GCE Persistent Disk |
✅ |
- |
- |
|
GlusterFS |
✅ |
✅ |
✅ |
|
HostPath |
✅ |
- |
- |
|
iSCSI |
✅ |
✅ |
- |
|
NFS |
✅ |
✅ |
✅ |
|
Openstack Cinder |
✅ |
- |
- |
|
VMWare vSphere |
✅ |
- |
- |
|
ローカル |
✅ |
- |
- |
AWS EBS、GCE 永続ディスクまたは OpenStack Cinder PV に依存する Pod には、「再作成デプロイメントストラテジー」を使用します。
4.3.3.4. 回収ポリシー
以下の表には、現在の回収ポリシーをまとめています。
| 回収ポリシー | 説明 |
|---|---|
|
Retain (保持) |
手動による回収 |
|
Recycle (リサイクル) |
基本的なスクラブ (例: |
現時点では、NFS および HostPath のみが「リサイクル」回収ポリシーをサポートしています。
OpenShift Container Platform 3.6 で導入された動的プロビジョニングが優先的に使用されるようになったため、recycle の回収ポリシーは非推奨になり、削除されました。
4.3.3.5. フェーズ
ボリュームは以下のフェーズのいずれかにあります。
| フェーズ | 説明 |
|---|---|
|
Available |
まだ要求にバインドされていない空きリソースです。 |
|
Bound |
ボリュームが要求にバインドされています。 |
|
Released |
要求が検出されていますが、リソースがまだクラスターにより回収されていません。 |
|
Failed |
ボリュームが自動回収に失敗しています。 |
CLI には PV にバインドされている PVC の名前が表示されます。
4.3.3.6. マウントオプション
アノテーション volume.beta.kubernetes.io/mount-options を使用して永続ボリュームのマウント中にマウントオプションを指定できます。
以下に例を示します。
マウントオプションの例
- 1
- 指定のマウントオプションは、PV がディスクにマウントされている時に使用されます。
以下の永続ボリュームタイプがマウントオプションをサポートします。
- NFS
- GlusterFS
- Ceph RBD
- OpenStack Cinder
- AWS Elastic Block Store (EBS)
- GCE Persistent Disk
- iSCSI
- Azure Disk
- Azure File
- VMWare vSphere
ファイバーチャネルおよび HostPath 永続ボリュームはマウントオプションをサポートしません。
4.3.4. Persistent Volume Claim (永続ボリューム要求、PVC)
各 PVC には、要求の仕様およびステータスである spec および status が含まれます。以下に例を示します。
PVC オブジェクト定義例
4.3.4.1. ストレージクラス
要求は、ストレージクラスの名前を storageClassName 属性に指定して特定のストレージクラスをオプションでリクエストできます。リクエストされたクラスの PV、つまり PVC と同じ storageClassName を持つ PV のみが PVC にバインドされます。クラスター管理者は 1 つ以上のストレージクラスを提供するように動的プロビジョナーを設定できます。クラスター管理者は、PVC の仕様に一致する PV をオンデマンドで作成できます。
クラスター管理者は、すべての PVC にデフォルトストレージクラスを設定することもできます。デフォルトのストレージクラスが設定されると、PVC は StorageClass または storageClassName アノテーションが "" に設定され、ストレージクラスなしで PV にバインドされるように明示的に要求する必要があります。
4.3.4.2. アクセスモード
要求は、特定のアクセスモードのストレージを要求する際にボリュームと同じ規則を使用します。
4.3.4.3. リソース
要求は、Pod の場合のようにリソースの特定の数量を要求できます。今回の例では、ストレージに対する要求です。同じリソースモデルがボリュームと要求の両方に適用されます。
4.3.4.4. ボリュームとしての要求
Pod は要求をボリュームとして使用することでストレージにアクセスします。この要求を使用して、Pod と同じ namespace 内に、要求を共存させる必要があります。クラスターは Pod の namespace で要求を見つけ、これを使用して要求をサポートする PersistentVolume を取得します。以下のように、ボリュームはホストにマウントされ、Pod に組み込まれます。
ホストおよび Pod のサンプルへのボリュームのマウント
4.3.5. ブロックボリュームのサポート
ブロックボリュームサポートは、テクノロジープレビュー機能で、手動でプロビジョニングされた PV でのみ利用できます。
テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
Red Hat のテクノロジープレビュー機能のサポートについての詳細は、https://access.redhat.com/ja/support/offerings/techpreview を参照してください。
PV および PVC 仕様に API フィールドを組み込み、raw ブロックボリュームを静的にプロビジョニングできます。
ブロックボリュームを使用するには、まず BlockVolume 機能ゲートを有効にする必要があります。マスターの機能ゲートを有効にするには、feature-gates を apiServerArguments および controllerArguments に追加します。ノードの機能ゲートを有効にするには、feature-gates を kubeletArguments に追加します。以下は例になります。
kubeletArguments:
feature-gates:
- BlockVolume=true
kubeletArguments:
feature-gates:
- BlockVolume=truePV の例
- 1
volumeModeフィールドは、この PV が raw ブロックボリュームであることを示します。
PVC の例
- 1
volumeModeフィールドは、raw ブロック永続ボリュームが要求されていることを示します。
Pod の仕様例
| 値 | デフォルト |
|---|---|
|
Filesystem |
Yes |
|
Block |
No |
| PV VolumeMode | PVC VolumeMode | バインディングの結果 |
|---|---|---|
|
Filesystem |
Filesystem |
バインド |
|
Unspecified |
Unspecified |
バインド |
|
Filesystem |
Unspecified |
バインド |
|
Unspecified |
Filesystem |
バインド |
|
Block |
Block |
バインド |
|
Unspecified |
Block |
バインドなし |
|
Block |
Unspecified |
バインドなし |
|
Filesystem |
Block |
バインドなし |
|
Block |
Filesystem |
バインドなし |
値を指定しないと、Filesystem のデフォルト値が指定されます。
4.4. 一時ローカルストレージ
4.4.1. 概要
このトピックは、一時ストレージのテクノロジープレビューを OpenShift Container Platform 3.10 で有効化した場合にのみ該当します。この機能は、デフォルトでは無効になっています。有効にすると、OpenShift Container Platform クラスターは一時ストレージを使用して、クラスターが破棄された後に、永続する必要のない情報が保存されます。この機能を有効にする方法は、『一時ストレージの設定』を参照してください。
永続ストレージに加え、Pod とコンテナーは、操作に一時または短期的なローカルストレージを必要とする場合があります。この一時ストレージは、個別の Pod の寿命より長くなることはなく、一時ストレージは Pod 間で共有することはできません。
OpenShift Container Platform 3.10 以前は、一時ローカルストレージは、コンテナーの書き込み可能な階層、logs ディレクトリー、EmptyDir ボリュームを使用して Pod に公開されていました。Pod は、スクラッチスペース、キャッシュ、ログに一時ローカルストレージを使用します。ローカルストレージのアカウントや分離がないことに関連する問題には、以下が含まれます。
- Pod では、利用可能なローカルストレージの数が分からない。
- Pod がローカルストレージを要求しても確実に割り当てられない可能性がある。
- ローカルストレージはベストエフォートのリソースである。
- Pod は、他の Pod でローカルストレージがいっぱいになるとエビクトされる可能性があり、十分なストレージが回収されるまで、新しい Pod は入れない。
一時ストレージは、永続ボリュームとは異なり、体系化されておらず、システム、コンテナーランタイム、Openshift Container Platform での他の用途に加え、ノードで実行中のすべての Pod 間で実際のデータではなく領域を共有します。一時ストレージのフレームワークは、Pod が一時的なストレージのニーズを指定するだけでなく、随時 OpenShift Container Platform が Pod をスケジューリングし、ローカルストレージが過剰に使用されないように保護します。
一時ストレージフレームワークでは、管理者および開発者がこのローカルストレージの管理を改善できますが、I/O スループットやレイテンシーに関する確約はありません。
4.4.2. 一時ストレージのタイプ
一時ローカルストレージは常に、プライマリーパーティションで利用できるようになっています。プライマリーパーティション、Root、ランタイムを作成する基本的な方法には 2 種類あります。
4.4.2.1. Root
このパーティションでは、デフォルトで kubelet の root ディレクトリー /var/lib/origin/ と /var/log/ ディレクトリーを保持します。このパーティションは、ユーザーの Pod、OS、Kubernetes システムのデーモン間で共有できます。Pod は、EmptyDir ボリューム、コンテナーログ、イメージ階層、コンテナーの書き込み可能な階層を使用して、このパーティションを使用できます。Kubelet はこのパーティションの共有アクセスおよび分離を管理します。このパーティションは一時的なもので、アプリケーションは、このパーティションから、ディスク IOPS などのパフォーマンス SLA は期待できません。
4.4.2.2. ランタイム
これは、ランタイムがオーバーレイファイルシステムに使用可能なオプションのパーティションです。OpenShift Container Platform は、このパーティションの分離および共有アクセスを特定して提供します。このパーティションには、イメージ階層と書き込み可能な階層が含まれます。ランタイムパーティションが存在する場合は、root パーティションにはイメージ階層もその他の書き込み可能階層も含まれません。
DeviceMapper を使用してランタイムストレージを提供する場合には、一時ストレージ管理には、コンテナーの Copy-on-Write 階層は含まれません。オーバーレイストレージを使用してこの一時ストレージを監視してください。
4.5. ソースコントロール管理
OpenShift Container Platform は、内部 (インハウス Git サーバーなど) または外部 (GitHub、Bitbucket など) でホストされている既存のソースコントロール管理 (SCM) システムを利用します。現時点で、OpenShift Container Platform は Git ソリューションのみをサポートします。
SCM 統合はビルドに密接に関連し、以下の 2 つの点を実行します。
4.6. 受付コントローラー
4.6.1. 概要
受付制御プラグインはリソースの永続化の前にマスター API への要求をインターセプトしますが、要求の認証および承認後にこれを実行します。
クラスターに要求が受け入れられる前に、受付制御プラグインがそれぞれ、順番に実行されます。この順番に実行されているプラグインのいずれかが要求を拒否すると、要求全体がただちに拒否され、エンドユーザーにエラーが返されます。
受付制御プラグインは、システムで設定されたデフォルトを適用するために受信オブジェクトを変更する場合があります。さらに、受付制御プラグインはクォータ使用の増分などを実行する要求処理の一環として関連するリソースを変更する場合もあります。
OpenShift Container Platform マスターには、それぞれのタイプのリソース (Kubernetes および OpenShift Container Platform) についてデフォルトで有効にされているプラグインのデフォルトの一覧が含まれます。それらはマスターが適切に機能するために必要です。これらの一覧を変更することは、実際の変更内容を把握している場合でない限りは推奨されません。本製品の今後のバージョンでは異なるセットのプラグインを使用し、それらの順序を変更する可能性があります。マスター設定ファイルでプラグインのデフォルトの一覧を上書きする場合、新規バージョンの OpenShift Container Platform マスターの要件を反映できるように一覧を更新する必要があります。
4.6.2. 一般的な受付ルール
3.3 以降で、OpenShift Container Platform は Kubernetes および OpenShift Container Platform リソースの単一の受付チェーンを使用します。これは、別個の受付チェーンが使用されていた 3.2 以前とは異なります。これは、トップレベルの admissionConfig.pluginConfig 要素に kubernetesMasterConfig.admissionConfig.pluginConfig に含まれていた受付プラグイン設定が含まれることを意味しています。
kubernetesMasterConfig.admissionConfig.pluginConfig は admissionConfig.pluginConfig に移動し、マージされる必要があります。
また 3.3 より、サポートされるすべての受付プラグインは単一チェーン内で順序付けられます。admissionConfig.pluginOrderOverride または kubernetesMasterConfig.admissionConfig.pluginOrderOverride を設定する必要はなくなります。代わりに、プラグイン固有の設定を追加するか、または以下のような DefaultAdmissionConfig スタンザを追加してデフォルトでオフになっているプラグインを有効にする必要があります。
disable を true にすると、on にデフォルト設定される受付プラグインが無効になります。
受付プラグインは、API サーバーのセキュリティーを実施するために一般的に使用されています。これらを無効にする場合には注意して行ってください。
単一の受付チェーンに安全に組み込むことのできない admissionConfig 要素を使用していた場合は、API サーバーログで警告を受信し、API サーバーはレガシーの互換性のために 2 つの異なる受付チェーンで開始されることになります。警告を解決するには、admissionConfig を更新します。
4.6.3. カスタマイズ可能な受付プラグイン
クラスター管理者は、一部の受付コントロールプラグインを、以下のような特定の動作を制御するように設定できます。
4.6.4. コンテナーを使用した受付コントローラー
コンテナーを使用する受付コントローラーも init コンテナーをサポートします。
4.7. カスタム受付コントローラー
4.7.1. 概要
デフォルトの受付コントローラーのほかにも、受付 Webhook を受付チェーンの一部として使用できます。
受付 Webhook は Webhook サーバーを呼び出して、ラベルの挿入など、作成時に Pod を変更するか、または受付プロセス時に Pod 設定の特定の部分を検証します。
受付 Webhook はリソースの永続化の前にマスター API への要求をインターセプトしますが、要求の認証および承認後にこれを実行します。
4.7.2. 受付 Webhook
OpenShift Container Platform では、API 受付チェーンで Webhook サーバーを呼び出す受付 Webhook オブジェクトを使用できます。
設定可能な 2 種類の受付 Webhook オブジェクトがあります。
- 変更用の受付 Webhookは、変更用の Webhook を使用した、永続化する前のリソースコンテンツの変更を可能にします。
- 検証用の受付 Webhook は、検証用の Webhook を使用したカスタム受付ポリシーの実施を可能にします。
Webhook および外部 Webhook サーバーの設定については本書では扱いません。ただし、Webhook サーバーは、OpenShift Contaniner Platform で適切に機能するために、インターフェースに準拠する必要があります。
受付 Webhook はテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
Red Hat のテクノロジープレビュー機能のサポートについての詳細は、https://access.redhat.com/support/offerings/techpreview/ を参照してください。
オブジェクトがインスタンス化されると、OpenShift Container Platform は API 呼び出しを実行してオブジェクトを許可します。受付プロセスでは、変更用の受付コントローラー は Webhook を呼び出して、アフィニティーラベルの挿入などのタスクを実行します。受付プロセスの終了時に、検証用の受付コントローラー は Webhook を呼び出し、アフィニティーラベルの検証などにより、オブジェクトが適切に設定されていることを確認します。検証にパスすると、OpenShift Container Platform はオブジェクトを設定済みとしてスケジュールします。
API 要求が送信されると、変更用または検証用の受付コントローラーは設定内の外部 Webhook の一覧を使用し、それらを並行して呼び出します。
- Webhook の すべて が要求を承認する場合、受付チェーンは継続します。
Webhook の いずれか が要求を拒否する場合、受付要求は拒否され、これは、初回の webhook の拒否理由に基づいて実行されます。
複数の Webhook が受付要求を拒否する場合、最初のものだけがユーザーに返されます。
- Webhook の呼び出し時にエラーが生じる場合、その要求は無視され、受付要求を承認/拒否するために使用されます。
受付コントローラーと Webhook サーバー間の通信のセキュリティーは TLS を使用して保護する必要があります。CA 証明書を生成し、その証明書を使用して Webhook サーバーで使用されるサーバー証明書に署名します。PEM 形式の CA 証明書は、「サービス提供証明書のシークレット」などのメカニズムを使用して受付コントローラーに提供されます。
以下の図は、複数の Webhook を呼び出す 2 つの受付 Webhook を含むプロセスを示しています。
受付 Webhook の単純な使用事例として、リソースの構文検証が挙げられます。たとえば、すべての Pod に共通のラベルセットを指定する必要のあるインフラストラクチャーがあり、そのラベルが指定されていない Pod は永続化させないようにする場合に、Webhook を作成してこれらのラベルを挿入したり、別の Webhook でラベルの有無を検証したりすることができます。その後 OpenShift Container Platform は、ラベルがあり、検証をパスした Pod をスケジュールし、ラベルがないためにパスしない Pod を拒否します。
共通のユースケースには以下が含まれます。
- サイドカーコンテナーを Pod に挿入するためのリソースの変更
- 一部のリソースをプロジェクトからブロックするためのプロジェクトの制限
- 依存するフィールドで複雑な検証を実行するためのカスタムリソース検証
4.7.2.1. 受付 Webhook のタイプ
クラスター管理者は、API サーバーの受付チェーンに 変更用の受付 Webhook または 検証用の受付 Webhook を含めることができます。
変更用の受付 Webhook は、受付プロセスの変更フェーズで呼び出されるので、リソースコンテンツが永続化される前にリソースを変更できます。受付 Webhook の一例として、「Pod ノードセレクター」機能があります。この機能は namespace でアノテーションを使用してラベルセレクターを検索し、これを Pod 仕様に追加します。
受付 Webhook 設定の変更例:
- 1
- 変更用の受付 Webhook 設定を指定します。
- 2
- 受付 Webhook オブジェクトの名前です。
- 3
- 呼び出す Webhook の名前です。
- 4
- Webhook サーバーに接続し、これを信頼し、データをこれに送信する方法についての情報です。
- 5
- フロントエンドサービスが作成されるプロジェクトです。
- 6
- フロントエンドサービスの名前です。
- 7
- 受付要求に使用される Webhook URL です。
- 8
- Webhook サーバーで使用されるサーバー証明書に署名する PEM でエンコーディングされた CA 証明書です。
- 9
- API サーバーがこのコントローラーを使用するタイミングを定義するルールです。
- 10
- このコントローラーを呼び出すために API サーバーをトリガーする操作です。
- create
- update
- delete
- connect
- 11
- Webhook 受付サーバーが利用できない場合にポリシーを実行する方法を指定します。
Ignore(allow/fail open) またはFail(block/fail closed) になります。
検証用の受付 Webhook は受付プロセスの検証フェーズで起動します。このフェーズでは、特定 API リソースの変更がない項目の実施を可能にし、リソースが再び変更されないようにすることができます。Pod ノードセレクターも、すべての nodeSelector フィールドがプロジェクトのノードセレクターの制限で制約されていることを確認する、検証用の受付の例となります。
検証用の受付 Webhook 設定の例:
- 1
- 検証用の受付 Webhook 設定を指定します。
- 2
- Webhook 受付オブジェクトの名前です。
- 3
- 呼び出す Webhook の名前です。
- 4
- Webhook サーバーに接続し、これを信頼し、データをこれに送信する方法についての情報です。
- 5
- フロントエンドサービスが作成されるプロジェクトです。
- 6
- フロントエンドサービスの名前です。
- 7
- 受付要求に使用される Webhook URL です。
- 8
- Webhook サーバーで使用されるサーバー証明書に署名する PEM でエンコーディングされた CA 証明書です。
- 9
- API サーバーがこのコントローラーを使用するタイミングを定義するルールです。
- 10
- このコントローラーを呼び出すために API サーバーをトリガーする操作です。
- create
- update
- delete
- connect
- 11
- Webhook 受付サーバーが利用できない場合にポリシーを実行する方法を指定します。
Ignore(allow/fail open) またはFail(block/fail closed) になります。
Fail open の場合に、すべてのクライアントの予測できない動作が生じる可能性があります。
4.7.2.2. 受付 Webhook を作成します。
最初に外部 Webhook サーバーをデプロイし、これが適切に機能することを確認します。これを実行しない場合、Webhook が fail open または fail closed として設定されているかに応じて、操作は無条件に許可または拒否されます。
- YAML ファイルを使用して変更用、または検証用受付 Webhook オブジェクトを設定します。
以下のコマンドを実行してオブジェクトを作成します。
oc create -f <file-name>.yaml
oc create -f <file-name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 受付 Webhook オブジェクトの作成後、OpenShift Container Platform が新規設定を反映するまでに数秒の時間がかかります。
受付 Webhook のフロントエンドサービスを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行してオブジェクトを作成します。
oc create -f <file-name>.yaml
oc create -f <file-name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Webhook で制御する必要のある Pod に受付 Webhook 名を追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Webhook をトリガーするためのラベルです。
独自のセキュアでポータブルな Webhook 受付サーバーをビルドする方法についてのエンドツーエンドの例については、kubernetes-namespace-reservation プロジェクトを参照し、ライブラリーについては generic-admission-apiserver を参照してください。
4.7.2.3. 受付 Webhook オブジェクトのサンプル
以下は、namespace が予約される場合に namespace の作成 を許可しない受付 Webhook のサンプルです。
以下は、webhook という名前の受付 Webhook によって評価される Pod のサンプルです。
以下は Webhook のフロントエンドサービスです。
4.8. 他の API オブジェクト
4.8.1. LimitRange
制限範囲は、Kubernetes namespace のリソースに設定される最小/最大の制限を実施するメカニズムを提供します。
制限範囲を namespace に追加することで、個別の Pod またはコンテナーによる CPU およびメモリーの最小および最大使用量を適用できます。
4.8.2. ResourceQuota
Kubernetes は、namespace で作成されるオブジェクト数と、namespace 内のオブジェクト間で要求されるリソース合計量の両方を制限できます。これにより、namespace 内の複数のチームで単一の Kubernetes クラスターを共有でき、あるチームによって別のチームがクラスターリソース不足になることを防ぐことができます。
ResourceQuota についての詳細は、『クラスター管理』を参照してください。
4.8.3. リソース
Kubernetes の Resource は、Pod またはコンテナーによって要求され、割り当てられ、消費されるものです。例として、メモリー (RAM)、CPU、ディスク時間、およびネットワーク帯域幅があります。
詳細は、『開発者ガイド』を参照してください。
4.8.4. Secret
「シークレット」は、キー、パスワード、および証明書などの機密情報のストレージです。これらは所定の Pod でアクセスできますが、定義とは別に保持されます。
4.8.5. PersistentVolume
「永続ボリューム」は、クラスター管理者によってプロビジョニングされるインフラストラクチャーのオブジェクト (PersistentVolume) です。永続ボリュームは、ステートフルなアプリケーションに対して、耐久性のあるストレージを提供します。
4.8.6. PersistentVolumeClaim
PersistentVolumeClaim オブジェクトは、「Pod 作成者によるストレージの要求」です。Kubernetes は、要求を利用可能なボリュームのプールと照合し、それらをバインドします。この要求は、Pod によりボリュームとして使用されます。Kubernetes は、ボリュームを要求する Pod と同じノードで、そのボリュームが利用可能であることを確認します。
4.8.6.1. カスタムリソース
カスタムリソース は、API を拡張するか、独自の API をプロジェクトまたはクラスターに導入できるようにする Kubernetes API の拡張です。
リンク 「カスタムリソースによる Kubernetes API の拡張」を参照してください。
リンク 「カスタムリソースによる Kubernetes API の拡張」を参照してください。4.8.7. OAuth オブジェクト
4.8.7.1. OAuthClient
OAuthClient は、RFC 6749, section 2 に説明されているように OAuth クライアントを表します。
以下の OAuthClient オブジェクトは自動的に作成されます。
|
|
Web コンソールのトークンを要求するために使用されるクライアント |
|
|
対話式ログインを処理できるユーザーエージェントで /oauth/token/request でトークンを要求するために使用されるクライアント |
|
|
WWW-Authenticate チャレンジを処理できるユーザーエージェントでトークンを要求するために使用されるクライアント |
OAuthClient オブジェクト定義
- 1
- アクセストークンの有効期間 (秒単位)(以下の説明を参照してください)。
- 2
nameは OAuth 要求のclient_idパラメーターとして使用されます。- 3
respondWithChallengesがtrueに設定される場合、/oauth/authorizeへの認証されていない要求は、設定される認証方法でサポートされている場合にはWWW-Authenticateチャレンジを生じさせます。- 4
secretパラメーターの値は、承認コードフローのclient_secretパラメーターとして使用されます。- 5
- 絶対 URI は、
redirectURIsセクションに 1 つ以上配置できます。承認要求と共に送信されるredirect_uriパラメーターには、指定のredirectURIsのいずれかをプレフィックスとして付加する必要があります。
accessTokenMaxAgeSeconds 値は、個別の OAuth クライアントのマスター設定に指定されている accessTokenMaxAgeSeconds 値を上書きします。この値をクライアントに設定すると、他のクライアントの有効期間に影響を与えることなく、クライアントのアクセストークンの有効期間を長く設定できます。
-
nullの場合、マスター設定ファイルのデフォルト値が使用されます。 -
0に設定される場合、トークンは有効期限切れになりません。 -
0よりも大きな値に設定される場合、クライアント用に発行されるトークンには指定された有効期限が設定されます。たとえば、accessTokenMaxAgeSeconds: 172800により、トークンは発行後 48 時間後に有効期限切れになります。
4.8.7.2. OAuthClientAuthorization
OAuthClientAuthorization は、特定の OAuthClient に特定のスコープが設定された OAuthAccessToken が付与されることについての User による承認を表します。
OAuthClientAuthorization オブジェクトの作成は、OAuth サーバーへの承認要求時に実行されます。
OAuthClientAuthorization オブジェクト定義
4.8.7.3. OAuthAuthorizeToken
OAuthAuthorizeToken は、RFC 6749, section 1.3.1 に説明されているように OAuth 承認コードを表します。
OAuthAuthorizeToken は、RFC 6749, section 4.1.1 で説明されているように /oauth/authorize エンドポイントへの要求によって作成されます。
OAuthAuthorizeToken は次に、RFC 6749, section 4.1.3 に説明されているように、/oauth/token エンドポイントへの要求で OAuthAccessToken を取得するために使用できます。
OAuthAuthorizeToken オブジェクト定義
- 1
nameは、OAuthAccessToken を交換するために承認コードとして使用されるトークン名を表します。- 2
clientName値は、このトークンを要求した OAuthClient です。- 3
expiresIn値は creationTimestamp の有効期限 (秒単位) です。- 4
redirectURI値は、このトークンが作成された承認フローでユーザーがリダイレクトされた場所です。- 5
userNameは、このトークンが OAuthAccessToken の取得を許可するユーザーの名前を表します。- 6
userUIDは、このトークンが OAuthAccessToken の取得を許可するユーザーの UID を表します。
4.8.7.4. OAuthAccessToken
OAuthAccessToken は、RFC 6749, section 1.4 に説明されているように、OAuth アクセストークンを表します。
OAuthAccessToken は、RFC 6749, section 4.1.3 に説明されているように、/oauth/token エンドポイントへの要求によって作成されます。
アクセストークンは、API に対して認証を行うためにベアラートークンとして使用されます。
OAuthAccessToken オブジェクト定義
- 1
nameは、API に対して認証を行うためにベアラートークンとして使用されるトークン名です。- 2
clientName値は、このトークンを要求した OAuthClient です。- 3
expiresIn値は creationTimestamp の有効期限 (秒単位) です。- 4
redirectURIは、このトークンが作成された承認フローでユーザーがリダイレクトされた場所です。- 5
userNameは、このトークンが認証を許可するユーザーを表します。- 6
userUIDは、このトークンが認証を許可するユーザーの UID を表します。- 7
authorizeTokenは、このトークンを取得するために使用される OAuthAuthorizationToken の名前です (ある場合)。
4.8.8. ユーザーオブジェクト
4.8.8.1. Identity
設定された「アイデンティティープロバイダー」を使用して、OpenShift Container Platform にユーザーはログインします。これにより、ユーザーのアイデンティティーが決定され、その情報が OpenShift Container Platform に提供されます。
次に OpenShift Container Platform は UserIdentityMapping でその Identity を検索します。
アイデンティティープロバイダーが lookup マッピング方法などで設定されている場合、外部の LDAP システムを使用している場合には、この自動マッピングは実行されません。この場合、マッピングは手動で作成する必要があります。詳細は、「Lookup マッピング方法」を参照してください。
-
Identityがすでに存在する場合でも、これがUserにマップされていないと、ログインは失敗します。 -
Identityがすでに存在し、これがUserにマップされている場合、ユーザーには、マップされたUserのOAuthAccessTokenが付与されます。 -
Identityが存在しない場合、Identity、User、およびUserIdentityMappingが作成され、ユーザーには、マップされたUserのOAuthAccessTokenが付与されます。
Identity オブジェクト定義
4.8.8.2. ユーザー
User はシステムのアクターを表します。ユーザーには、「ロールをユーザーまたはグループに追加」してパーミッションが付与されます。
ユーザーオブジェクトは初回ログイン時に自動的に作成されるか、API で作成できます。
/、:、および % を含む OpenShift Container Platform ユーザー名はサポートされません。
User オブジェクト定義
4.8.8.3. UserIdentityMapping
UserIdentityMapping は Identity を User にマップします。
UserIdentityMapping を作成し、更新し、または削除することにより、Identity および User オブジェクトの対応するフィールドが変更されます。
Identity は単一の User にのみマップされるため、特定のアイデンティティーとしてログインすると、User が明確に判別されます。
User には複数のアイデンティティーをマップできます。これにより、複数のログイン方法で同じ User を識別できます。
UserIdentityMapping オブジェクト定義
- 1
UserIdentityMapping名は、マップされたIdentity名に一致します。
4.8.8.4. グループ
Groupは、システム内のユーザーの一覧を表します。グループには、「ロールをユーザーまたはグループに追加」してパーミッションが付与されます。
Group オブジェクト定義
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}