第4章 追加の概念
4.1. 認証
4.1.1. 概要
認証層は、OpenShift Container Platform API への要求に関連付けられたユーザーを識別します。次に、認証層は要求が許可されるかどうかを判別するために要求側のユーザーについての情報を使用します。
As an administrator, you can configure authentication using a master configuration file.
4.1.2. ユーザーとグループ
OpenShift Container Platform の ユーザー は、OpenShift Container Platform API に要求できるエンティティーです。通常、これは OpenShift Container Platform と対話している開発者または管理者のアカウントを表します。
A user can be assigned to one or more groups, each of which represent a certain set of users. Groups are useful when managing authorization policies to grant permissions to multiple users at once, for example allowing access to objects within a project, versus granting them to users individually.
In addition to explicitly defined groups, there are also system groups, or virtual groups, that are automatically provisioned by OpenShift. These can be seen when viewing cluster bindings.
仮想グループのデフォルトセットでは、とくに以下の点に留意してください。
仮想グループ | 説明 |
---|---|
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 サーバーから取得されます。 -
Sent as an
Authorization: Bearer…
header -
Sent as an
access_token=…
query parameter for websocket requests prior to OpenShift Container Platform server version 3.6. -
Sent as a websocket subprotocol header in the form
base64url.bearer.authorization.k8s.io.<base64url-encoded-token>
for websocket requests in OpenShift Container Platform server version 3.6 and later.
-
- 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>
If you need to create a project request on behalf of a user, include the --as=<user> --as-group=<group1> --as-group=<group2>
flags in your command. Because system:authenticated:oauth
is the only bootstrap group that can create project requests, you must impersonate that group, as shown in the following example:
$ 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 に対して認証を実行します。
When a person requests a new OAuth token, the OAuth server uses the configured identity provider to determine the identity of the person making the request.
次に、そのアイデンティティーがマップするユーザーを判別し、そのユーザーのアクセスユーザーを作成し、使用できるようにトークンを返します。
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 イベントのサンプル
以下の手順は、ユーザーが破損状態に入る 1 つの経緯とこの問題の解決方法を示しています。
サービスアカウントを 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
Create the objects
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 ログでサービスを確認し、サーバーエラーを見つけます。
承認サーバーに、要求を満たすことを阻む予期しないエラーが発生しました。
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. 統合
All requests for OAuth tokens involve a request to <master>/oauth/authorize
. Most authentication integrations place an authenticating proxy in front of this endpoint, or configure OpenShift Container Platform to validate credentials against a backing identity provider. Requests to <master>/oauth/authorize
can come from user-agents that cannot display interactive login pages, such as the CLI. Therefore, OpenShift Container Platform supports authenticating using a WWW-Authenticate
challenge in addition to interactive login flows.
認証プロキシーが <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-known
RFC 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 チャレンジ
を要求するように設定された 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 の |
ロール |
ルールのコレクションです。ユーザーおよびグループは、同時に複数のロールに関連付けられるか、または バインド できます。 |
バインディング |
ロールを使ったユーザーおよび/グループ間の関連付けです。 |
Cluster administrators can visualize rules, roles, and bindings using the 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 |
A super-user that can perform any action in any project. When bound to a user with a local binding, they have full control over quota and every action on every resource in the project. |
cluster-status |
基本的なクラスターのステータス情報を取得できるユーザーです。 |
edit |
プロジェクトのほとんどのプロジェクトを変更できるが、ロールまたはバインディングを表示したり、変更したりする機能を持たないユーザーです。 |
self-provisioner |
独自のプロジェクトを作成できるユーザーです。 |
view |
変更できないものの、プロジェクトでほとんどのオブジェクトを確認できるユーザーです。それらはロールまたはバインディングを表示したり、変更したりできません。 |
ユーザーおよびグループは複数のロールに同時に関連付けたり、バインド できることに注意してください。
Project administrators can visualize roles, including a matrix of the verbs and resources each are associated using the CLI to view local bindings.
The cluster role bound to the project administrator is limited in a project via a local binding. It is not bound cluster-wide like the cluster roles granted to the cluster-admin or system:admin.
クラスターロールは、クラスターレベルで定義されるロールですが、クラスターレベルまたはプロジェクトレベルのいずれかでバインドできます。
Learn how to create a local role for a project.
4.2.4.1. クラスターロールの更新
After any OpenShift Container Platform cluster upgrade, the default roles are updated and automatically reconciled when the server is started. Additionally, see Updating Policy Definitions for instructions on getting other recommendations using:
$ oc adm policy reconcile-cluster-roles
4.2.4.2. カスタムロールおよびパーミッションの適用
To add or update custom roles and permissions, it is strongly recommended to use the following command:
# oc auth reconcile -f FILE
このコマンドは、他のクライアントを切断しない方法で新規パーミッションが適切に適用されるようにします。これは、ルールセット間の論理カバー操作を計算することにより内部で実行され、RBAC リリースの JSON マージでは実行できません。
4.2.4.3. クラスターロールの集計
The default admin, edit, and view cluster roles support cluster role aggregation, where the cluster rules for each role are dynamically updated as new rules are created. This feature is relevant only if you extend the Kubernetes API by creating custom resources.
4.2.5. SCC (Security Context Constraints)
In addition to the RBAC resources that control what a user can do, OpenShift Container Platform provides security context constraints (SCC) that control the actions that a pod can perform and what it has the ability to access. Administrators can manage SCCs using the CLI.
SCC は永続ストレージへのアクセスを管理する場合にも非常に便利です。
SCC は、システムで許可されるために Pod の実行時に必要となる一連の条件を定義するオブジェクトです。管理者は以下を制御できます。
- Running of privileged containers.
- コンテナーが要求できる機能の追加
- ホストディレクトリーのボリュームとしての使用
- コンテナーの 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]
Do not modify the default SCCs. Customizing the default SCCs can lead to issues when OpenShift Container Platform is upgraded. Instead, create new SCCs.
各 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 がアクセスできるセキュリティー機能を制限する各種の設定およびストラテジーで構成されています。これらの設定は以下のカテゴリーに分類されます。
ブール値による制御 |
このタイプのフィールドはデフォルトで最も制限のある値に設定されます。たとえば、 |
許可されるセットによる制御 |
このタイプのフィールドはセットに対してチェックされ、それらの値が許可されることを確認します。 |
ストラテジーによる制御 |
値を生成するストラテジーを持つ項目は以下を提供します。
|
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 - デフォルトは指定されません。
fsGroup
ID の指定を許可します。
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 の値を生成するために使用される場合、最初のワイルドカード以外のプロファイルがデフォルトとして使用されます。
Refer to the seccomp documentation for more information about configuring and using custom profiles.
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
この出力で、情報収集のために実行する必要のある API 要求を判断しやすくなります。
ユーザーが判読可能な形式で情報を取得し直すには、以下を実行します。
$ oc policy can-i --list
この出力により、詳細な一覧が表示されます。
特定の動詞が実行可能かどうかを判断するには、以下を実行します。
$ oc policy can-i <verb> <resource>
User scopes can provide more information about a given scope. For example:
$ oc policy can-i <verb> <resource> --scopes=user:info
4.3. 永続ストレージ
4.3.1. 概要
Managing storage is a distinct problem from managing compute resources. OpenShift Container Platform leverages the Kubernetes persistent volume (PV) framework to allow cluster administrators to provision persistent storage for a cluster. Using persistent volume claims (PVCs), developers can request PV resources without having specific knowledge of the underlying storage infrastructure.
PVCs are specific to a project and are created and used by developers as a means to use a PV. PV resources on their own are not scoped to any single project; they can be shared across the entire OpenShift Container Platform cluster and claimed from any project. After a PV is bound to a PVC, however, that PV cannot then be bound to additional PVCs. This has the effect of scoping a bound PV to a single namespace (that of the binding project).
PV は、クラスター管理者によってプロビジョニングされるクラスターの既存のネットワーク設定されたストレージの一部を表す PersistentVolume
API オブジェクトで定義されます。これは、ノードがクラスターリソースであるのと同様にクラスター内のリソースです。PV は Volumes
のようなボリュームプラグインですが、PV を使用する個々の Pod から独立したライフサイクルを持ちます。PV オブジェクトは、NFS、iSCSI、またはクラウドプロバイダー固有のストレージシステムのいずれの場合でも、ストレージの実装の詳細をキャプチャーします。
インフラストラクチャーにおけるストレージの高可用性は、基礎となるストレージのプロバイダーに委ねられています。
PVCs are defined by a PersistentVolumeClaim
API object, which represents a request for storage by a developer. It is similar to a pod in that pods consume node resources and PVCs consume PV resources. For example, pods can request specific levels of resources (e.g., CPU and memory), while PVCs can request specific storage capacity and access modes (e.g, they can be mounted once read/write or many times read-only).
4.3.2. Lifecycle of a Volume and Claim
PV はクラスターのリソースです。PVC はそれらのリソースの要求であり、リソースに対する要求チェックとして機能します。PV と PVC 間の相互作用には以下のライフサイクルが設定されます。
4.3.2.1. Provisioning
PVC で定義される開発者からの要求に対応し、クラスター管理者はストレージおよび一致する PV をプロビジョニングする 1 つ以上の動的プロビジョナーを設定します。
または、クラスター管理者は、使用可能な実際のストレージの詳細を保持する多数の PV を前もって作成できます。PV は API に存在し、利用可能な状態になります。
4.3.2.2. Binding
When you create a PVC, you request a specific amount of storage, specify the required access mode, and can create a storage class to describe and classify the storage. The control loop in the master watches for new PVCs and binds the new PVC to an appropriate PV. If an appropriate PV does not exist, a provisioner for the storage class creates one.
PV ボリュームは、要求したボリュームを上回る可能性がありますが、これは、手動でプロビジョニングされた PV の場合に特にそう言えます。超過を最小限にするために、OpenShift Container Platform は他のすべての条件に一致する最小の PV にバインドします。
要求は、一致するボリュームが存在しないか、ストレージクラスを提供するいずれの利用可能なプロビジョナーで作成されない場合には無期限にバインドされないままになります。要求は、一致するボリュームが利用可能になるとバインドされます。たとえば、多数の手動でプロビジョニングされた 50Gi ボリュームを持つクラスターは 100Gi を要求する PVC に一致しません。PVC は 100Gi PV がクラスターに追加されるとバインドされます。
4.3.2.3. Using
Pod は要求をボリュームとして使用します。クラスターは要求を検査して、バインドされたボリュームを検索し、Pod にそのボリュームをマウントします。複数のアクセスモードをサポートするボリュームの場合、要求を Pod のボリュームとして使用する際に適用するモードを指定する必要があります。
Once you have a claim and that claim is bound, the bound PV belongs to you for as long as you need it. You can schedule pods and access claimed PVs by including persistentVolumeClaim
in the pod’s volumes block. See below for syntax details.
4.3.2.4. Persistent Volume Claim Protection
PVC protection is an alpha feature and may change in a future release of OpenShift Container Platform.
The purpose of PVC protection is to ensure that PVCs in active use by a pod are not removed from the system, as this may result in data loss.
A PVC is in active use by a pod when the pod status is Pending
, and the pod is assigned to a node or the pod status is Running
.
When the PVC protection feature is enabled, if you delete a PVC that is in active use by a pod, the PVC is not immediately removed. PVC removal is postponed until the PVC is no longer actively used by any pods.
You can see that a PVC is protected when the PVC’s status is Terminating
and the Finalizers
list includes 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] ...
To enable PVC protection, see Configuring Persistent Volume Claim Protection.
4.3.2.5. Releasing
When you are done with a volume, you can delete the PVC object from the API, which allows reclamation of the resource. The volume is considered "released" when the claim is deleted, but it is not yet available for another claim. The previous claimant’s data remains on the volume and must be handled according to policy.
4.3.2.6. Reclaiming
The reclaim policy of a PersistentVolume
tells the cluster what to do with the volume after it is released. Volumes reclaim policy can either be Retained
, Recycled
, or Deleted
.
Retained
reclaim policy allows manual reclamation of the resource for those volume plug-ins that support it. Deleted
reclaim policy deletes both the PersistentVolume
object from OpenShift Container Platform and the associated storage asset in external infrastructure, such as AWS EBS, GCE PD, or Cinder volume.
Volumes that were dynamically provisioned are always deleted.
4.3.2.6.1. Recycling
If supported by appropriate volume plug-in, recycling performs a basic scrub (rm -rf /thevolume/*
) on the volume and makes it available again for a new claim.
The recycle
reclaim policy is deprecated in favor of dynamic provisioning and it will be removed in future releases.
You can configure a custom recycler pod template using the controller manager command line arguments as described in the ControllerArguments section. The custom recycler pod template must contain a volumes
specification, as shown in the example below:
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
- Namespace where the recycler pod runs.
openshift-infra
is the recommended namespace, as it already has apv-recycler-controller
service account that can recycle volumes. - 2
- Name of service account that is allowed to mount NFS volumes. It must exist in the specified namespace. A
pv-recycler-controller
account is recommended, as it is automatically created inopenshift-infra
namespace and has all the required permissions. - 3 4
- The particular
server
andpath
values specified in the custom recycler pod template in thevolumes
part is replaced with the particular corresponding values from the PV that is being recycled.
4.3.3. Persistent Volumes
Each PV contains a spec
and status
, which is the specification and status of the volume.
Persistent Volume Object Definition
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. Types of Persistent Volumes
OpenShift Container Platform は以下の PersistentVolume
プラグインをサポートします。
4.3.3.2. 容量
Generally, a PV has a specific storage capacity. This is set using the PV’s capacity
attribute.
現時点で、ストレージ容量は設定または要求できる唯一のリソースです。今後は属性として IOPS、スループットなどが含まれる可能性があります。
4.3.3.3. Access Modes
PersistentVolume
はリソースプロバイダーでサポートされるすべての方法でホストにマウントできます。プロバイダーには各種の機能があり、それぞれの PV のアクセスモードは特定のボリュームでサポートされる特定のモードに設定されます。たとえば、NFS は複数の読み取り/書き込みクライアントをサポートしますが、特定の NFS PV は読み取り専用としてサーバー上でエクスポートされる可能性があります。それぞれの PV は、その特定の PV の機能について記述するアクセスモードの独自のセットを取得します。
Claims are matched to volumes with similar access modes. The only two matching criteria are access modes and size. A claim’s access modes represent a request. Therefore, you might be granted more, but never less. For example, if a claim requests RWO, but the only volume available is an NFS PV (RWO+ROX+RWX), then the claim would match NFS because it supports RWO.
Direct matches are always attempted first. The volume’s modes must match or contain more modes than you requested. The size must be greater than or equal to what is expected. If two types of volumes (NFS and iSCSI, for example) both have the same set of access modes, then either of them can match a claim with those modes. There is no ordering between types of volumes and no way to choose one type over another.
All volumes with the same modes are grouped, then sorted by size (smallest to largest). The binder gets the group with matching modes and iterates over each (in size order) until one size matches.
The access modes are:
アクセスモード | CLI Abbreviation | 説明 |
---|---|---|
ReadWriteOnce |
|
ボリュームは単一ノードで読み取り/書き込みとしてマウントできます。 |
ReadOnlyMany |
|
ボリュームは数多くのノードで読み取り専用としてマウントできます。 |
ReadWriteMany |
|
ボリュームは数多くのノードで読み取り/書き込みとしてマウントできます。 |
ボリュームの AccessModes
は、ボリュームの機能の記述子です。それらは施行されている制約ではありません。ストレージプロバイダーはリソースの無効な使用から生じるランタイムエラーに対応します。
たとえば、Ceph は ReadWriteOnce アクセスモードを提供します。ボリュームの ROX 機能を使用する必要がある場合は、要求に read-only
のマークを付ける必要があります。プロバイダーのエラーは、マウントエラーとしてランタイム時に表示されます。
iSCSI and Fibre Channel volumes do not have any fencing mechanisms yet. You must ensure the volumes are only used by one node at a time. In certain situations, such as draining a node, the volumes can be used simultaneously by two nodes. Before draining the node, first ensure the pods that use these volumes are deleted.
The table below lists the access modes supported by different persistent volumes:
ボリュームプラグイン | ReadWriteOnce | ReadOnlyMany | ReadWriteMany |
---|---|---|---|
AWS EBS |
✅ |
- |
- |
Azure File |
✅ |
✅ |
✅ |
Azure Disk |
✅ |
- |
- |
Ceph RBD |
✅ |
✅ |
- |
ファイバーチャネル |
✅ |
✅ |
- |
GCE Persistent Disk |
✅ |
- |
- |
GlusterFS |
✅ |
✅ |
✅ |
HostPath |
✅ |
- |
- |
iSCSI |
✅ |
✅ |
- |
NFS |
✅ |
✅ |
✅ |
Openstack Cinder |
✅ |
- |
- |
VMWare vSphere |
✅ |
- |
- |
ローカル |
✅ |
- |
- |
- If pods rely on AWS EBS, GCE Persistent Disks, or Openstack Cinder PVs, use a recreate deployment strategy
4.3.3.4. Reclaim Policy
The current reclaim policies are:
Reclaim Policy | 説明 |
---|---|
Retain (保持) |
Manual reclamation |
Recycle |
Basic scrub (e.g, |
Currently, only NFS and HostPath support the 'Recycle' reclaim policy.
The recycle
reclaim policy is deprecated in favor of dynamic provisioning and it will be removed in future releases.
4.3.3.5. フェーズ
ボリュームは以下のフェーズのいずれかにあります。
フェーズ | 説明 |
---|---|
Available |
A free resource that is not yet bound to a claim. |
Bound |
ボリュームが要求にバインドされています。 |
Released |
要求が検出されていますが、リソースがまだクラスターにより回収されていません。 |
Failed |
ボリュームが自動回収に失敗しています。 |
CLI には PV にバインドされている PVC の名前が表示されます。
4.3.3.6. Mount Options
アノテーション 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
- Specified mount options are then used while mounting the persistent volume to the disk.
以下の永続ボリュームタイプがマウントオプションをサポートします。
- 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 Claims
Each PVC contains a spec
and status
, which is the specification and status of the claim.
Persistent Volume Claim Object Definition
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: myclaim spec: accessModes: - ReadWriteOnce resources: requests: storage: 8Gi storageClassName: gold
4.3.4.1. Storage Class
要求は、ストレージクラスの名前を storageClassName
属性に指定して特定のストレージクラスをオプションでリクエストできます。リクエストされたクラスの PV、つまり PVC と同じ storageClassName
を持つ PV のみが PVC にバインドされます。クラスター管理者は 1 つ以上のストレージクラスを提供するように動的プロビジョナーを設定できます。クラスター管理者は、PVC の仕様に一致する PV をオンデマンドで作成できます。
クラスター管理者は、すべての PVC にデフォルトストレージクラスを設定することもできます。デフォルトのストレージクラスが設定されると、PVC は ""
に設定された StorageClass
または storageClassName
アノテーションがストレージクラスなしの PV にバインドされるように明示的に要求する必要があります。
4.3.4.2. Access Modes
要求は、特定のアクセスモードのストレージを要求する際にボリュームと同じ規則を使用します。
4.3.4.3. リソース
Claims, like pods, can request specific quantities of a resource. In this case, the request is for storage. The same resource model applies to both volumes and claims.
4.3.4.4. Claims As Volumes
Pods access storage by using the claim as a volume. Claims must exist in the same namespace as the pod using the claim. The cluster finds the claim in the pod’s namespace and uses it to get the PersistentVolume
backing the claim. The volume is then mounted to the host and into the 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: myclaim
4.3.5. Block Volume Support
Block Volume Support is a Technology Preview feature and it is only available for manually provisioned persistent volumes. Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend to use them for production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
Red Hat のテクノロジープレビュー機能のサポートについての詳細は、https://access.redhat.com/support/offerings/techpreview/ を参照してください。
You can statically provision raw block volumes by including some new API fields in your PV and PVC specifications.
ブロックボリュームを使用するには、まず BlockVolume
機能ゲートを有効にする必要があります。マスターの機能ゲートを有効にするには、feature-gates
を apiServerArguments
および controllerArguments
に追加します。ノードの機能ゲートを有効にするには、feature-gates
を kubeletArguments
に追加します。以下は例になります。
kubeletArguments: feature-gates: - BlockVolume=true
For more information, see Configuring for Local Volume.
Example Persistent Volume
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 ブロックボリュームであることを示します。
Example Persistent Volume Claim
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: block-pvc
spec:
accessModes:
- ReadWriteOnce
volumeMode: Block 1
resources:
requests:
storage: 10Gi
- 1
volumeMode
フィールドは、raw ブロック永続ボリュームが要求されていることを示します。
Example Pod Specification
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
値 | デフォルト |
---|---|
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 のデフォルト値が指定されます。
Plug-in | Support Block Volume |
---|---|
ファイバーチャネル |
Merged OpenShift Container Platform 3.9 |
Ceph RBD |
Merged OpenShift Container Platform 3.10 |
iSCSI |
InProgress OpenShift Container Platform 3.10 |
AWS EBS |
InProgress OpenShift Container Platform 3.10 |
GCE PD |
InProgress OpenShift Container Platform 3.10 |
GlusterFS |
InProgress OpenShift Container Platform 3.10 |
4.4. ソースコントロール管理
OpenShift Container Platform は、内部 (インハウス Git サーバーなど) または外部 (GitHub、Bitbucket など) でホストされている既存のソースコントロール管理 (SCM) システムを利用します。現時点で、OpenShift Container Platform は Git ソリューションのみをサポートします。
SCM 統合はビルドに密接に関連し、以下の 2 つの点を実行します。
-
Creating a
BuildConfig
using a repository, which allows building your application inside of OpenShift Container Platform. You can create aBuildConfig
manually or let OpenShift Container Platform create it automatically by inspecting your repository. - Triggering a build upon repository changes.
4.5. 受付コントローラー
4.5.1. 概要
受付制御プラグインはリソースの永続化の前にマスター API への要求をインターセプトしますが、要求の認証および承認後にこれを実行します。
クラスターに要求が受け入れられる前に、受付制御プラグインがそれぞれ、順番に実行されます。この順番に実行されているプラグインのいずれかが要求を拒否すると、要求全体がただちに拒否され、エンドユーザーにエラーが返されます。
受付制御プラグインは、システムで設定されたデフォルトを適用するために受信オブジェクトを変更する場合があります。さらに、受付制御プラグインはクォータ使用の増分などを実行する要求処理の一環として関連するリソースを変更する場合もあります。
OpenShift Container Platform マスターには、それぞれのタイプのリソース (Kubernetes および OpenShift Container Platform) についてデフォルトで有効にされているプラグインのデフォルトの一覧が含まれます。それらはマスターが適切に機能するために必要です。これらの一覧を変更することは、実際の変更内容を把握している場合でない限りは推奨されません。本製品の今後のバージョンでは異なるセットのプラグインを使用し、それらの順序を変更する可能性があります。マスター設定ファイルでプラグインのデフォルトの一覧を上書きする場合、新規バージョンの OpenShift Container Platform マスターの要件を反映できるように一覧を更新する必要があります。
4.5.2. 一般的な受付ルール
Starting in 3.3, OpenShift Container Platform uses a single admission chain for Kubernetes and OpenShift Container Platform resources. This changed from 3.2, and before where we had separate admission chains. This means that the top-level admissionConfig.pluginConfig
element can now contain the admission plug-in configuration, which used to be contained in kubernetesMasterConfig.admissionConfig.pluginConfig
.
kubernetesMasterConfig.admissionConfig.pluginConfig
は admissionConfig.pluginConfig
に移動し、マージされる必要があります。
Also, starting in 3.3, all the supported admission plug-ins are ordered in the single chain for you. You should no longer set admissionConfig.pluginOrderOverride
or the kubernetesMasterConfig.admissionConfig.pluginOrderOverride
. Instead, you should enable plug-ins that are off by default by either adding their plug-in-specific configuration, or adding a DefaultAdmissionConfig
stanza like this:
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 が受付要求を拒否する場合、最初のものだけがユーザーに返されます。
- If there is an error encountered when calling a webhook, that request is ignored and is be used to approve/deny the admission request.
The communication between the admission controller and the webhook server needs to be secured using TLS. Generate a CA certificate and use the certificate to sign the server certificate used by your webhook server. The PEM-formatted CA certificate is supplied to the admission controller using a mechanism, such as Service Serving Certificate Secrets.
以下の図は、複数の Webhook を呼び出す 2 つの受付 Webhook を含むプロセスを示しています。
受付 Webhook の単純な使用事例として、リソースの構文検証が挙げられます。たとえば、すべての Pod に共通のラベルセットを指定する必要のあるインフラストラクチャーがあり、そのラベルが指定されていない Pod は永続化させないようにする場合に、Webhook を作成してこれらのラベルを挿入したり、別の Webhook でラベルの有無を検証したりすることができます。その後 OpenShift Container Platform は、ラベルがあり、検証をパスした Pod をスケジュールし、ラベルがないためにパスしない Pod を拒否します。
共通のユースケースには以下が含まれます。
- サイドカーコンテナーを Pod に挿入するためのリソースの変更
- 一部のリソースをプロジェクトからブロックするためのプロジェクトの制限
- 依存するフィールドで複雑な検証を実行するためのカスタムリソース検証
4.6.2.1. 受付 Webhook のタイプ
クラスター管理者は、API サーバーの受付チェーンに 変更用の受付 Webhook または 検証用の受付 Webhook を含めることができます。
Mutating admission webhooks are invoked during the mutation phase of the admission process, which allows modification of the resource content before it is persisted. One example of a mutating admission webhook is the Pod Node Selector feature, which uses an annotation on a namespace to find a label selector and add it to the pod specification.
Sample mutating admission webhook configuration:
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
フィールドがプロジェクトのノードセレクターの制限で制約されていることを確認する、検証用の受付の例となります。
Sample validating admission webhook configuration:
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: webhook
4.7. 他の API オブジェクト
4.7.1. LimitRange
制限範囲は、Kubernetes namespace のリソースに設定される最小/最大の制限を実施するメカニズムを提供します。
制限範囲を namespace に追加することで、個別の Pod またはコンテナーによる CPU およびメモリーの最小および最大使用量を適用できます。
4.7.2. ResourceQuota
Kubernetes は、namespace で作成されるオブジェクト数と、namespace 内のオブジェクト間で要求されるリソース合計量の両方を制限できます。これにより、namespace 内の複数のチームで単一の Kubernetes クラスターを共有でき、あるチームによって別のチームがクラスターリソース不足になることを防ぐことができます。
See Cluster Administrationfor more information on ResourceQuota
.
4.7.3. リソース
Kubernetes の Resource
は、Pod またはコンテナーによって要求され、割り当てられ、消費されるものです。例として、メモリー (RAM)、CPU、ディスク時間、およびネットワーク帯域幅があります。
See the Developer Guidefor more information.
4.7.4. Secret
Secrets are storage for sensitive information, such as keys, passwords, and certificates. They are accessible by the intended pod(s), but held separately from their definitions.
4.7.5. PersistentVolume
A persistent volume is an object (PersistentVolume
) in the infrastructure provisioned by the cluster administrator. Persistent volumes provide durable storage for stateful applications.
4.7.6. PersistentVolumeClaim
A PersistentVolumeClaim
object is a request for storage by a pod author. Kubernetes matches the claim against the pool of available volumes and binds them together. The claim is then used as a volume by a pod. Kubernetes makes sure the volume is available on the same node as the pod that requires it.
4.7.6.1. カスタムリソース
カスタムリソース は、API を拡張するか、独自の API をプロジェクトまたはクラスターに導入できるようにする Kubernetes API の拡張です。
See link:https://access.redhat.com/documentation/en-us/openshift_container_platform/3.9/html-single/cluster_administration/#admin-guide-custom-resources[Extend the Kubernetes API with Custom Resources].
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
- 絶対 URI は、
redirectURIs
セクションに 1 つ以上配置できます。承認要求と共に送信される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
represents the name of the User this token allows obtaining an OAuthAccessToken for.- 6
userUID
represents the UID of the User this token allows obtaining an OAuthAccessToken for.
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
represents the User this token allows authentication as.- 6
userUID
represents the User this token allows authentication as.- 7
authorizeToken
は、このトークンを取得するために使用される OAuthAuthorizationToken の名前です (ある場合)。
4.7.8. ユーザーオブジェクト
4.7.8.1. Identity
When a user logs into OpenShift Container Platform, they do so using a configured identity provider. This determines the user’s identity, and provides that information to OpenShift Container Platform.
次に OpenShift Container Platform は UserIdentityMapping
でその Identity
を検索します。
If the identity provider is configured with the lookup
mapping method, for example, if you are using an external LDAP system, this automatic mapping is not performed. You must create the mapping manually. For more information, see Lookup Mapping Method.
-
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. ユーザー
A User
represents an actor in the system. Users are granted permissions by adding roles to users or to their groups.
ユーザーオブジェクトは初回ログイン時に自動的に作成されるか、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. グループ
A Group
represents a list of users in the system. Groups are granted permissions by adding roles to users or to their groups.
Group
オブジェクト定義
kind: "Group" apiVersion: "user.openshift.io/v1" metadata: name: "developers" 1 creationTimestamp: "2015-01-01T01:01:01-00:00" users: - "bob" 2