第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 サーバーのバージョン 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>
ユーザーの代わりにプロジェクト要求を作成する必要がある場合、--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
4.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 |
|
追加のクライアントを登録するには、以下を実行します。
$ oc create -f <(echo ' kind: OAuthClient apiVersion: oauth.openshift.io/v1 metadata: name: demo 1 secret: "..." 2 redirectURIs: - "http://www.example.com/" 3 grantMethod: prompt 4 ')
- 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>
-
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>
最も単純な形態として、有効なリダイレクト URI を直接指定するためにアノテーションを使用できます。以下は例になります。
"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\"}}"このアノテーションの値にはシリアライズされた JSON データが含まれるため、拡張フォーマットを使用するとより容易に表示できます。
{
"kind": "OAuthRedirectReference",
"apiVersion": "v1",
"reference": {
"kind": "Route",
"name": "jenkins"
}
}
ここでは、OAuthRedirectReference により jenkins という名前のルートを参照できます。そのため、そのルートのすべての ingress は有効とみなされます。OAuthRedirectReference の詳細な仕様は以下のようになります。
{
"kind": "OAuthRedirectReference",
"apiVersion": "v1",
"reference": {
"kind": ..., 1
"name": ..., 2
"group": ... 3
}
}両方のアノテーションのプレフィックスも組み合わせて、参照オブジェクトで提供されるデータを上書きできます。以下は例になります。
"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\"}}"
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"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 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 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>
以下は発生する可能性のあるイベントエラーの一覧です。
リダイレクト URI アノテーションが指定されていないか、無効な URI が指定されている
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 [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 [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>]
SA トークンがない
Reason Message NoSAOAuthTokens system:serviceaccount:myproject:proxy has no tokens
4.1.4.3.1.1. 設定ミスによって生じる API イベントのサンプル
以下の手順は、障害が発生する場合に問題を解決方する方法を示しています。
サービスアカウントを OAuth クライアントとして使用してプロジェクトを作成します。
プロキシーサービスアカウントオブジェクトの YAML を作成し、これがルートの
proxyを使用することを確認します。vi serviceaccount.yaml
以下のサンプルコードを追加します。
apiVersion: v1 kind: ServiceAccount metadata: name: proxy annotations: serviceaccounts.openshift.io/oauth-redirectreference.primary: '{"kind":"OAuthRedirectReference","apiVersion":"v1","reference":{"kind":"Route","name":"proxy"}}'プロキシーへのセキュアな接続を作成するために、ルートオブジェクトの YAML を作成します。
vi route.yaml
以下のサンプルコードを追加します。
apiVersion: route.openshift.io/v1 kind: Route metadata: name: proxy spec: to: name: proxy tls: termination: Reencrypt apiVersion: v1 kind: Service metadata: name: proxy annotations: service.alpha.openshift.io/serving-cert-secret-name: proxy-tls spec: ports: - name: proxy port: 443 targetPort: 8443 selector: app: proxyプロキシーをサイドカーとして起動するために、デプロイメント設定の YAML を作成します。
vi proxysidecar.yaml
以下のサンプルコードを追加します。
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: proxy spec: replicas: 1 selector: matchLabels: app: proxy template: metadata: labels: app: proxy spec: serviceAccountName: proxy containers: - name: oauth-proxy image: openshift/oauth-proxy:v1.0.0 imagePullPolicy: IfNotPresent ports: - containerPort: 8443 name: public args: - --https-address=:8443 - --provider=openshift - --openshift-service-account=proxy - --upstream=http://localhost:8080 - --tls-cert=/etc/tls/private/tls.crt - --tls-key=/etc/tls/private/tls.key - --cookie-secret=SECRET volumeMounts: - mountPath: /etc/tls/private name: proxy-tls - name: app image: openshift/hello-openshift:latest volumes: - name: proxy-tls secret: secretName: proxy-tlsオブジェクトを作成します。
oc create -f serviceaccount.yaml oc create -f route.yaml oc create -f proxysidecar.yaml
oc edit sa/proxyを実行してサービスアカウントを編集し、serviceaccounts.openshift.io/oauth-redirectreferenceアノテーションを、存在しないルートを参照するように変更します。apiVersion: v1 imagePullSecrets: - name: proxy-dockercfg-08d5n kind: ServiceAccount metadata: annotations: serviceaccounts.openshift.io/oauth-redirectreference.primary: '{"kind":"OAuthRedirectReference","apiVersion":"v1","reference":{"kind":"Route","name":"notexist"}}' ...OAuth ログでサービスを確認し、サーバーエラーを見つけます。
The authorization server encountered an unexpected condition that prevented it from fulfilling the request.
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>]
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 要求を実行し、以下の情報を取得できます。
{
"issuer": "https://<master>", 1
"authorization_endpoint": "https://<master>/oauth/authorize", 2
"token_endpoint": "https://<master>/oauth/token", 3
"scopes_supported": [ 4
"user:full",
"user:info",
"user:check-access",
"user:list-scoped-projects",
"user:list-projects"
],
"response_types_supported": [ 5
"code",
"token"
],
"grant_types_supported": [ 6
"authorization_code",
"implicit"
],
"code_challenge_methods_supported": [ 7
"plain",
"S256"
]
}- 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 |
|
|
|
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
Name: admin Labels: <none> Annotations: openshift.io/description=A user that has edit rights within the project and can change the project's membership. rbac.authorization.kubernetes.io/autoupdate=true PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- appliedclusterresourcequotas [] [] [get list watch] appliedclusterresourcequotas.quota.openshift.io [] [] [get list watch] bindings [] [] [get list watch] buildconfigs [] [] [create delete deletecollection get list patch update watch] buildconfigs.build.openshift.io [] [] [create delete deletecollection get list patch update watch] buildconfigs/instantiate [] [] [create] buildconfigs.build.openshift.io/instantiate [] [] [create] buildconfigs/instantiatebinary [] [] [create] buildconfigs.build.openshift.io/instantiatebinary [] [] [create] buildconfigs/webhooks [] [] [create delete deletecollection get list patch update watch] buildconfigs.build.openshift.io/webhooks [] [] [create delete deletecollection get list patch update watch] buildlogs [] [] [create delete deletecollection get list patch update watch] buildlogs.build.openshift.io [] [] [create delete deletecollection get list patch update watch] builds [] [] [create delete deletecollection get list patch update watch] builds.build.openshift.io [] [] [create delete deletecollection get list patch update watch] builds/clone [] [] [create] builds.build.openshift.io/clone [] [] [create] builds/details [] [] [update] builds.build.openshift.io/details [] [] [update] builds/log [] [] [get list watch] builds.build.openshift.io/log [] [] [get list watch] configmaps [] [] [create delete deletecollection get list patch update watch] cronjobs.batch [] [] [create delete deletecollection get list patch update watch] daemonsets.extensions [] [] [get list watch] deploymentconfigrollbacks [] [] [create] deploymentconfigrollbacks.apps.openshift.io [] [] [create] deploymentconfigs [] [] [create delete deletecollection get list patch update watch] deploymentconfigs.apps.openshift.io [] [] [create delete deletecollection get list patch update watch] deploymentconfigs/instantiate [] [] [create] deploymentconfigs.apps.openshift.io/instantiate [] [] [create] deploymentconfigs/log [] [] [get list watch] deploymentconfigs.apps.openshift.io/log [] [] [get list watch] deploymentconfigs/rollback [] [] [create] deploymentconfigs.apps.openshift.io/rollback [] [] [create] deploymentconfigs/scale [] [] [create delete deletecollection get list patch update watch] deploymentconfigs.apps.openshift.io/scale [] [] [create delete deletecollection get list patch update watch] deploymentconfigs/status [] [] [get list watch] deploymentconfigs.apps.openshift.io/status [] [] [get list watch] deployments.apps [] [] [create delete deletecollection get list patch update watch] deployments.extensions [] [] [create delete deletecollection get list patch update watch] deployments.extensions/rollback [] [] [create delete deletecollection get list patch update watch] deployments.apps/scale [] [] [create delete deletecollection get list patch update watch] deployments.extensions/scale [] [] [create delete deletecollection get list patch update watch] deployments.apps/status [] [] [create delete deletecollection get list patch update watch] endpoints [] [] [create delete deletecollection get list patch update watch] events [] [] [get list watch] horizontalPodautoscalers.autoscaling [] [] [create delete deletecollection get list patch update watch] horizontalPodautoscalers.extensions [] [] [create delete deletecollection get list patch update watch] imagestreamimages [] [] [create delete deletecollection get list patch update watch] imagestreamimages.image.openshift.io [] [] [create delete deletecollection get list patch update watch] imagestreamimports [] [] [create] imagestreamimports.image.openshift.io [] [] [create] imagestreammappings [] [] [create delete deletecollection get list patch update watch] imagestreammappings.image.openshift.io [] [] [create delete deletecollection get list patch update watch] imagestreams [] [] [create delete deletecollection get list patch update watch] imagestreams.image.openshift.io [] [] [create delete deletecollection get list patch update watch] imagestreams/layers [] [] [get update] imagestreams.image.openshift.io/layers [] [] [get update] imagestreams/secrets [] [] [create delete deletecollection get list patch update watch] imagestreams.image.openshift.io/secrets [] [] [create delete deletecollection get list patch update watch] imagestreams/status [] [] [get list watch] imagestreams.image.openshift.io/status [] [] [get list watch] imagestreamtags [] [] [create delete deletecollection get list patch update watch] imagestreamtags.image.openshift.io [] [] [create delete deletecollection get list patch update watch] jenkins.build.openshift.io [] [] [admin edit view] jobs.batch [] [] [create delete deletecollection get list patch update watch] limitranges [] [] [get list watch] localresourceaccessreviews [] [] [create] localresourceaccessreviews.authorization.openshift.io [] [] [create] localsubjectaccessreviews [] [] [create] localsubjectaccessreviews.authorization.k8s.io [] [] [create] localsubjectaccessreviews.authorization.openshift.io [] [] [create] namespaces [] [] [get list watch] namespaces/status [] [] [get list watch] networkpolicies.extensions [] [] [create delete deletecollection get list patch update watch] persistentvolumeclaims [] [] [create delete deletecollection get list patch update watch] Pods [] [] [create delete deletecollection get list patch update watch] Pods/attach [] [] [create delete deletecollection get list patch update watch] Pods/exec [] [] [create delete deletecollection get list patch update watch] Pods/log [] [] [get list watch] Pods/portforward [] [] [create delete deletecollection get list patch update watch] Pods/proxy [] [] [create delete deletecollection get list patch update watch] Pods/status [] [] [get list watch] Podsecuritypolicyreviews [] [] [create] Podsecuritypolicyreviews.security.openshift.io [] [] [create] Podsecuritypolicyselfsubjectreviews [] [] [create] Podsecuritypolicyselfsubjectreviews.security.openshift.io [] [] [create] Podsecuritypolicysubjectreviews [] [] [create] Podsecuritypolicysubjectreviews.security.openshift.io [] [] [create] processedtemplates [] [] [create delete deletecollection get list patch update watch] processedtemplates.template.openshift.io [] [] [create delete deletecollection get list patch update watch] projects [] [] [delete get patch update] projects.project.openshift.io [] [] [delete get patch update] replicasets.extensions [] [] [create delete deletecollection get list patch update watch] replicasets.extensions/scale [] [] [create delete deletecollection get list patch update watch] replicationcontrollers [] [] [create delete deletecollection get list patch update watch] replicationcontrollers/scale [] [] [create delete deletecollection get list patch update watch] replicationcontrollers.extensions/scale [] [] [create delete deletecollection get list patch update watch] replicationcontrollers/status [] [] [get list watch] resourceaccessreviews [] [] [create] resourceaccessreviews.authorization.openshift.io [] [] [create] resourcequotas [] [] [get list watch] resourcequotas/status [] [] [get list watch] resourcequotausages [] [] [get list watch] rolebindingrestrictions [] [] [get list watch] rolebindingrestrictions.authorization.openshift.io [] [] [get list watch] rolebindings [] [] [create delete deletecollection get list patch update watch] rolebindings.authorization.openshift.io [] [] [create delete deletecollection get list patch update watch] rolebindings.rbac.authorization.k8s.io [] [] [create delete deletecollection get list patch update watch] roles [] [] [create delete deletecollection get list patch update watch] roles.authorization.openshift.io [] [] [create delete deletecollection get list patch update watch] roles.rbac.authorization.k8s.io [] [] [create delete deletecollection get list patch update watch] routes [] [] [create delete deletecollection get list patch update watch] routes.route.openshift.io [] [] [create delete deletecollection get list patch update watch] routes/custom-host [] [] [create] routes.route.openshift.io/custom-host [] [] [create] routes/status [] [] [get list watch update] routes.route.openshift.io/status [] [] [get list watch update] scheduledjobs.batch [] [] [create delete deletecollection get list patch update watch] secrets [] [] [create delete deletecollection get list patch update watch] serviceaccounts [] [] [create delete deletecollection get list patch update watch impersonate] services [] [] [create delete deletecollection get list patch update watch] services/proxy [] [] [create delete deletecollection get list patch update watch] statefulsets.apps [] [] [create delete deletecollection get list patch update watch] subjectaccessreviews [] [] [create] subjectaccessreviews.authorization.openshift.io [] [] [create] subjectrulesreviews [] [] [create] subjectrulesreviews.authorization.openshift.io [] [] [create] templateconfigs [] [] [create delete deletecollection get list patch update watch] templateconfigs.template.openshift.io [] [] [create delete deletecollection get list patch update watch] templateinstances [] [] [create delete deletecollection get list patch update watch] templateinstances.template.openshift.io [] [] [create delete deletecollection get list patch update watch] templates [] [] [create delete deletecollection get list patch update watch] templates.template.openshift.io [] [] [create delete deletecollection get list patch update watch] Name: basic-user Labels: <none> Annotations: openshift.io/description=A user that can get basic information about projects. rbac.authorization.kubernetes.io/autoupdate=true PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- clusterroles [] [] [get list] clusterroles.authorization.openshift.io [] [] [get list] clusterroles.rbac.authorization.k8s.io [] [] [get list watch] projectrequests [] [] [list] projectrequests.project.openshift.io [] [] [list] projects [] [] [list watch] projects.project.openshift.io [] [] [list watch] selfsubjectaccessreviews.authorization.k8s.io [] [] [create] selfsubjectrulesreviews [] [] [create] selfsubjectrulesreviews.authorization.openshift.io [] [] [create] storageclasses.storage.k8s.io [] [] [get list] users [] [~] [get] users.user.openshift.io [] [~] [get]
ローカルロールバインディングを表示して得られる以下の抜粋は、上記のロールが各種のユーザーおよびグループにバインドされていることを示しています。
oc describe rolebinding.rbac admin basic-user -n alice-project
Name: admin Labels: <none> Annotations: <none> Role: Kind: ClusterRole Name: admin Subjects: Kind Name Namespace ---- ---- --------- User system:admin User alice Name: basic-user Labels: <none> Annotations: <none> Role: Kind: ClusterRole Name: basic-user Subjects: Kind Name Namespace ---- ---- --------- User joe Group devel
クラスターロール、クラスターロールのバインディング、ローカルロールのバインディング、ユーザー、グループおよびサービスアカウントの関係は以下に説明されています。

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 クラスターのアップグレード後に、デフォルトのロールは更新され、サーバーの起動時に自動的に調整されます。以下を使用した他の推奨方法についての詳細は、「ポリシー定義の更新」を参照してください。
$ oc adm policy reconcile-cluster-roles
4.2.4.2. カスタムロールおよびパーミッションの適用
カスタムロールおよびパーミッションを追加するか、または更新するには、以下のコマンドを使用することを強く推奨します。
# 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 を使用してそれらを表示できます。
$ oc get scc NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP PRIORITY READONLYROOTFS VOLUMES anyuid false [] MustRunAs RunAsAny RunAsAny RunAsAny 10 false [configMap downwardAPI emptyDir persistentVolumeClaim secret] hostaccess false [] MustRunAs MustRunAsRange MustRunAs RunAsAny <none> false [configMap downwardAPI emptyDir hostPath persistentVolumeClaim secret] hostmount-anyuid false [] MustRunAs RunAsAny RunAsAny RunAsAny <none> false [configMap downwardAPI emptyDir hostPath nfs persistentVolumeClaim secret] hostnetwork false [] MustRunAs MustRunAsRange MustRunAs MustRunAs <none> false [configMap downwardAPI emptyDir persistentVolumeClaim secret] nonroot false [] MustRunAs MustRunAsNonRoot RunAsAny RunAsAny <none> false [configMap downwardAPI emptyDir persistentVolumeClaim secret] privileged true [*] RunAsAny RunAsAny RunAsAny RunAsAny <none> false [*] restricted false [] MustRunAs MustRunAsRange MustRunAs RunAsAny <none> false [configMap downwardAPI emptyDir persistentVolumeClaim secret]
デフォルトの SCC を変更しないでください。デフォルトの SCC をカスタマイズすると、OpenShift Container Platform のアップグレード時に問題が発生する可能性があります。その代わりに、新規 SCC を作成します。
各 SCC の定義についても、クラスター管理者は CLI を使用して表示できます。たとえば、特権付き SCC の場合は、以下のようになります。
# oc export scc/privileged allowHostDirVolumePlugin: true allowHostIPC: true allowHostNetwork: true allowHostPID: true allowHostPorts: true allowPrivilegedContainer: true allowedCapabilities: 1 - '*' apiVersion: v1 defaultAddCapabilities: [] 2 fsGroup: 3 type: RunAsAny groups: 4 - system:cluster-admins - system:nodes kind: SecurityContextConstraints metadata: annotations: kubernetes.io/description: 'privileged allows access to all privileged and host features and the ability to run as any user, any group, any fsGroup, and with any SELinux context. WARNING: this is the most relaxed SCC and should be used only for cluster administration. Grant with caution.' creationTimestamp: null name: privileged priority: null readOnlyRootFilesystem: false requiredDropCapabilities: [] 5 runAsUser: 6 type: RunAsAny seLinuxContext: 7 type: RunAsAny seccompProfiles: - '*' supplementalGroups: 8 type: RunAsAny users: 9 - system:serviceaccount:default:registry - system:serviceaccount:default:router - system:serviceaccount:openshift-infra:build-controller volumes: - '*'
- 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 がアクセスできるセキュリティー機能を制限する各種の設定およびストラテジーで構成されています。これらの設定は以下のカテゴリーに分類されます。
|
Controlled by a boolean (ブール値による制御) |
このタイプのフィールドはデフォルトで最も制限のある値に設定されます。たとえば、 |
|
Controlled by an allowable set (許可されるセットによる制御) |
このタイプのフィールドは該当セットに対してチェックされ、それらの値が許可されることを確認します。 |
|
Controlled by a strategy (ストラテジーによる制御) |
値を生成するストラテジーを持つ項目は以下を提供します。
|
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
4.2.5.4. Seccomp
SeccompProfiles は、Pod またはコンテナーの seccomp アノテーションに設定できる許可されたプロファイルを一覧表示します。未使用 (nil) または空の値は、プロファイルが Pod またはコンテナーで指定されないことを意味します。ワイルドカード * を使用してすべてのプロファイルを許可します。Pod の値を生成するために使用される場合、最初のワイルドカード以外のプロファイルがデフォルトとして使用されます。
カスタムプロファイルの設定および使用についての詳細は、seccomp についての説明を参照してください。
4.2.5.5. 受付 (Admission)
SCC の設定された Admission Control (受付制御) により、ユーザーに付与された機能に基づくリソース作成に対する制御が可能になります。
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
この出力は、情報収集のために実行する必要のある API 要求を判断するのに役立ちます。
ユーザーの判読可能な形式で情報を受信するには、以下を実行します。
$ oc policy can-i --list
この出力により、詳細な一覧が表示されます。
特定の動詞が実行可能かどうかを判断するには、以下を実行します。
$ oc policy can-i <verb> <resource>
ユーザースコープ は、指定のスコープに関する詳細情報を提供します。以下に例を示します。
$ oc policy can-i <verb> <resource> --scopes=user:info
4.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 は要求をボリュームとして使用します。クラスターは要求を検査して、バインドされたボリュームを検索し、Pod にそのボリュームをマウントします。複数のアクセスモードをサポートするボリュームの場合、要求を Pod のボリュームとして使用する際に適用するモードを指定する必要があります。
ユーザーがバインドされている要求を持つ場合、バインドされた PV は必要な限りユーザーに所属することになります。Pod のスケジュールおよび要求された PV のアクセスは、persistentVolumeClaim を Pod のボリュームブロックに組み込んで実行できます。構文の詳細については、以下を参照してください。
4.3.2.4. Persistent Volume Claim (永続ボリューム要求) の保護
PVC の保護はアルファ機能であり、OpenShift Container Platform の今後のリリースで変更される場合があります。
PVC 保護の目的は、Pod でアクティブに使用される PVC がシステムから削除されることによってデータ損失が生じないようにすることにあります。
PVC は、Pod ステータスが Pending で Pod がノードに割り当てられている場合や、Pod ステータスが Running の場合に Pod によってアクティブに使用された状態になります。
PVC の保護機能が有効にされている場合、Pod でアクティブに使用されている PVC を削除しても PVC はすぐに除去されません。PVC の除去は PVC が Pod でアクティブに使用されなくなるまで延期されます。
PVC のステータスが Terminating の場合、PVC が保護され、Finalizers 一覧に kubernetes.io/pvc-protection が含まれていることを確認できます。
oc describe pvc hostpath
Name: hostpath
Namespace: default
StorageClass: example-hostpath
Status: Terminating
Volume:
Labels: <none>
Annotations: volume.beta.kubernetes.io/storage-class=example-hostpath
volume.beta.kubernetes.io/storage-provisioner=example.com/hostpath
Finalizers: [kubernetes.io/pvc-protection]
...PVC の保護を有効にするには、「Persistent Volume Claim (永続ボリューム要求) 保護の設定」を参照してください。
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/*) し、これを新規の要求で再度利用可能にします。
recycle 回収ポリシーは動的プロビジョニングが優先されるために非推奨となり、今後のリリースでは削除されます。
「ControllerArguments」のセクションで説明されているように、コントローラーマネージャーのコマンドライン引数を使用してカスタム Recycler Pod テンプレートを設定できます。カスタム Recycler Pod テンプレートには、以下の例に示されているように volumes 仕様が含まれます。
apiVersion: v1 kind: Pod metadata: name: pv-recycler- namespace: openshift-infra 1 spec: restartPolicy: Never serviceAccount: pv-recycler-controller 2 volumes: - name: nfsvol nfs: server: any-server-it-will-be-replaced 3 path: any-path-it-will-be-replaced 4 containers: - name: pv-recycler image: "gcr.io/google_containers/busybox" command: ["/bin/sh", "-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/* && test -z \"$(ls -A /scrub)\" || exit 1"] volumeMounts: - name: nfsvol mountPath: /scrub
- 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 が含まれます。
永続ボリュームオブジェクトの定義
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv0003
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle
nfs:
path: /tmp
server: 172.17.0.2
4.3.3.1. 永続ボリュームのタイプ
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 が削除されていることを確認してください。
以下の表では、異なる永続ボリュームによってサポートされるアクセスモードを一覧表示しています。
表4.1 永続ボリュームのサポートされるアクセスモード
| ボリュームプラグイン | ReadWriteOnce | ReadOnlyMany | ReadWriteMany |
|---|---|---|---|
|
AWS EBS |
✅ |
- |
- |
|
Azure File |
✅ |
✅ |
✅ |
|
Azure Disk |
✅ |
- |
- |
|
Ceph RBD |
✅ |
✅ |
- |
|
ファイバーチャネル |
✅ |
✅ |
- |
|
GCE Persistent Disk |
✅ |
- |
- |
|
GlusterFS |
✅ |
✅ |
✅ |
|
HostPath |
✅ |
- |
- |
|
iSCSI |
✅ |
✅ |
- |
|
NFS |
✅ |
✅ |
✅ |
|
Openstack Cinder |
✅ |
- |
- |
|
VMWare vSphere |
✅ |
- |
- |
|
ローカル |
✅ |
- |
- |
- Pod が AWS EBS、GCE Persistent Disk、または Openstack Cinder PV を使用する場合は、再作成デプロイメントストラテジーを使用します。
4.3.3.4. 回収ポリシー
現時点で、回収ポリシーは以下のようになります。
| 回収ポリシー | 説明 |
|---|---|
|
Retain (保持) |
手動による回収 |
|
Recycle (リサイクル) |
基本的なスクラブ (例: |
現時点では、NFS および HostPath のみが「リサイクル」回収ポリシーをサポートしています。
recycle 回収ポリシーは動的プロビジョニングが優先されるために非推奨となり、今後のリリースでは削除されます。
4.3.3.5. フェーズ
ボリュームは以下のフェーズのいずれかに置かれます。
| フェーズ | 説明 |
|---|---|
|
Available |
要求にバインドされていない空きリソースです。 |
|
Bound |
ボリュームが要求にバインドされています。 |
|
Released |
要求が検出されていますが、リソースはクラスターによって回収されていません。 |
|
Failed |
ボリュームがその自動回収に失敗しています。 |
CLI には PV にバインドされている PVC の名前が表示されます。
4.3.3.6. マウントオプション
アノテーション volume.beta.kubernetes.io/mount-options を使用して永続ボリュームのマウント中にマウントオプションを指定できます。
以下は例になります。
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv0001
annotations:
volume.beta.kubernetes.io/mount-options: rw,nfsvers=4,noexec 1
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
nfs:
path: /tmp
server: 172.17.0.2
persistentVolumeReclaimPolicy: Recycle
claimRef:
name: claim1
namespace: default- 1
- 永続ボリュームのディスクへのマウント中に指定されたマウントオプションが使用されます。
以下の永続ボリュームタイプがマウントオプションをサポートします。
- 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 が含まれます。
Persistent Volume Claim (永続ボリューム要求、PVC) オブジェクト定義
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: myclaim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 8Gi
storageClassName: gold
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 に組み込まれます。
kind: Pod
apiVersion: v1
metadata:
name: myPod
spec:
containers:
- name: myfrontend
image: dockerfile/nginx
volumeMounts:
- mountPath: "/var/www/html"
name: mypd
volumes:
- name: mypd
persistentVolumeClaim:
claimName: myclaim4.3.5. ブロックボリュームのサポート
ボロックボリュームのサポートはテクノロジープレビュー機能であり、手動でプロビジョニングされた永続ボリュームでのみ利用可能です。テクノロジープレビュー機能は、Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
Red Hat のテクノロジープレビュー機能のサポートについての詳細は、https://access.redhat.com/support/offerings/techpreview/ を参照してください。
一部の新規 API フィールドを PV および PVC 仕様に組み込み、raw ブロックボリュームを静的にプロビジョニングできます。
ブロックボリュームを使用するには、まず BlockVolume 機能ゲートを有効にする必要があります。マスターの機能ゲートを有効にするには、feature-gates を apiServerArguments および controllerArguments に追加します。ノードの機能ゲートを有効にするには、feature-gates を kubeletArguments に追加します。以下は例になります。
kubeletArguments:
feature-gates:
- BlockVolume=true詳細情報は、「ローカルボリュームの設定」を参照してください。
永続ボリュームのサンプル
apiVersion: v1
kind: PersistentVolume
metadata:
name: block-pv
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
volumeMode: Block 1
persistentVolumeReclaimPolicy: Retain
fc:
targetWWNs: ["50060e801049cfd1"]
lun: 0
readOnly: false
- 1
volumeModeフィールドは、この PV が raw ブロックボリュームであることを示します。
Persistent Volume Claim (永続ボリューム要求) のサンプル
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: block-pvc
spec:
accessModes:
- ReadWriteOnce
volumeMode: Block 1
resources:
requests:
storage: 10Gi
- 1
volumeModeフィールドは、raw ブロック永続ボリュームが要求されていることを示します。
Pod 仕様のサンプル
apiVersion: v1
kind: Pod
metadata:
name: Pod-with-block-volume
spec:
containers:
- name: fc-container
image: fedora:26
command: ["/bin/sh", "-c"]
args: [ "tail -f /dev/null" ]
volumeDevices: 1
- name: data
devicePath: /dev/xvda 2
volumes:
- name: data
persistentVolumeClaim:
claimName: block-pvc 3
表4.2 VolumeMode の許可される値
| 値 | デフォルト |
|---|---|
|
Filesystem |
Yes |
|
Block |
No |
表4.3 ブロックボリュームのバインドシナリオ
| 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 ブロックボリュームをサポートし、今後サポートするプラグインのステータス
| プラグイン | ブロックボリュームのサポート |
|---|---|
|
ファイバーチャネル |
(マージ済み) OpenShift Container Platform 3.9 |
|
Ceph RBD |
(マージ済み) OpenShift Container Platform 3.10 |
|
iSCSI |
(進行中) OpenShift Container Platform 3.10 |
|
AWS EBS |
(進行中) OpenShift Container Platform 3.10 |
|
GCE PD |
(進行中) OpenShift Container Platform 3.10 |
|
GlusterFS |
(進行中) OpenShift Container Platform 3.10 |
4.4. ソースコントロール管理
OpenShift Container Platform は、内部 (インハウス Git サーバーなど) または外部 (GitHub、Bitbucket など) でホストされている既存のソースコントロール管理 (SCM) システムを利用します。現時点で、OpenShift Container Platform は Git ソリューションのみをサポートします。
SCM 統合はビルドに密接に関連し、以下の 2 つの点を実行します。
4.5. 受付コントローラー
4.5.1. 概要
受付制御プラグインはリソースの永続化の前にマスター API への要求をインターセプトしますが、要求の認証および承認後にこれを実行します。
それぞれの受付制御プラグインは、要求がクラスターに受け入れられる前にシーケンスで実行されます。シーケンスのプラグインが要求を拒否する場合、要求全体がただちに拒否され、エラーがエンドユーザーに返されます。
受付制御プラグインは、システムで設定されたデフォルトを適用するために受信オブジェクトを変更する場合があります。さらに、受付制御プラグインはクォータの使用の拡張などを実行する要求処理の一環として関連リソースを変更する場合もあります。
OpenShift Container Platform マスターには、各タイプのリソース (Kubernetes および OpenShift Container Platform) についてデフォルトで有効にされているプラグインのデフォルトの一覧が含まれます。それらはマスターが適切に機能するために必要です。これらの一覧を変更することは、実際の変更内容を把握している場合でない限りは推奨されません。本製品の今後のバージョンでは異なるセットのプラグインを使用し、それらの順序を変更する可能性があります。マスター設定ファイルでプラグインのデフォルトの一覧を上書きする場合、新規バージョンの OpenShift Container Platform マスターの要件を反映できるように一覧を更新する必要があります。
4.5.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 スタンザを追加してデフォルトでオフになっているプラグインを有効にする必要があります。
admissionConfig:
pluginConfig:
AlwaysPullImages: 1
configuration:
kind: DefaultAdmissionConfig
apiVersion: v1
disable: false 2
disable を true にすると、on にデフォルト設定される受付プラグインが無効になります。
受付プラグインは、API サーバーのセキュリティーを実施するために一般的に使用されています。これらを無効にする場合には注意して行ってください。
単一の受付チェーンに安全に組み込むことのできない admissionConfig 要素を使用していた場合は、API サーバーログで警告を受信し、API サーバーはレガシーの互換性のために 2 つの異なる受付チェーンで開始されることになります。警告を解決するには、admissionConfig を更新します。
4.5.3. カスタマイズ可能な受付プラグイン
クラスター管理者は、一部の受付コントロールプラグインを、以下のような特定の動作を制御するように設定できます。
4.5.4. コンテナーを使用した受付コントローラー
コンテナーを使用する受付コントローラーも init コンテナーをサポートします。
4.6. カスタム受付コントローラー
4.6.1. 概要
デフォルトの受付コントローラーのほかにも、受付 Webhook を受付チェーンの一部として使用できます。
受付 Webhook は Webhook サーバーを呼び出して、ラベルの挿入など、作成時に Pod を変更するか、または受付プロセス時に Pod 設定の特定の部分を検証します。
受付 Webhook はリソースの永続化の前にマスター API への要求をインターセプトしますが、要求の認証および承認後にこれを実行します。
4.6.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 が共通のラベルセットを持つことを条件とする場合、Pそれらのラベルを持たない Pod を永続化しないようにする必要があるとします。この場合、これらのラベルを挿入する Webhook やそれらのラベルの有無を検証する Webhook を作成することができます。その後 OpenShift Container Platform は、ラベルを持ち、検証をパスした Pod をスケジュールし、ラベルがないためにパスしない Pod を拒否します。
共通のユースケースには以下が含まれます。
- サイドカーコンテナーを Pod に挿入するためのリソースの変更
- 一部のリソースをプロジェクトからブロックするためのプロジェクトの制限
- 依存するフィールドで複雑な検証を実行するためのカスタムリソース検証
4.6.2.1. 受付 Webhook のタイプ
クラスター管理者は、API サーバーの受付チェーンに 変更用の受付 Webhook または 検証用の受付 Webhook を含めることができます。
変更用の受付 Webhook は、受付プロセスの変更フェーズで起動します。これにより、リソースコンテンツが永続化される前に変更することができます。受付 Webhook の一例として、Pod ノードセレクター機能があります。この機能は namespace でアノテーションを使用してラベルセレクターを検索し、これを Pod 仕様に追加します。
受付 Webhook 設定の変更例:
apiVersion: admissionregistration.k8s.io/v1beta1 kind: MutatingWebhookConfiguration 1 metadata: name: <controller_name> 2 webhooks: - name: <webhook_name> 3 clientConfig: 4 service: namespace: 5 name: 6 path: <webhook_url> 7 caBundle: <cert> 8 rules: 9 - operations: 10 - <operation> apiGroups: - "" apiVersions: - "*" resources: - <resource> failurePolicy: <policy> 11
- 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 設定の例:
apiVersion: admissionregistration.k8s.io/v1beta1 kind: ValidatingWebhookConfiguration 1 metadata: name: <controller_name> 2 webhooks: - name: <webhook_name> 3 clientConfig: 4 service: namespace: default 5 name: kubernetes 6 path: <webhook_url> 7 caBundle: <cert> 8 rules: 9 - operations: 10 - <operation> apiGroups: - "" apiVersions: - "*" resources: - <resource> failurePolicy: <policy> 11
- 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.6.2.2. 受付 Webhook の作成
最初に外部 Webhook サーバーをデプロイし、これが適切に機能することを確認します。これを実行しない場合、Webhook が fail open または fail closed として設定されているかに応じて、操作は無条件に許可または拒否されます。
- YAML ファイルを使用して変更用、または検証用受付 Webhook オブジェクトを設定します。
以下のコマンドを実行してオブジェクトを作成します。
oc create -f <file-name>.yaml
受付 Webhook オブジェクトの作成後、OpenShift Container Platform が新規設定を反映するまでに数秒の時間がかかります。
受付 Webhook のフロントエンドサービスを作成します。
apiVersion: v1 kind: Service metadata: labels: role: webhook 1 name: <name> spec: selector: role: webhook 2以下のコマンドを実行してオブジェクトを作成します。
oc create -f <file-name>.yaml
Webhook で制御する必要のある Pod に受付 Webhook 名を追加します。
apiVersion: v1 kind: Pod metadata: labels: role: webhook 1 name: <name> spec: containers: - name: <name> image: myrepo/myimage:latest imagePullPolicy: <policy> ports: - containerPort: 8000- 1
- Webhook をトリガーするためのラベルです。
独自のセキュアでポータブルな Webhook 受付サーバーをビルドする方法についてのエンドツーエンドの例については、kubernetes-namespace-reservation プロジェクトを参照し、ライブラリーについては generic-admission-apiserver を参照してください。
4.6.2.3. 受付 Webhook オブジェクトのサンプル
以下は、namespace が予約される場合に namespace の作成 を許可しない受付 Webhook のサンプルです。
apiVersion: admissionregistration.k8s.io/v1beta1
kind: ValidatingWebhookConfiguration
metadata:
name: namespacereservations.admission.online.openshift.io
webhooks:
- name: namespacereservations.admission.online.openshift.io
clientConfig:
service:
namespace: default
name: webhooks
path: /apis/admission.online.openshift.io/v1beta1/namespacereservations
caBundle: KUBE_CA_HERE
rules:
- operations:
- CREATE
apiGroups:
- ""
apiVersions:
- "b1"
resources:
- namespaces
failurePolicy: Ignore以下は、webhook という名前の受付 Webhook によって評価される Pod のサンプルです。
apiVersion: v1
kind: Pod
metadata:
labels:
role: webhook
name: webhook
spec:
containers:
- name: webhook
image: myrepo/myimage:latest
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8000以下は Webhook のフロントエンドサービスです。
apiVersion: v1
kind: Service
metadata:
labels:
role: webhook
name: webhook
spec:
ports:
- port: 443
targetPort: 8000
selector:
role: webhook4.7. 他の API オブジェクト
4.7.1. LimitRange
制限範囲は、Kubernetes namespace のリソースに設定される最小/最大の制限を実施するメカニズムを提供します。
制限範囲を namespace に追加することで、個別の Pod またはコンテナーによって消費される CPU およびメモリーの最小および最大量を施行できます。
4.7.2. ResourceQuota
Kubernetes は、namespace で作成されるオブジェクト数と、namespace 内のオブジェクト間で要求されるリソース合計量の両方を制限できます。これにより、namespace 内の複数のチームで単一の Kubernetes クラスターを共有でき、あるチームによって別のチームがクラスターリソース不足になることを防ぐことができます。
ResourceQuota についての詳細は、『クラスター管理』を参照してください。
4.7.3. リソース
Kubernetes の Resource は、Pod またはコンテナーによって要求され、割り当てられ、消費されるものです。例として、メモリー (RAM)、CPU、ディスク時間、およびネットワーク帯域幅があります。
詳細は、『開発者ガイド』を参照してください。
4.7.4. シークレット
シークレットは、キー、パスワード、および証明書などの機密情報のストレージです。これらは所定の Pod でアクセスできますが、定義とは別に保持されます。
4.7.5. PersistentVolume
永続ボリュームは、クラスター管理者によってプロビジョニングされるインフラストラクチャーのオブジェクト (PersistentVolume) です。永続ボリュームは、ステートフルなアプリケーションの耐久性のあるストレージを提供します。
4.7.6. PersistentVolumeClaim
PersistentVolumeClaim オブジェクトは、Pod 作成者によるストレージの要求です。Kubernetes は、要求を利用可能なボリュームのプールに対して一致させ、それらをバインドします。この要求は、Pod によってボリュームとして使用されます。Kubernetes はボリュームがこれを要求する Pod と同じノードで利用可能であることを確認します。
4.7.6.1. カスタムリソース
カスタムリソース は、API を拡張するか、独自の API をプロジェクトまたはクラスターに導入できるようにする Kubernetes API の拡張です。
リンク https://access.redhat.com/documentation/ja-jp/openshift_container_platform/3.9/html-single/cluster_administration/#admin-guide-custom-resources[カスタムリソースによる Kubernetes API の拡張] を参照してください。
4.7.7. OAuth オブジェクト
4.7.7.1. OAuthClient
OAuthClient は、RFC 6749, section 2 に説明されているように OAuth クライアントを表します。
以下の OAuthClient オブジェクトは自動的に作成されます。
|
|
Web コンソールのトークンを要求するために使用されるクライアント |
|
|
対話式ログインを処理できるユーザーエージェントで /oauth/token/request でトークンを要求するために使用されるクライアント |
|
|
WWW-Authenticate チャレンジを処理できるユーザーエージェントでトークンを要求するために使用されるクライアント |
OAuthClient オブジェクト定義
kind: "OAuthClient" accessTokenMaxAgeSeconds: null 1 apiVersion: "oauth.openshift.io/v1" metadata: name: "openshift-web-console" 2 selflink: "/oapi/v1/oAuthClients/openshift-web-console" resourceVersion: "1" creationTimestamp: "2015-01-01T01:01:01Z" respondWithChallenges: false 3 secret: "45e27750-a8aa-11e4-b2ea-3c970e4b7ffe" 4 redirectURIs: - "https://localhost:8443" 5
- 1
- アクセストークンの有効期間 (秒単位)(以下の説明を参照してください)。
- 2
nameは OAuth 要求のclient_idパラメーターとして使用されます。- 3
respondWithChallengesがtrueに設定される場合、/oauth/authorizeへの認証されていない要求は、設定される認証方法でサポートされている場合にはWWW-Authenticateチャレンジを生じさせます。- 4
secretパラメーターの値は、承認コードフローのclient_secretパラメーターとして使用されます。- 5
- 1 つ以上の絶対 URI を
redirectURIsセクションに配置できます。承認要求と共に送信されるredirect_uriパラメーターの前には、指定されたredirectURIsのいずれかが付けられる必要があります。
accessTokenMaxAgeSeconds 値は、個々の OAuth クライアントについてのマスター設定ファイルのデフォルトの accessTokenMaxAgeSeconds 値を上書きします。クライアントにこの値を設定することにより、他のクライアントの有効期間に影響を与えることなく、クライアントのアクセストークンの有効期間を長く設定できます。
-
nullの場合、マスター設定ファイルのデフォルト値が使用されます。 -
0に設定される場合、トークンは有効期限切れになりません。 -
0よりも大きな値に設定される場合、クライアント用に発行されるトークンには指定された有効期限が設定されます。たとえば、accessTokenMaxAgeSeconds: 172800により、トークンは発行後 48 時間後に有効期限切れになります。
4.7.7.2. OAuthClientAuthorization
OAuthClientAuthorization は、特定の OAuthClient に特定のスコープが設定された OAuthAccessToken が付与されることについての User による承認を表します。
OAuthClientAuthorization オブジェクトの作成は、OAuth サーバーへの承認要求時に実行されます。
OAuthClientAuthorization オブジェクト定義
kind: "OAuthClientAuthorization" apiVersion: "oauth.openshift.io/v1" metadata: name: "bob:openshift-web-console" resourceVersion: "1" creationTimestamp: "2015-01-01T01:01:01-00:00" clientName: "openshift-web-console" userName: "bob" userUID: "9311ac33-0fde-11e5-97a1-3c970e4b7ffe" scopes: []
4.7.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 オブジェクト定義
kind: "OAuthAuthorizeToken" apiVersion: "oauth.openshift.io/v1" metadata: name: "MDAwYjM5YjMtMzM1MC00NDY4LTkxODItOTA2OTE2YzE0M2Fj" 1 resourceVersion: "1" creationTimestamp: "2015-01-01T01:01:01-00:00" clientName: "openshift-web-console" 2 expiresIn: 300 3 scopes: [] redirectURI: "https://localhost:8443/console/oauth" 4 userName: "bob" 5 userUID: "9311ac33-0fde-11e5-97a1-3c970e4b7ffe" 6
- 1
nameは、OAuthAccessToken を交換するために承認コードとして使用されるトークン名を表します。- 2
clientName値は、このトークンを要求した OAuthClient です。- 3
expiresIn値は creationTimestamp の有効期限 (秒単位) です。- 4
redirectURI値は、このトークンが作成された承認フローでユーザーがリダイレクトされた場所です。- 5
userNameは、このトークンが OAuthAccessToken の取得を許可するユーザーの名前を表します。- 6
userUIDは、このトークンが OAuthAccessToken の取得を許可するユーザーの UID を表します。
4.7.7.4. OAuthAccessToken
OAuthAccessToken は、RFC 6749, section 1.4 に説明されているように OAuth アクセストークンを表します。
OAuthAccessToken は、RFC 6749, section 4.1.3 に説明されているように /oauth/token エンドポイントへの要求によって作成されます。
アクセストークンは、API に対して認証を行うためにベアラートークンとして使用されます。
OAuthAccessToken オブジェクト定義
kind: "OAuthAccessToken" apiVersion: "oauth.openshift.io/v1" metadata: name: "ODliOGE5ZmMtYzczYi00Nzk1LTg4MGEtNzQyZmUxZmUwY2Vh" 1 resourceVersion: "1" creationTimestamp: "2015-01-01T01:01:02-00:00" clientName: "openshift-web-console" 2 expiresIn: 86400 3 scopes: [] redirectURI: "https://localhost:8443/console/oauth" 4 userName: "bob" 5 userUID: "9311ac33-0fde-11e5-97a1-3c970e4b7ffe" 6 authorizeToken: "MDAwYjM5YjMtMzM1MC00NDY4LTkxODItOTA2OTE2YzE0M2Fj" 7
- 1
nameは、API に対して認証を行うためにベアラートークンとして使用されるトークン名です。- 2
clientName値は、このトークンを要求した OAuthClient です。- 3
expiresIn値は creationTimestamp の有効期限 (秒単位) です。- 4
redirectURIは、このトークンが作成された承認フローでユーザーがリダイレクトされた場所です。- 5
userNameは、このトークンが認証を許可するユーザーを表します。- 6
userUIDは、このトークンが認証を許可するユーザーの UID を表します。- 7
authorizeTokenは、このトークンを取得するために使用される OAuthAuthorizationToken の名前です (ある場合)。
4.7.8. ユーザーオブジェクト
4.7.8.1. アイデンティティー
ユーザーが 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 オブジェクト定義
kind: "Identity" apiVersion: "user.openshift.io/v1" metadata: name: "anypassword:bob" 1 uid: "9316ebad-0fde-11e5-97a1-3c970e4b7ffe" resourceVersion: "1" creationTimestamp: "2015-01-01T01:01:01-00:00" providerName: "anypassword" 2 providerUserName: "bob" 3 user: name: "bob" 4 uid: "9311ac33-0fde-11e5-97a1-3c970e4b7ffe" 5
4.7.8.2. ユーザー
User はシステムのアクターを表します。ユーザーには、ロールをユーザーまたはグループに追加してパーミッションが付与されます。
ユーザーオブジェクトは初回ログイン時に自動的に作成されるか、API で作成できます。
/, :、および % を含む OpenShift Container Platform ユーザー名はサポートされません。
User オブジェクト定義
kind: "User" apiVersion: "user.openshift.io/v1" metadata: name: "bob" 1 uid: "9311ac33-0fde-11e5-97a1-3c970e4b7ffe" resourceVersion: "1" creationTimestamp: "2015-01-01T01:01:01-00:00" identities: - "anypassword:bob" 2 fullName: "Bob User" 3
4.7.8.3. UserIdentityMapping
UserIdentityMapping は Identity を User にマップします。
UserIdentityMapping を作成し、更新し、または削除することにより、Identity および User オブジェクトの対応するフィールドが変更されます。
Identity は単一の User にのみマップされるため、特定のアイデンティティーとしてログインすると、User が明確に判別されます。
User には複数のアイデンティティーをマップできます。これにより、複数のログイン方法で同じ User を識別できます。
UserIdentityMapping オブジェクト定義
kind: "UserIdentityMapping"
apiVersion: "user.openshift.io/v1"
metadata:
name: "anypassword:bob" 1
uid: "9316ebad-0fde-11e5-97a1-3c970e4b7ffe"
resourceVersion: "1"
identity:
name: "anypassword:bob"
uid: "9316ebad-0fde-11e5-97a1-3c970e4b7ffe"
user:
name: "bob"
uid: "9311ac33-0fde-11e5-97a1-3c970e4b7ffe"
- 1
UserIdentityMapping名は、マップされたIdentity名に一致します。
4.7.8.4. グループ
Groupは、システム内のユーザーの一覧を表します。グループには、ロールをユーザーまたはグループに追加してパーミッションが付与されます。
Group オブジェクト定義
kind: "Group" apiVersion: "user.openshift.io/v1" metadata: name: "developers" 1 creationTimestamp: "2015-01-01T01:01:01-00:00" users: - "bob" 2

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.