第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 が namespacename という 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

対話式ログインを処理できるユーザーエージェントを使用して <master>/oauth/token/request でトークンを要求します。

openshift-challenging-client

WWW-Authenticate チャレンジを処理できるユーザーエージェントでトークンを要求します。

追加のクライアントを登録するには、以下を実行します。

$ 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 クライアントの nameclient_id パラメーターとして使用されます。
2
<master>/oauth/token への要求の実行時に、secretclient_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_idsystem: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
  }
}
1
kind は参照されているオブジェクトのタイプを参照します。現時点では、route のみがサポートされています。
2
name はオブジェクトの名前を参照します。このオブジェクトはサービスアカウントと同じ namespace にある必要があります。
3
group はオブジェクトのグループを参照します。ルートのグループは空の文字列であるため、これを空白のままにします。

両方のアノテーションのプレフィックスも組み合わせて、参照オブジェクトで提供されるデータを上書きできます。以下は例になります。

"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:8000https://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 クライアントとして使用してプロジェクトを作成します。

    1. プロキシーサービスアカウントオブジェクトの 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"}}'
    2. プロキシーへのセキュアな接続を作成するために、ルートオブジェクトの 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
    3. プロキシーをサイドカーとして起動するために、デプロイメント設定の 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
    4. オブジェクトを作成します。

      oc create -f serviceaccount.yaml
      oc create -f route.yaml
      oc create -f proxysidecar.yaml
  2. 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"}}'
    ...
  3. OAuth ログでサービスを確認し、サーバーエラーを見つけます。

    The authorization server encountered an unexpected condition that prevented it from fulfilling the request.
  4. 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-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 7591OAuth 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

Location ヘッダーに URL フラグメントの access_token パラメーターが含まれます (RFC 4.2.2)。

access_token 値を OAuth トークンとして使用します。

302

Location ヘッダーに error クエリーパラメーターが含まれます (RFC 4.1.2.1)。

失敗します。オプションで error (およびオプションの error_description) クエリー値をユーザーに表示します。

302

他の Location ヘッダー

リダイレクトに従い、これらのルールを使用して結果を処理します。

401

WWW-Authenticate ヘッダーが存在します。

タイプ (BasicNegotiate など) が認識される場合にチャレンジに応答し、要求を再送信し、これらのルールを使用して結果を処理します。

401

WWW-Authenticate ヘッダーがありません。

チャレンジの認証ができません。失敗し、応答本体を表示します (これにはリンク、または OAuth トークンを取得する別の方法についての詳細が含まれる可能性があります)。

その他

その他

失敗し、オプションで応答の本体をユーザーに表示します。

4.1.4.7. Prometheus の認証メトリクス

OpenShift Container Platform は認証の試行中に以下の Prometheus システムメトリクスをキャプチャーします。

  • openshift_auth_basic_password_countoc login ユーザー名およびパスワードの試行回数をカウントします。
  • openshift_auth_basic_password_count_resultoc login ユーザー名およびパスワードの試行回数を結果 (成功またはエラー) 別にカウントします。
  • openshift_auth_form_password_count は Web コンソールのログイン試行回数をカウントします。
  • openshift_auth_form_password_count_result は Web コンソールのログイン試行回数を結果 (成功またはエラー) 別にカウントします。
  • openshift_auth_password_totaloc login および Web コンソールのログイン試行の合計数をカウントします。

4.2. 承認

4.2.1. 概要

Role-based Access Control (RBAC: ロールベースアクセス制御) オブジェクトは、ユーザーがプロジェクト内の所定のアクションを実行することが許可されるかどうかを決定します。

これにより、プラットフォーム管理者はクラスターロールおよびバインディングを使用して、OpenShift Container Platform プラットフォーム自体およびすべてのプロジェクトへの各種のアクセスレベルを持つユーザーを制御できます。

さらに開発者はローカルロールおよびバインディングを使用し、プロジェクトへのアクセスを持つユーザーを制御できます。承認は認証とは異なる手順であることに注意してください。認証については、アクションを実行するユーザーのアイデンティティーを判別することと関係があります。

承認は以下を使用して管理されます。

ルール

オブジェクトのセットで許可された動詞を設定します。たとえば、これには Pod の create を実行できるかどうかなどが含まれます。

ロール

ルールのコレクションです。ユーザーおよびグループを一度に複数のロールに関連付けたり、バインド したりできます。

バインディング

ユーザーおよび/またはグループと ロール の関連付けです。

クラスター管理者は、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

クラスターロール、クラスターロールのバインディング、ローカルロールのバインディング、ユーザー、グループおよびサービスアカウントの関係は以下に説明されています。

OpenShift Container Platform RBAC

4.2.2. 承認の評価

OpenShift Container Platform が承認を評価する際、いくつかのファクターを組み合わせて意思決定が行われます。

アイデンティティー

承認のコンテキストでは、ユーザー名およびユーザーが属するグループの一覧になります。

アクション

実行されるアクションです。ほとんどの場合、これは以下で構成されます。

プロジェクト

アクセスされるプロジェクトです。

動詞

getlistcreateupdatedeletedeletecollection または watch を使用できます。

リソース名

アクセスされる API エンドポイントです。

バインディング

バインディングの詳細一覧です。

OpenShift Container Platform は以下の手順を使って承認を評価します。

  1. アイデンティティーおよびプロジェクトでスコープ設定されたアクションは、ユーザーまたはそれらのグループに適用されるすべてのバインディングを検索するために使用されます。
  2. バインディングは、適用されるすべてのロールを見つけるために使用されます。
  3. ロールは、適用されるすべてのルールを見つけるために使用されます。
  4. 一致を見つけるために、アクションが各ルールに対してチェックされます。
  5. 一致するルールが見つからない場合、アクションはデフォルトで拒否されます。

4.2.3. クラスターおよびローカル RBAC

承認を制御する 2 つのレベルの RBAC ロールおよびバインディングがあります。

クラスター RBAC

すべてのプロジェクトで適用可能なロールおよびバインディングです。クラスター全体で存在するロールはクラスターロールとみなされます。クラスターロールのバインディングはクラスターロールのみを参照できます。

ローカル RBAC

所定のプロジェクトにスコープ設定されているロールおよびバインディングです。プロジェクトにのみ存在するロールは ローカルロール とみなされます。ローカルロールのバインディングはクラスターロールおよびローカルロールの両方を参照できます。

この 2 つのレベルからなる階層により、ローカルロールによる個別プロジェクト内のカスタマイズが可能になる一方で、クラスターロールによる複数プロジェクト間での再利用が可能になります。

評価時に、クラスターロールのバインディングおよびローカルロールのバインディングの両方が使用されます。以下は例になります。

  1. クラスター全体の「allow」ルールがチェックされます。
  2. ローカルにバインドされた「allow」ルールがチェックされます。
  3. デフォルトで拒否します。

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 の実行時に必要となる一連の条件を定義するオブジェクトです。管理者は以下を制御できます。

  1. 特権付きコンテナーの実行
  2. コンテナーが追加を要求できる機能
  3. ホストディレクトリーのボリュームとしての使用
  4. コンテナーの SELinux コンテキスト
  5. ユーザー ID
  6. ホストの namespace およびネットワークの使用
  7. Pod のボリュームを所有する FSGroup の割り当て
  8. 許可される補助グループの設定
  9. 読み取り専用のルートファイルシステムの要求
  10. ボリュームタイプの使用の制御
  11. 許可される 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 マニフェストの作成者は追加機能を要求したり、デフォルトから一部をドロップしてこの一覧を変更できます。allowedCapabilitiesdefaultAddCapabilities、および 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 (ブール値による制御)

このタイプのフィールドはデフォルトで最も制限のある値に設定されます。たとえば、AllowPrivilegedContainer は指定されていない場合は、常に false に設定されます。

Controlled by an allowable set (許可されるセットによる制御)

このタイプのフィールドは該当セットに対してチェックされ、それらの値が許可されることを確認します。

Controlled by a strategy (ストラテジーによる制御)

値を生成するストラテジーを持つ項目は以下を提供します。

  • 値を生成するメカニズム
  • 指定された値が許可される値のセット内の値であることを確認するメカニズム

4.2.5.1. SCC ストラテジー

4.2.5.1.1. RunAsUser
  1. MustRunAs - runAsUser が設定されることを要求します。デフォルトで設定済みの runAsUser を使用します。設定済みの runAsUser に対して検証します。
  2. MustRunAsRange - 事前に割り当てられた値を使用していない場合に、最小および最大値が定義されることを要求します。デフォルトでは最小値を使用します。許可される範囲全体に対して検証します。
  3. MustRunAsNonRoot - Pod がゼロ以外の runAsUser で送信されること、または USER ディレクティブをイメージに定義することを要求します。デフォルトは指定されません。
  4. RunAsAny - デフォルトは指定されません。runAsUser の指定を許可します。
4.2.5.1.2. SELinuxContext
  1. MustRunAs - 事前に割り当てられた値を使用していない場合に seLinuxOptions が設定されることを要求します。デフォルトとして seLinuxOptions を使用します。seLinuxOptions に対して検証します。
  2. RunAsAny - デフォルトは指定されません。seLinuxOptions の指定を許可します。
4.2.5.1.3. SupplementalGroups
  1. MustRunAs - 事前に割り当てられた値を使用していない場合に、少なくとも 1 つの範囲が指定されることを要求します。デフォルトとして最初の範囲の最小値を使用します。すべての範囲に対して検証します。
  2. RunAsAny - デフォルトは指定されません。supplementalGroups の指定を許可します。
4.2.5.1.4. FSGroup
  1. MustRunAs - 事前に割り当てられた値を使用していない場合に、少なくとも 1 つの範囲が指定されることを要求します。デフォルトとして最初の範囲の最小値を使用します。最初の範囲の最初の ID に対して検証します。
  2. RunAsAny - デフォルトは指定されません。fsGroup ID の指定を許可します。

4.2.5.2. ボリュームの制御

特定のボリュームタイプの使用は、SCC の volumes フィールドを設定して制御できます。このフィールドの許可される値は、ボリュームの作成時に定義されるボリュームソースに対応します。

新規 SCC の許可されるボリュームの推奨される最小セットは configMapdownwardAPIemptyDirpersistentVolumeClaimsecret、および 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 の最終的なセキュリティーコンテキストを作成します。

  1. 使用できるすべての SCC を取得します。
  2. 要求に指定されていないセキュリティーコンテキストの設定のフィールド値を生成します。
  3. 利用可能な制約に対する最終的な設定を検証します。

制約の一致するセットが検出される場合、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 の完全なセットが決定されると、それらは以下に戻づいて順序付けられます。

  1. 優先度が高い順。nil は 0 優先度とみなされます。
  2. 優先度が等しい場合、SCC は最も制限の多いものから少ないものの順に並べ替えられます。
  3. 優先度と制限のどちらも等しい場合、SCC は名前順に並べ替えられます。

デフォルトで、クラスター管理者に付与される anyuid SCC には SCC セットの優先度が指定されます。これにより、クラスター管理者は Pod の SecurityContextRunAsUser を指定しなくても 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 仕様で定義されていない場合に事前に定義された値を検索できます。

  1. 最小または最大値が設定されていない MustRunAsRangeRunAsUser ストラテジー。受付は openshift.io/sa.scc.uid-range アノテーションを検索して範囲フィールドを設定します。
  2. レベルが設定されていない MustRunAsSELinuxContext ストラテジー。受付は openshift.io/sa.scc.mcs アノテーションを検索してレベルを設定します。
  3. MustRunAsFSGroup ストラテジー。受付は openshift.io/sa.scc.supplemental-groups アノテーションを検索します。
  4. MustRunAsSupplementalGroups ストラテジー。受付は openshift.io/sa.scc.supplemental-groups アノテーションを検索します。

生成フェーズでは、セキュリティーコンテキストのプロバイダーが Pod に設定されていない値をデフォルト設定します。デフォルト設定は使用されるストラテジーに基づいて行われます。

  1. RunAsAny および MustRunAsNonRoot ストラテジーはデフォルトの値を提供しません。そのため、Pod が定義されるフィールドを必要とする場合 (グループ ID など)、このフィールドは Pod 仕様内に定義する必要があります。
  2. MustRunAs (単一の値) ストラテジーは、常に使用されるデフォルト値を提供します。たとえば、グループ ID の場合、Pod 仕様が独自の ID 値を定義する場合でも、namespace のデフォルトフィールドが Pod のグループに表示されます。
  3. 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 の回収ポリシーは、クラスターに対してリリース後のボリュームの処理方法について指示します。ボリュームの回収ポリシーは、RetainedRecycled、または 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-infra namespace に自動作成され、必要なすべてのパーミッションを含むため、推奨されるアカウントになります。
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

RWO

ボリュームは単一ノードで読み取り/書き込みとしてマウントできます。

ReadOnlyMany

ROX

ボリュームは数多くのノードで読み取り専用としてマウントできます。

ReadWriteMany

RWX

ボリュームは数多くのノードで読み取り/書き込みとしてマウントできます。

重要

ボリュームの AccessModes はボリュームの機能の記述子です。それらは施行されている制約ではありません。ストレージプロバイダーはリソースの無効な使用から生じるランタイムエラーに対応します。

たとえば、Ceph は ReadWriteOnce アクセスモードを提供します。ボリュームの ROX 機能を使用する必要がある場合は、要求に read-only のマークを付ける必要があります。プロバイダーのエラーは、マウントエラーとしてランタイム時に表示されます。

iSCSI およびファイバーチャネルボリュームにはフェンシングメカニズムがありません。ボリュームが一度に 1 つのノードでのみ使用されるようにする必要があります。ノードのドレイン (解放) などの特定の状況では、ボリュームは 2 つのノードで同時に使用される可能性があります。ノードをドレイン (解放) する前に、これらのボリュームを使用する Pod が削除されていることを確認してください。

以下の表では、異なる永続ボリュームによってサポートされるアクセスモードを一覧表示しています。

表4.1 永続ボリュームのサポートされるアクセスモード

ボリュームプラグインReadWriteOnceReadOnlyManyReadWriteMany

AWS EBS

-

-

Azure File

Azure Disk

-

-

Ceph RBD

-

ファイバーチャネル

-

GCE Persistent Disk

-

-

GlusterFS

HostPath

-

-

iSCSI

-

NFS

Openstack Cinder

-

-

VMWare vSphere

-

-

ローカル

-

-

注記

4.3.3.4. 回収ポリシー

現時点で、回収ポリシーは以下のようになります。

回収ポリシー説明

Retain (保持)

手動による回収

Recycle (リサイクル)

基本的なスクラブ (例: rm -rf /<volume>/*)

注記

現時点では、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: myclaim

4.3.5. ブロックボリュームのサポート

重要

ボロックボリュームのサポートはテクノロジープレビュー機能であり、手動でプロビジョニングされた永続ボリュームでのみ利用可能です。テクノロジープレビュー機能は、Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。

Red Hat のテクノロジープレビュー機能のサポートについての詳細は、https://access.redhat.com/support/offerings/techpreview/ を参照してください。

一部の新規 API フィールドを PV および PVC 仕様に組み込み、raw ブロックボリュームを静的にプロビジョニングできます。

ブロックボリュームを使用するには、まず BlockVolume 機能ゲートを有効にする必要があります。マスターの機能ゲートを有効にするには、feature-gatesapiServerArguments および controllerArguments に追加します。ノードの機能ゲートを有効にするには、feature-gateskubeletArguments に追加します。以下は例になります。

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

1
(volumeMounts と同様に) volumeDevices は、ブロックデバイスに使用され、PersistentVolumeClaim ソースでのみ使用できます。
2
(mountPath と同様に) devicePath は、物理デバイスへのパスを表します。
3
ボリュームソースのタイプは persistentVolumeClaim であり、予想される通りに PVC の名前に一致する必要があります。

表4.2 VolumeMode の許可される値

デフォルト

Filesystem

Yes

Block

No

表4.3 ブロックボリュームのバインドシナリオ

PV VolumeModePVC 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 サーバーなど) または外部 (GitHubBitbucket など) でホストされている既存のソースコントロール管理 (SCM) システムを利用します。現時点で、OpenShift Container Platform は Git ソリューションのみをサポートします。

SCM 統合はビルドに密接に関連し、以下の 2 つの点を実行します。

  • リポジトリーを使用して BuildConfig を作成します。これにより OpenShift Container Platform 内でのアプリケーションのビルドが可能になります。BuildConfig手動で作成することも、リポジトリーを検査して OpenShift Container Platform で自動的に作成することもできます。
  • リポジトリーの変更時のビルドをトリガーします。

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.pluginConfigadmissionConfig.pluginConfig に移動し、マージされる必要があります。

また 3.3 より、サポートされるすべての受付プラグインは単一チェーン内で順序付けられます。admissionConfig.pluginOrderOverride または kubernetesMasterConfig.admissionConfig.pluginOrderOverride を設定する必要はなくなります。代わりに、プラグイン固有の設定を追加するか、または以下のような DefaultAdmissionConfig スタンザを追加してデフォルトでオフになっているプラグインを有効にする必要があります。

admissionConfig:
  pluginConfig:
    AlwaysPullImages: 1
      configuration:
        kind: DefaultAdmissionConfig
        apiVersion: v1
        disable: false 2
1
受付プラグイン名です。
2
プラグインが有効にされる必要があることを示しています。これはオプションであり、参照用にのみ表示されます。

disabletrue にすると、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 を含むプロセスを示しています。

API admission stage

受付 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 として設定されているかに応じて、操作は無条件に許可または拒否されます。

  1. YAML ファイルを使用して変更用、または検証用受付 Webhook オブジェクトを設定します。
  2. 以下のコマンドを実行してオブジェクトを作成します。

    oc create -f <file-name>.yaml

    受付 Webhook オブジェクトの作成後、OpenShift Container Platform が新規設定を反映するまでに数秒の時間がかかります。

  3. 受付 Webhook のフロントエンドサービスを作成します。

    apiVersion: v1
    kind: Service
    metadata:
      labels:
        role: webhook 1
      name: <name>
    spec:
      selector:
       role: webhook 2
    1 2
    Webhook をトリガーするための自由形式のラベルです。
  4. 以下のコマンドを実行してオブジェクトを作成します。

    oc create -f <file-name>.yaml
  5. 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 クラスターを共有でき、あるチームによって別のチームがクラスターリソース不足になることを防ぐことができます。

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 オブジェクトは自動的に作成されます。

openshift-web-console

Web コンソールのトークンを要求するために使用されるクライアント

openshift-browser-client

対話式ログインを処理できるユーザーエージェントで /oauth/token/request でトークンを要求するために使用されるクライアント

openshift-challenging-client

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
respondWithChallengestrue に設定される場合、/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 にマップされている場合、ユーザーにはマップされた UserOAuthAccessToken が付与されます。
  • Identity が存在しない場合、IdentityUser、および UserIdentityMapping が作成され、ユーザーにはマップされた UserOAuthAccessToken が付与されます。

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

1
アイデンティティー名は providerName:providerUserName の形式である必要があります。
2
providerName はアイデンティティープロバイダーの名前です。
3
providerUserName は、アイデンティティープロバイダーのスコープでこのアイデンティティーを一意に表す名前です。
4
user パラメーターの name は、このアイデンティティーがマップされるユーザーの名前です。
5
uid は、このアイデンティティーがマップされるユーザーの UID を表します。

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

1
name は、ロールをユーザーに追加する際に使用されるユーザー名です。
2
identities の値は、このユーザーにマップされるアイデンティティーオブジェクトです。これはログインできないユーザーについて null または空にすることができます。
3
fullName 値は、ユーザーのオプションの表示名です。

4.7.8.3. UserIdentityMapping

UserIdentityMappingIdentityUser にマップします。

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

1
name は、ロールをグループに追加する際のグループ名です。
2
users の値は、このグループのメンバーであるユーザーオブジェクトの名前です。