第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 で自動的にプロビジョニングされます。これらは、クラスターのバインディングを表示 する際に確認できます。

仮想グループのデフォルトセットでは、とくに以下の点に留意してください。

Expand
仮想グループ説明

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…​ ヘッダーとして送信されます。
  • 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>
Copy to Clipboard Toggle word wrap

ユーザーの代わりにプロジェクトの要求を作成する必要がある場合、--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
Copy to Clipboard Toggle word wrap

4.1.4. OAuth

OpenShift Container Platform マスターには、組み込まれた OAuth サーバーが含まれます。ユーザーは OAuth アクセストークンを取得して、API に対して認証します。

新しい OAuth のトークンが要求されると、OAuth サーバーは設定済みの アイデンティティプロバイダー を使用して要求したユーザーのアイデンティティーを判別します。

次に、そのアイデンティティーがマップするユーザーを判別し、そのユーザーのアクセスユーザーを作成し、使用できるようにトークンを返します。

4.1.4.1. OAuth クライアント

OAuth トークンのすべての要求は、トークンを受信し、使用する OAuth クライアントを指定する必要があります。以下の OAuth クライアントは、OpenShift Container Platform API の起動時に自動的に作成されます。

Expand
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

')
Copy to Clipboard Toggle word wrap
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>
    Copy to Clipboard Toggle word wrap
  • 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>
Copy to Clipboard Toggle word wrap

最も単純なフォームでは、アノテーションは有効なリダイレクト URI を直接指定するために使用できます。以下に例を示します。

"serviceaccounts.openshift.io/oauth-redirecturi.first":  "https://example.com"
"serviceaccounts.openshift.io/oauth-redirecturi.second": "https://other.com"
Copy to Clipboard Toggle word wrap

上記の例の 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\"}}"
Copy to Clipboard Toggle word wrap

このアノテーションの値にはシリアライズされた JSON データが含まれるため、これを拡張フォーマットで表示するとより容易になります。

{
  "kind": "OAuthRedirectReference",
  "apiVersion": "v1",
  "reference": {
    "kind": "Route",
    "name": "jenkins"
  }
}
Copy to Clipboard Toggle word wrap

ここでは、OAuthRedirectReference により jenkins という名前のルートを参照できます。そのため、そのルートのすべての ingress は有効とみなされます。OAuthRedirectReference の詳細な仕様は以下のようになります。

{
  "kind": "OAuthRedirectReference",
  "apiVersion": "v1",
  "reference": {
    "kind": ..., 
1

    "name": ..., 
2

    "group": ... 
3

  }
}
Copy to Clipboard Toggle word wrap
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\"}}"
Copy to Clipboard Toggle word wrap

first ポストフィックスはアノテーションを関連付けるために使用されます。jenkins ルートに https://example.com の ingress がある場合に、https://example.com/custompath が有効とみなされますが、https://example.com は有効とみなされません。上書きデータを部分的に指定するためのフォーマットは以下のようになります。

Expand
タイプ構文

スキーム

"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\"}}"
Copy to Clipboard Toggle word wrap

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"
Copy to Clipboard Toggle word wrap
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
Copy to Clipboard Toggle word wrap

出力例

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>
Copy to Clipboard Toggle word wrap

oc describe sa/<service-account-name> を実行すると、指定のサービスアカウント名に関連付けられた OAuth イベントが報告されます。

$ oc describe sa/proxy | grep -A5 Events
Copy to Clipboard Toggle word wrap

出力例

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>
Copy to Clipboard Toggle word wrap

以下は生じる可能性のあるイベントエラーの一覧です。

リダイレクト 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>
Copy to Clipboard Toggle word wrap

無効なルートが指定されている

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>]
Copy to Clipboard Toggle word wrap

無効な参照タイプが指定されている

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>]
Copy to Clipboard Toggle word wrap

SA トークンがない

Reason                  Message
NoSAOAuthTokens         system:serviceaccount:myproject:proxy has no tokens
Copy to Clipboard Toggle word wrap
4.1.4.3.1.1. 誤設定の場合に引き起こされる API イベントのサンプル

以下の手順は、ユーザーが破損状態に入る 1 つの経緯とこの問題の解決方法を示しています。

  1. サービスアカウントを OAuth クライアントとして利用するプロジェクトを作成します。

    1. プロキシーサービスアカウントオブジェクトの YAML を作成し、これがルートの proxy を使用することを確認します。

      $ vi serviceaccount.yaml
      Copy to Clipboard Toggle word wrap

      以下のサンプルコードを追加します。

      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: proxy
        annotations:
          serviceaccounts.openshift.io/oauth-redirectreference.primary: '{"kind":"OAuthRedirectReference","apiVersion":"v1","reference":{"kind":"Route","name":"proxy"}}'
      Copy to Clipboard Toggle word wrap
    2. プロキシーへのセキュアな接続を作成するために、ルートオブジェクトの YAML を作成します。

      $ vi route.yaml
      Copy to Clipboard Toggle word wrap

      以下のサンプルコードを追加します。

      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
      Copy to Clipboard Toggle word wrap
    3. プロキシーをサイドカーとして起動するために、デプロイメント設定の YAML を作成します。

      $ vi proxysidecar.yaml
      Copy to Clipboard Toggle word wrap

      以下のサンプルコードを追加します。

      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: openshift3/oauth-proxy
              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
      Copy to Clipboard Toggle word wrap
    4. 3 つのオブジェクトを作成します。

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

    The authorization server encountered an unexpected condition that prevented it from fulfilling the request.
    Copy to Clipboard Toggle word wrap
  4. oc get events を実行して ServiceAccount イベントを表示します。

    $ oc get events | grep ServiceAccount
    Copy to Clipboard Toggle word wrap

    出力例

    23m        23m         1         proxy                    ServiceAccount                                  Warning   NoSAOAuthRedirectURIs   service-account-oauth-client-getter   [routes.route.openshift.io "notexist" not found, system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]
    Copy to Clipboard Toggle word wrap

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"
  ]
}
Copy to Clipboard Toggle word wrap
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 認証フローをサポートします。

以下のコマンドを実行し、Authorization Code Grant (認可コードによるグラント) 方法を使用して OAuth トークンを要求します。

$ curl -H "X-Remote-User: <username>" \
     --cacert /etc/origin/master/ca.crt \
     --cert /etc/origin/master/admin.crt \
     --key /etc/origin/master/admin.key \
     -I https://<master-address>/oauth/authorize?response_type=token\&client_id=openshift-challenging-client | grep -oP "access_token=\K[^&]*"
Copy to Clipboard Toggle word wrap

OAuth トークンを、(openshift-challenging-client などの) WWW-Authenticate チャレンジ を要求するように設定された client_id で Implicit Grant (暗黙的グラント) フロー (response_type=token) を使用して要求する場合、以下が /oauth/authorize から送られる可能性のあるサーバー応答、およびそれらの処理方法になります。

Expand
ステータス内容クライアント応答

302

URL フラグメントに access_token パラメーターを含む Location ヘッダー (RFC 4.2.2)

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

302

error クエリーパラメーターを含む Location ヘッダー (RFC 4.1.2.1)

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

302

他の Location ヘッダー

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

401

WWW-Authenticate ヘッダーが存在する

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

401

WWW-Authenticate ヘッダーがない

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

その他

その他

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

Implicit Grant (暗黙的グラント) フローを使用して OAuth トークンを要求するには、以下を実行します。

$ curl -u <username>:<password>
'https://<master-address>:8443/oauth/authorize?client_id=openshift-challenging-client&response_type=token' -skv / 
1

/ -H "X-CSRF-Token: xxx" 
2
Copy to Clipboard Toggle word wrap

出力例

*   Trying 10.64.33.43...
* Connected to 10.64.33.43 (10.64.33.43) port 8443 (#0)
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 592 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
*        server certificate verification SKIPPED
*        server certificate status verification SKIPPED
*        common name: 10.64.33.43 (matched)
*        server certificate expiration date OK
*        server certificate activation date OK
*        certificate public key: RSA
*        certificate version: #3
*        subject: CN=10.64.33.43
*        start date: Thu, 09 Aug 2018 04:00:39 GMT
*        expire date: Sat, 08 Aug 2020 04:00:40 GMT
*        issuer: CN=openshift-signer@1531109367
*        compression: NULL
* ALPN, server accepted to use http/1.1
* Server auth using Basic with user 'developer'
> GET /oauth/authorize?client_id=openshift-challenging-client&response_type=token HTTP/1.1
> Host: 10.64.33.43:8443
> Authorization: Basic ZGV2ZWxvcGVyOmRzc2Zkcw==
> User-Agent: curl/7.47.0
> Accept: */*
> X-CSRF-Token: xxx
>
< HTTP/1.1 302 Found
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Expires: Fri, 01 Jan 1990 00:00:00 GMT
< Location:
https://10.64.33.43:8443/oauth/token/implicit#access_token=gzTwOq_mVJ7ovHliHBTgRQEEXa1aCZD9lnj7lSw3ekQ&expires_in=86400&scope=user%3Afull&token_type=Bearer 
1

< Pragma: no-cache
< Set-Cookie: ssn=MTUzNTk0OTc1MnxIckVfNW5vNFlLSlF5MF9GWEF6Zm55Vl95bi1ZNE41S1NCbFJMYnN1TWVwR1hwZmlLMzFQRklzVXRkc0RnUGEzdnBEa0NZZndXV2ZUVzN1dmFPM2dHSUlzUmVXakQ3Q09rVXpxNlRoVmVkQU5DYmdLTE9SUWlyNkJJTm1mSDQ0N2pCV09La3gzMkMzckwxc1V1QXpybFlXT2ZYSmI2R2FTVEZsdDBzRjJ8vk6zrQPjQUmoJCqb8Dt5j5s0b4wZlITgKlho9wlKAZI=; Path=/; HttpOnly; Secure
< Date: Mon, 03 Sep 2018 04:42:32 GMT
< Content-Length: 0
< Content-Type: text/plain; charset=utf-8
<
* Connection #0 to host 10.64.33.43 left intact
Copy to Clipboard Toggle word wrap

1
client-idopenshift-challenging-client に設定され、response-typetoken に設定されます。
2
X-CSRF-Token ヘッダーを空でない値に設定します。
1
トークンは、access_token=gzTwOq_mVJ7ovHliHBTgRQEEXa1aCZD9lnj7lSw3ekQ として 302 応答の Location ヘッダーで返されます。

OAuth トークンの値のみを表示するには、以下のコマンドを実行します。

$ curl -u <username>:<password> /
'https://<master-address>:8443/oauth/authorize?client_id=openshift-challenging-client&response_type=token' / 
1

-skv -H "X-CSRF-Token: xxx" --stderr - |  grep -oP "access_token=\K[^&]*" 
2
Copy to Clipboard Toggle word wrap
1
client-idopenshift-challenging-client に設定され、response-typetoken に設定されます。
2
X-CSRF-Token ヘッダーを空でない値に設定します。

出力例

hvqxe5aMlAzvbqfM2WWw3D6tR0R2jCQGKx0viZBxwmc
Copy to Clipboard Toggle word wrap

トークンを要求するために Code Grant 方法を使用することもできます。

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 コンソールのログイン試行回数をカウントします。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat