Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

第12章 認証およびユーザーエージェントの設定

12.1. 概要

OpenShift Container Platform マスターには、OAuth サーバーがビルトインされています。開発者と管理者は、API に対する認証を実行するために OAuth アクセストークンを取得します。

管理者はマスター設定ファイルを使用して OAuth を アイデンティティープロバイダーを指定するように設定できます。アイデンティティープロバイダーは、通常インストール (advanced installation) の実行中に設定するのが最適ですが、インストール後に設定することもできます。

注記

/:、および % を含む OpenShift Container Platform ユーザー名はサポートされません。

クイックインストールまたは通常インストール (Advanced installation) 方式を使用して OpenShift Container Platform をインストールした場合、Deny All アイデンティティープロバイダーがデフォルトで使用されます。このアイデンティティープロバイダーは、すべてのユーザー名とパスワードについてアクセスを拒否します。アクセスを許可するには、別のアイデンティティープロバイダーを選択し、マスター設定ファイル (デフォルトでは、/etc/origin/master/master-config.yamlにあります) を適宜設定する必要があります。

設定ファイルなしでマスターを実行する場合は、Allow All アイデンティティープロバイダーがデフォルトで使用されます。このアイデンティティープロバイダーは、空でないユーザー名とパスワードによるログインをすべて許可します。これはテストを行う場合に便利です。その他のアイデンティティープロバイダーを使用するか、tokengrant、または session オプション を変更する場合は、設定ファイルからマスターを実行する必要があります。

注記

外部ユーザーのセットアップを管理するためのロールが割り当てられている必要があります。

注記

アイデンティティープロバイダーに変更を加えたら、変更を有効にするためにマスターサービスを再起動する必要があります。

# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers

12.2. アイデンティティープロバイダーパラメーター

すべてのアイデンティティープロバイダーには共通する 4 つのパラメーターがあります。

パラメーター説明

name

プロバイダー名は、プロバイダーのユーザー名にプレフィックスとして付加され、アイデンティティー名が作成されます。

challenge

true の場合、非 Web クライアント (CLI など) からの認証されていないトークン要求は、WWW-Authenticate チャレンジ ヘッダー付きで送信されます。 これはすべてのアイデンティティープロバイダーでサポートされる訳ではありません。

ブラウザークライアントに対するクロスサイトリクエストフォージェリー (CSRF) 攻撃を防止するため、基本的な認証チャレンジは X-CSRF-Token ヘッダーが要求に存在する場合にのみ送信されます。基本的な WWW-Authenticate challenge を受信する必要があるクライアントでは、このヘッダーを空でない値に設定する必要があります。

login

true の場合、Web クライアント (Web コンソールなど) からの認証されていないトークン要求は、このプロバイダーがサポートするログインページにリダイレクトされます。これはすべてのアイデンティティープロバイダーによってサポートされている訳ではありません。

ユーザーがアイデンティティープロバイダーのログインにリダイレクトされる前にブランドページに移動するようにする場合、マスター設定ファイルで oauthConfig → alwaysShowProviderSelection: true を設定します。このプロバイダー選択ページは カスタマイズできます。

mappingMethod

新規アイデンティティーがログイン時にユーザーにマップされる方法を定義します。以下の値のいずれかを入力します。

claim
デフォルトの値です。アイデンティティーの推奨ユーザー名を持つユーザーをプロビジョニングします。そのユーザー名を持つユーザーがすでに別のアイデンティティーにマッピングされている場合は失敗します。
lookup
既存のアイデンティティー、ユーザーアイデンティティーマッピング、およびユーザーを検索しますが、ユーザーまたはアイデンティティーの自動プロビジョニングは行いません。これにより、クラスター管理者は手動で、または外部のプロセスを使用してアイデンティティーとユーザーを設定できます。この方法を使用する場合は、ユーザーを手動でプロビジョニングする必要があります。「lookup マッピング方法を使用する場合のユーザーの手動プロビジョニング」を参照してください。
generate
アイデンティティーの推奨ユーザー名を持つユーザーをプロビジョニングします。推奨ユーザー名を持つユーザーがすでに既存のアイデンティティーにマッピングされている場合は、 myuser2 などの一意のユーザー名が生成されます。この方法は、OpenShift Container Platform のユーザー名とアイデンティティープロバイダーのユーザー名との正確な一致を必要とする外部プロセス (LDAP グループ同期など) と組み合わせて使用することはできません。
add
アイデンティティーの推奨ユーザー名を持つユーザーをプロビジョニングします。推奨ユーザー名を持つユーザーがすでに存在する場合、アイデンティティーは既存のユーザーにマッピングされ、そのユーザーの既存のアイデンティティーマッピングに追加されます。これは、同じユーザーセットを識別して同じユーザー名にマッピングするアイデンティティープロバイダーが複数設定されている場合に必要です。
注記

mappingMethod パラメーターを add に設定すると、アイデンティティープロバイダーの追加または変更時に新規プロバイダーのアイデンティティーを既存ユーザーにマッピングできます。

12.3. アイデンティティープロバイダーの設定

OpenShift Container Platform は単一のアイデンティティープロバイダーの設定のみをサポートします。ただし、LDAP フェイルオーバーなどのより複雑な設定の基本認証を拡張することが可能です。

これらのパラメーターを使用して、インストール時またはインストール後にアイデンティティープロバイダーを定義できます。

12.3.1. Ansible を使用したアイデンティティープロバイダーの設定

初回の 通常インストール (Advanced installation) では、Deny All アイデンティティープロバイダーがデフォルトで設定されます。ただし、これは、インベントリーファイルで設定可能な openshift_master_identity_providers パラメーターを使用してインストール時に上書きすることができます。OAuth 設定のセッションオプションもインベントリーファイルで設定できます。

例12.1 Ansible を使用したアイデンティティープロバイダー設定の例

# htpasswd auth
openshift_master_identity_providers=[{'name': 'htpasswd_auth', 'login': 'true', 'challenge': 'true', 'kind': 'HTPasswdPasswordIdentityProvider', 'filename': '/etc/origin/master/htpasswd'}]
# Defining htpasswd users
#openshift_master_htpasswd_users={'user1': '<pre-hashed password>', 'user2': '<pre-hashed password>'
# or
#openshift_master_htpasswd_file=<path to local pre-generated htpasswd file>

# Allow all auth
#openshift_master_identity_providers=[{'name': 'allow_all', 'login': 'true', 'challenge': 'true', 'kind': 'AllowAllPasswordIdentityProvider'}]

# LDAP auth
#openshift_master_identity_providers=[{'name': 'my_ldap_provider', 'challenge': 'true', 'login': 'true', 'kind': 'LDAPPasswordIdentityProvider', 'attributes': {'id': ['dn'], 'email': ['mail'], 'name': ['cn'], 'preferredUsername': ['uid']}, 'bindDN': '', 'bindPassword': '', 'ca': '', 'insecure': 'false', 'url': 'ldap://ldap.example.com:389/ou=users,dc=example,dc=com?uid'}]
# Configuring the ldap ca certificate 1
#openshift_master_ldap_ca=<ca text>
# or
#openshift_master_ldap_ca_file=<path to local ca file to use>

# Available variables for configuring certificates for other identity providers:
#openshift_master_openid_ca
#openshift_master_openid_ca_file
#openshift_master_request_header_ca
#openshift_master_request_header_ca_file
1
openshift_master_identity_providers パラメーターに CA 証明書の場所を指定する場合、証明書の値を openshift_master_ldap_ca パラメーターに指定したり、パスを openshift_master_ldap_ca_file パラメーターに使用したりしないようにしてください。

12.3.2. マスター設定ファイルでのアイデンティティープロバイダーの設定

マスター設定ファイルを変更することで、必要なアイデンティティープロバイダーを使用してマスターホストで認証を設定できます。

例12.2 マスター設定ファイルでのアイデンティティープロバイダーの設定例

...
oauthConfig:
  identityProviders:
  - name: htpasswd_auth
    challenge: true
    login: true
    mappingMethod: "claim"
...

デフォルトの claim 値に設定されている場合、アイデンティティーを以前に存在していたユーザー名にマッピングすると OAuth が失敗します。

12.3.3. アイデンティティープロバイダーまたはメソッドの設定

12.3.3.1. lookup マッピング方法を使用する場合のユーザーの手動プロビジョニング

lookup マッピング方法を使用する場合、ユーザープロビジョニングは外部システムによって API 経由で行われます。通常、アイデンティティーは、ログイン時にユーザーに自動的にマッピングされます。「 lookup」マッピング方法は、この自動マッピングを自動的に無効にします。そのため、ユーザーを手動でプロビジョニングする必要があります。

identity オブジェクトの詳細については、Identity ユーザー API オブジェクトを参照してください。

lookup マッピング方法を使用する場合は、アイデンティティープロバイダーを設定した後にユーザーごとに以下の手順を使用してください。

  1. OpenShift Container Platform ユーザーを作成します (まだ作成していない場合)。

    $ oc create user <username>

    たとえば、以下のコマンドを実行して OpenShift Container Platform ユーザー bob を作成します。

    $ oc create user bob
  2. OpenShift Container Platform アイデンティティーを作成します (まだ作成していない場合)。アイデンティティープロバイダーの名前と、アイデンティティープロバイダーの範囲でこのアイデンティティーを一意に表す名前を使用します。

    $ oc create identity <identity-provider>:<user-id-from-identity-provider>

    <identity-provider> は、マスター設定のアイデンティティープロバイダーの名前であり、以下の該当するアイデンティティープロバイダーセクションに表示されています。

    たとえば、以下のコマンドを実行すると、アイデンティティープロバイダーが ldap_provider、アイデンティティープロバイダーのユーザー名が bob_s のアイデンティティーが作成されます。

    $ oc create identity ldap_provider:bob_s
  3. 作成したユーザーとアイデンティティーのユーザー/アイデンティティーマッピングを作成します。

    $ oc create useridentitymapping <identity-provider>:<user-id-from-identity-provider> <username>

    たとえば、以下のコマンドを実行すると、アイデンティティーがユーザーにマッピングされます。

    $ oc create useridentitymapping ldap_provider:bob_s bob

12.3.4. Allow All

空でないユーザー名とパスワードによるログインを許可するには、 identityProviders スタンザに AllowAllPasswordIdentityProvider を設定します。

例12.3 AllowAllPasswordIdentityProvider を使用したマスター設定

oauthConfig:
  ...
  identityProviders:
  - name: my_allow_provider 1
    challenge: true 2
    login: true 3
    mappingMethod: claim 4
    provider:
      apiVersion: v1
      kind: AllowAllPasswordIdentityProvider
1
このプロバイダー名は、プロバイダーのユーザー名にプレフィックスとして付加され、アイデンティティー名が作成されます。
2
true の場合、非 Web クライアント (CLI など) からの認証されていないトークン要求は、このプロバイダーの WWW-Authenticate チャレンジヘッダーと共に送信されます。
3
true の場合、Web クライアント (Web コンソールなど) からの認証されていないトークン要求は、このプロバイダーがサポートするログインページにリダイレクトされます。
4
このプロバイダーのアイデンティティーとユーザーオブジェクト間のマッピングの確立方法を制御します (上記を参照してください)。

12.3.5. Deny All

すべてのユーザー名とパスワードについてアクセスを拒否するには、 identityProviders スタンザに DenyAllPasswordIdentityProvider を設定します。

例12.4 DenyAllPasswordIdentityProvider を使用したマスター設定

oauthConfig:
  ...
  identityProviders:
  - name: my_deny_provider 1
    challenge: true 2
    login: true 3
    mappingMethod: claim 4
    provider:
      apiVersion: v1
      kind: DenyAllPasswordIdentityProvider
1
このプロバイダー名は、プロバイダーのユーザー名にプレフィックスとして付加され、アイデンティティー名が作成されます。
2
true の場合、非 Web クライアント (CLI など) からの認証されていないトークン要求は、このプロバイダーの WWW-Authenticate チャレンジヘッダーと共に送信されます。
3
true の場合、Web クライアント (Web コンソールなど) からの認証されていないトークン要求は、このプロバイダーがサポートするログインページにリダイレクトされます。
4
このプロバイダーのアイデンティティーとユーザーオブジェクト間のマッピングの確立方法を制御します (上記を参照してください)。

12.3.6. HTPasswd

ユーザー名およびパスワードを htpasswd を使用して生成されたフラットファイルに対して検証するには、identityProviders スタンザに HTPasswdPasswordIdentityProvider を設定します。

注記

htpasswd ユーティリティーは httpd-tools パッケージにあります。

# yum install httpd-tools

OpenShift Container Platform では、 Bcrypt、SHA-1、および MD5 暗号化ハッシュ関数がサポートされ、MD5 は htpasswd のデフォルトです。プレーンテキスト、暗号化テキスト、およびその他のハッシュ関数は、現時点ではサポートされていません。

フラットファイルは、その変更時間が変わると再度読み取られます。サーバーの再起動は必要ありません。

htpasswd コマンドを使用するには、以下の手順を実行します。

  • ユーザー名とハッシュされたパスワードを含むフラットファイルを作成するには、以下を実行します。

    $ htpasswd -c </path/to/users.htpasswd> <user_name>

    次に、ユーザーのクリアテキストのパスワードを入力し、確認します。コマンドにより、ハッシュされたバージョンのパスワードが生成されます。

    例を以下に示します。

    htpasswd -c users.htpasswd user1
    New password:
    Re-type new password:
    Adding password for user user1
    注記

    -b オプションを追加すると、パスワードをコマンドラインに指定できます。

    $ htpasswd -c -b <user_name> <password>

    例を以下に示します。

    $ htpasswd -c -b file user1 MyPassword!
    Adding password for user user1
  • ファイルにログインを追加するか、ログインを更新するには、以下のコマンドを実行します。

    $ htpasswd </path/to/users.htpasswd> <user_name>
  • ファイルからログインを削除するには、以下のコマンドを実行します。

    $ htpasswd -D </path/to/users.htpasswd> <user_name>

例12.5 HTPasswdPasswordIdentityProvider を使用したマスター設定

oauthConfig:
  ...
  identityProviders:
  - name: my_htpasswd_provider 1
    challenge: true 2
    login: true 3
    mappingMethod: claim 4
    provider:
      apiVersion: v1
      kind: HTPasswdPasswordIdentityProvider
      file: /path/to/users.htpasswd 5
1
このプロバイダー名は、プロバイダーのユーザー名にプレフィックスとして付加され、アイデンティティー名が作成されます。
2
true の場合、非 Web クライアント (CLI など) からの認証されていないトークン要求は、このプロバイダーの WWW-Authenticate チャレンジヘッダーと共に送信されます。
3
true の場合、Web クライアント (Web コンソールなど) からの認証されていないトークン要求は、このプロバイダーがサポートするログインページにリダイレクトされます。
4
このプロバイダーのアイデンティティーとユーザーオブジェクト間のマッピングの確立方法を制御します (上記を参照してください)。
5
htpasswd を使用して生成されたファイルです。

12.3.7. Keystone

Keystone は、アイデンティティー、トークン、カタログ、およびポリシーサービスを提供する OpenStack プロジェクトです。OpenShift Container Platform クラスターと Keystone を統合すると、内部データベースにユーザーを格納するように設定された OpenStack Keystone v3 サーバーによる共有認証を有効にできます。この設定を完了すると、ユーザーは Keystone 認証情報を使用して OpenShift Container Platform にログインできるようになります。

12.3.7.1. マスターでの認証の設定

  1. 状況に応じて以下のいずれかの手順を実行します。

    • Openshift のインストールがすでに完了している場合は、/etc/origin/master/master-config.yaml ファイルを新規ディレクトリーにコピーします。以下は例になります。

      $ cd /etc/origin/master
      $ mkdir keystoneconfig; cp master-config.yaml keystoneconfig
    • OpenShift Container Platform をまだインストールしていない場合は、OpenShift Container Platform API サーバーを起動し、(将来の) OpenShift Container Platform マスターのホスト名と、起動コマンドによって作成された設定ファイルを格納するディレクトリーを指定します。

      $ openshift start master --public-master=<apiserver> --write-config=<directory>

      例を以下に示します。

      $ openshift start master --public-master=https://myapiserver.com:8443 --write-config=keystoneconfig
      注記

      Ansible を使用してインストールする場合は、identityProvider 設定を Ansible Playbook に追加する必要があります。Ansible を使用してインストールした後、以下の手順に従って設定を手動で変更した場合、インストールツールまたはアップグレードを再実行するたびに変更内容がすべて失われます。

  2. 新規の keystoneconfig/master-config.yaml ファイルの identityProviders スタンザを編集し、KeystonePasswordIdentityProvider の設定例をコピーして貼り付け、既存のスタンザを置き換えます。

    oauthConfig:
      ...
      identityProviders:
      - name: my_keystone_provider 1
        challenge: true 2
        login: true 3
        mappingMethod: claim 4
        provider:
          apiVersion: v1
          kind: KeystonePasswordIdentityProvider
          domainName: default 5
          url: http://keystone.example.com:5000 6
          ca: ca.pem 7
          certFile: keystone.pem 8
          keyFile: keystonekey.pem 9
    1
    このプロバイダー名は、プロバイダーのユーザー名にプレフィックスとして付加され、アイデンティティー名が作成されます。
    2
    true の場合、非 Web クライアント (CLI など) からの認証されていないトークン要求は、このプロバイダーの WWW-Authenticate チャレンジヘッダーと共に送信されます。
    3
    true の場合、Web クライアント (Web コンソールなど) からの認証されていないトークン要求は、このプロバイダーがサポートするログインページにリダイレクトされます。
    4
    このプロバイダーのアイデンティティーとユーザーオブジェクト間のマッピングの確立方法を制御します (上記を参照してください)。
    5
    Keystone のドメイン名です。Keystone では、ユーザー名はドメイン固有です。単一ドメインのみがサポートされます。
    6
    Keystone サーバーへの接続に使用する URL (必須) です。
    7
    オプション: 設定された URL のサーバー証明書を検証するために使用する証明書バンドルです。
    8
    オプション: 設定された URL に対して要求を実行する際に提示するクライアント証明書です。
    9
    クライアント証明書のキーです。certFile が指定されている場合は必須です。
  3. 以下の変更を identityProviders スタンザに加えます。

    1. プロバイダーの name (「my_keystone_provider」) を、使用する Keystone サーバーに合わせて変更します。この名前は、プロバイダーのユーザー名にプレフィックスとして付加され、アイデンティティー名が作成されます。
    2. 必要な場合、mappingMethod を変更して、プロバイダーのアイデンティティーとユーザーオブジェクト間でマッピングを確立する方法を制御します。
    3. domainName を OpenStack Keystone サーバーのドメイン名に変更します。Keystone では、ユーザー名はドメイン固有です。単一ドメインのみがサポートされます。
    4. OpenStack Keystone への接続に使用する url を指定します。
    5. オプションで、設定された URL のサーバー証明書を検証できるように ca を使用する証明書バンドルに変更します。
    6. オプションで、certFile を、設定された URL に対する要求の実行時に提示するクライアント証明書に変更します。
    7. certFile が指定されている場合は、keyFile をクライアント証明書のキーに変更する必要があります。
  4. 変更を保存してファイルを閉じます。
  5. OpenShift Container Platform API サーバーを起動し、変更したばかりの設定ファイルを指定します。

    $ openshift start master --config=<path/to/modified/config>/master-config.yaml

設定が完了すると、OpenShift Container Platform Web コンソールにログインするすべてのユーザーに Keystone 認証情報を使用してログインすることを求めるプロンプトが出されます。

12.3.7.2. Keystone 認証を使用するユーザーの作成

外部認証プロバイダー (この場合は Keystone) と統合する場合、OpenShift Container Platform にはユーザーを作成しません。Keystone は「system of record」であり、ユーザーは Keystone データベースで定義され、設定された認証サーバーに対する有効な Keystone ユーザー名を持つ任意のユーザーがログインできます。

ユーザーを OpenShift Container Platform に追加するには、そのユーザーが Keystone データベースに存在している必要があります。また、必要な場合はそのユーザーの新しい Keystone アカウントを作成する必要があります。

12.3.7.3. ユーザーの確認

1 名以上のユーザーがログインしたら、oc get users を実行してユーザーの一覧を表示し、ユーザーが正しく作成されていることを確認できます。

例12.6 oc get users コマンドの出力

$ oc get users
NAME         UID                                    FULL NAME   IDENTITIES
bobsmith     a0c1d95c-1cb5-11e6-a04a-002186a28631   Bob Smith   keystone:bobsmith 1
1
OpenShift Container Platform のアイデンティティーは、Keystone ユーザー名とそれにプレフィックスとして付加されるアイデンティティープロバイダー名で構成されます。

ここからは、ユーザーロールの管理方法を学習することをお勧めします。

12.3.8. LDAP 認証

単純なバインド認証を使用してユーザー名とパスワードを LDAPv3 サーバーに対して検証するには、identityProviders スタンザに LDAPPasswordIdentityProvider を設定します。

注記

これらの手順に従う代わりに LDAP サーバーのファイルオーバーを要求する場合には、LDAP フェイルオーバーに SSSD を設定して基本認証メソッドを拡張します。

認証時に、指定されたユーザー名に一致するエントリーが LDAP ディレクトリーで検索されます。単一の一意な一致が見つかった場合、エントリーの識別名 (DN) と指定されたパスワードを使用した単純なバインドが試みられます。

以下の手順が実行されます。

  1. 設定された url の属性およびフィルターとユーザーが指定したユーザー名を組み合わせて検索フィルターを生成します。
  2. 生成されたフィルターを使用してディレクトリーを検索します。検索によって 1 つもエントリーが返されない場合は、アクセスを拒否します。
  3. 検索で取得したエントリーの DN とユーザー指定のパスワードを使用して LDAP サーバーへのバインドを試みます。
  4. バインドが失敗した場合は、アクセスを拒否します。
  5. バインドが成功した場合は、アイデンティティー、電子メールアドレス、表示名、および推奨ユーザー名として設定された属性を使用してアイデンティティーを作成します。

設定される url は、LDAP ホストと使用する検索パラメーターを指定する RFC 2255 URL です。URL の構文は以下のようになります。

ldap://host:port/basedn?attribute?scope?filter

上記の例は、以下のコンポーネントで構成されています。

URL コンポーネント説明

ldap

通常の LDAP の場合は、文字列 ldap を使用します。セキュアな LDAP (LDAPS) の場合は、代わりに ldaps を使用します。

host:port

LDAP サーバーの名前とポートで。デフォルトは、ldap の場合は localhost:389、LDAPS の場合は localhost:636 です。

basedn

すべての検索が開始されるディレクトリーのブランチの DN です。これは少なくともディレクトリーツリーの最上位になければなりませんが、ディレクトリーのサブツリーを指定することもできます。

attribute

検索対象の属性です。RFC 2255 はカンマ区切りの属性の一覧を許可しますが、属性をどれだけ指定しても最初の属性のみが使用されます。属性を指定しない場合は、デフォルトで uid が使用されます。使用しているサブツリーのすべてのエントリー間で一意の属性を選択することを推奨します。

scope

検索の範囲です。one または sub のいずれかを指定できます。範囲を指定しない場合は、デフォルトの範囲として sub が使用されます。

filter

有効な LDAP 検索フィルターです。指定しない場合、デフォルトは (objectClass=*) です。

検索の実行時に属性、フィルター、指定したユーザー名が組み合わされて以下のような検索フィルターが作成されます。

(&(<filter>)(<attribute>=<username>))

たとえば、以下の URL について見てみましょう。

ldap://ldap.example.com/o=Acme?cn?sub?(enabled=true)

クライアントが bob というユーザー名を使用して接続を試みる場合、生成される検索フィルターは (&(enabled=true)(cn=bob)) になります。

LDAP ディレクトリーの検索に認証が必要な場合は、エントリー検索の実行に使用する bindDNbindPassword を指定します。

LDAPPasswordIdentityProvider を使用したマスターの設定

oauthConfig:
  ...
  identityProviders:
  - name: "my_ldap_provider" 1
    challenge: true 2
    login: true 3
    mappingMethod: claim 4
    provider:
      apiVersion: v1
      kind: LDAPPasswordIdentityProvider
      attributes:
        id: 5
        - dn
        email: 6
        - mail
        name: 7
        - cn
        preferredUsername: 8
        - uid
      bindDN: "" 9
      bindPassword: "" 10
      ca: my-ldap-ca-bundle.crt 11
      insecure: false 12
      url: "ldap://ldap.example.com/ou=users,dc=acme,dc=com?uid" 13

1
このプロバイダー名は返されるユーザー名にプレフィックスとして付加され、アイデンティティー名が作成されます。
2
true の場合、非 Web クライアント (CLI など) からの認証されていないトークン要求は、このプロバイダーの WWW-Authenticate チャレンジヘッダーと共に送信されます。
3
true の場合、Web クライアント (Web コンソールなど) からの認証されていないトークン要求は、このプロバイダーがサポートするログインページにリダイレクトされます。
4
このプロバイダーのアイデンティティーとユーザーオブジェクト間のマッピングの確立方法を制御します (上記を参照してください)。
5
アイデンティティーとして使用する属性の一覧です。最初の空でない属性が使用されます。少なくとも 1 つの属性が必要です。一覧表示される属性のいずれにも値がない場合、認証は失敗します。
6
メールアドレスとして使用する属性の一覧です。最初の空でない属性が使用されます。
7
表示名として使用する属性の一覧です。最初の空でない属性が使用されます。
8
このアイデンティティーのユーザーをプロビジョニングする際に推奨ユーザー名として使用する属性の一覧です。最初の空でない属性が使用されます。
9
検索フェーズでバインドするために使用するオプションの DN です。
10
検索フェーズでバインドするために使用するオプションのパスワードです。この値は、環境変数、外部ファイル、または暗号化ファイルで指定することもできます。
11
設定された URL のサーバー証明書を検証するために使用する証明書バンドルです。空の場合、システムで信頼されたルートが使用されます。これは insecure: false の場合にのみ適用されます。
12
true の場合、サーバーへの TLS 接続は確立されません。false の場合、ldaps:// URL は TLS を使用して接続し、ldap:// URL は TLS にアップグレードされます。
13
LDAP ホストと使用する検索パラメーターを指定する RFC 2255 URL です (上記を参照してください)。
注記

LDAP 統合のためのユーザーのホワイトリストを作成するには、lookup マッピング方法を使用します。LDAP からのログインが許可される前に、クラスター管理者は各 LDAP ユーザーのアイデンティティーとユーザーオブジェクトを作成する必要があります。

12.3.9. Basic 認証 (リモート)

Basic 認証は、ユーザーがリモートのアイデンティティープロバイダーに対して検証した認証情報を使用して OpenShift Container Platform にログインすることを可能にする汎用バックエンド統合メカニズムです。

Basic 認証は汎用性があるため、このアイデンティティープロバイダー使用して詳細な認証設定を実行できます。詳細なリモート Basic 認証設定の開始点として、LDAP フェイルオーバーを設定したり、コンテナー化された Basic 認証リポジトリーを使用できます。

注意

Basic 認証では、ユーザー ID とパスワードのスヌーピングを防ぎ、中間者攻撃を回避するためにリモートサーバーへの HTTPS 接続を使用する必要があります。

BasicAuthPasswordIdentityProvider を設定していると、ユーザーはユーザー名とパスワードを OpenShift Container Platform に送信し、サーバー間の要求を行い、認証情報を基本認証ヘッダーとして渡すことで、これらの認証情報をリモートサーバーに対して検証することができます。このため、ユーザーはログイン時に認証情報を OpenShift Container Platform に送信する必要があります。

注記

これはユーザー名/パスワードログインの仕組みにのみ有効で、OpenShift Container Platform はリモート認証サーバーに対するネットワーク要求を実行できる必要があります。

identityProviders スタンザで BasicAuthPasswordIdentityProvider を設定し、サーバー間の基本認証要求を使用してユーザー名とパスワードをリモートサーバーに対して検証できるようにします。ユーザー名とパスワードは基本認証で保護されるリモート URL に対して検証され、JSON を返します。

401 応答は認証の失敗を示しています。

200 以外のステータスまたは空でない「エラー」キーはエラーを示しています。

{"error":"Error message"}

sub (サブジェクト) キーを持つ 200 ステータスは、成功を示しています。

{"sub":"userid"} 1
1
このサブジェクトは認証ユーザーに固有である必要があり、変更することができません。

正常な応答により、以下のような追加データがオプションで提供されることがあります。

  • name キーを使用した表示名。以下は例になります。

    {"sub":"userid", "name": "User Name", ...}
  • email キーを使用したメールアドレス。以下は例になります。

    {"sub":"userid", "email":"user@example.com", ...}
  • preferred_username キーを使用した推奨ユーザー名。これは、固有の変更できないサブジェクトがデータベースキーまたは UID であり、判読可能な名前が存在する場合に便利です。これは、認証された ID に対して OpenShift Container Platform ユーザーをプロビジョニングする場合にヒントとして使われます。以下は例を示しています。

    {"sub":"014fbff9a07c", "preferred_username":"bob", ...}

12.3.9.1. マスターでの認証の設定

  1. 状況に応じて以下のいずれかの手順を実行します。

    • Openshift のインストールがすでに完了している場合は、/etc/origin/master/master-config.yaml ファイルを新規ディレクトリーにコピーします。以下は例になります。

      $ mkdir basicauthconfig; cp master-config.yaml basicauthconfig
    • OpenShift Container Platform をまだインストールしていない場合は、OpenShift Container Platform API サーバーを起動し、(将来の) OpenShift Container Platform マスターのホスト名と、起動コマンドによって作成された設定ファイルを格納するディレクトリーを指定します。

      $ openshift start master --public-master=<apiserver> --write-config=<directory>

      例を以下に示します。

      $ openshift start master --public-master=https://myapiserver.com:8443 --write-config=basicauthconfig
      注記

      Ansible を使用してインストールする場合は、identityProvider 設定を Ansible Playbook に追加する必要があります。Ansible を使用してインストールした後、以下の手順に従って設定を手動で変更した場合、インストールツールまたはアップグレードを再実行するたびに変更内容がすべて失われます。

  2. 新規の master-config.yaml ファイルの identityProviders スタンザを編集し、BasicAuthPasswordIdentityProvider 設定のサンプルをコピーして貼り付け、既存のスタンザを置き換えます。

    oauthConfig:
      ...
      identityProviders:
      - name: my_remote_basic_auth_provider 1
        challenge: true 2
        login: true 3
        mappingMethod: claim 4
        provider:
          apiVersion: v1
          kind: BasicAuthPasswordIdentityProvider
          url: https://www.example.com/remote-idp 5
          ca: /path/to/ca.file 6
          certFile: /path/to/client.crt 7
          keyFile: /path/to/client.key 8
    1
    このプロバイダー名は返されるユーザー名にプレフィックスとして付加され、アイデンティティー名が作成されます。
    2
    true の場合、非 Web クライアント (CLI など) からの認証されていないトークン要求は、このプロバイダーの WWW-Authenticate チャレンジヘッダーと共に送信されます。
    3
    true の場合、Web クライアント (Web コンソールなど) からの認証されていないトークン要求は、このプロバイダーがサポートするログインページにリダイレクトされます。
    4
    このプロバイダーのアイデンティティーとユーザーオブジェクト間のマッピングの確立方法を制御します (上記を参照してください)。
    5
    Basic 認証ヘッダーで認証情報を受け入れる URL。
    6
    オプション: 設定された URL のサーバー証明書を検証するために使用する証明書バンドルです。
    7
    オプション: 設定された URL に対して要求を実行する際に提示するクライアント証明書です。
    8
    クライアント証明書のキーです。certFile が指定されている場合は必須です。

    以下の変更を identityProviders スタンザに加えます。

    1. プロバイダーの name をデプロイメントに対して固有で関連するものに設定します。この名前は返されるユーザー ID にプレフィックスとして付加され、アイデンティティー名が作成されます。
    2. 必要な場合、mappingMethod を設定して、プロバイダーのアイデンティティーとユーザーオブジェクト間でマッピングを確立する方法を制御します。
    3. Basic 認証ヘッダーで認証情報を受け入れるサーバーへの接続に使用する HTTPS url を指定します。
    4. オプションで、設定された URL のサーバー証明書を検証するために ca を使用する証明書バンドルに設定するか、またはこれを空にしてシステムで信頼されるルートを使用します。
    5. オプションで、certFile を削除するか、またはこれを設定された URL へ要求を行う時に提示するクライアント証明書に設定します。
    6. certFile を指定する場合、keyFile をクライアント証明書のキーに設定する必要があります。
  3. 変更を保存してファイルを閉じます。
  4. OpenShift Container Platform API サーバーを起動し、変更したばかりの設定ファイルを指定します。

    $ openshift start master --config=<path/to/modified/config>/master-config.yaml

これが設定されると、OpenShift Container Platform Web コンソールにログインするユーザーには、Basic 認証の認証情報を使用してログインすることを求めるプロンプトが表示されます。

12.3.9.2. トラブルシューティング

最もよく起こる問題は、バックエンドサーバーへのネットワーク接続に関連しています。簡単なデバッグの場合は、マスターで curl コマンドを実行します。正常なログインをテストするには、以下のコマンド例の <user><password> を有効な認証情報に置き換えます。無効なログインをテストするには、それらを正しくない認証情報に置き換えます。

curl --cacert /path/to/ca.crt --cert /path/to/client.crt --key /path/to/client.key -u <user>:<password> -v https://www.example.com/remote-idp

正常な応答

sub (サブジェクト) キーを持つ 200 ステータスは、成功を示しています。

{"sub":"userid"}

サブジェクトは認証ユーザーに固有である必要があり、変更することはできません。

正常な応答により、以下のような追加データがオプションで提供されることがあります。

  • name キーを使用した表示名:

    {"sub":"userid", "name": "User Name", ...}
  • email キーを使用したメールアドレス:

    {"sub":"userid", "email":"user@example.com", ...}
  • preferred_username キーを使用した推奨ユーザー名:

    {"sub":"014fbff9a07c", "preferred_username":"bob", ...}

    preferred_username キーは、固有の変更できないサブジェクトがデータベースキーまたは UID であり、判読可能な名前が存在する場合に便利です。これは、認証 ID に対して OpenShift Container Platform ユーザーをプロビジョニングする場合にヒントとして使われます。

失敗の応答

  • 401 応答は認証の失敗を示しています。
  • 200 以外のステータスまたは空でない「エラー」キーはエラーを示しています: {"error":"Error message"}

12.3.10. 要求ヘッダー

identityProviders スタンザで RequestHeaderIdentityProvider を設定して、X-Remote-User などの要求ヘッダー値からユーザーを識別します。これは通常、プロキシー認証と組み合わせて使用され、要求ヘッダー値を設定します。これは OpenShift Enterprise 2 のリモートユーザープラグイン によって管理者が Kerberos、LDAP、その他の数多くの形式のエンタープライズ認証を指定する方法と似ています。

さらに、SAML 認証などの詳細な設定に要求ヘッダーアイデンティティープロバイダーを使用できます。

ユーザーがこのアイデンティティープロバイダーを使用して認証を行うには、認証プロキシー経由で https://<master>/oauth/authorize (およびサブパス) にアクセスする必要があります。これを実行するには、OAuth トークンに対する非認証の要求を https://<master>/oauth/authorize にプロキシー処理するプロキシーエンドポイントにリダイレクトするよう OAuth サーバーを設定します。

ブラウザーベースのログインフローが想定されるクライアントからの非認証要求をリダイレクトするには、以下を実行します。

  1. login パラメーターを true に設定します。
  2. provider.loginURL パラメーターをインタラクティブなクライアントを認証する認証プロキシー URL に設定してから、要求を https://<master>/oauth/authorize にプロキシーします。

WWW-Authenticate チャレンジが想定されるクライアントからの非認証要求をリダイレクトするには、以下を実行します。

  1. challenge パラメーターを true に設定します。
  2. provider.challengeURL パラメーターを WWW-Authenticate チャレンジが想定されるクライアントを認証する認証プロキシー URL に設定し、要求を https://<master>/oauth/authorize にプロキシーします。

provider.challengeURL および provider.loginURL パラメーターには、URL のクエリー部分に以下のトークンを含めることができます。

  • ${url} は現在の URL と置き換えられ、エスケープされてクエリーパラメーターで保護されます。

    例: https://www.example.com/sso-login?then=${url}

  • ${query} は最新のクエリー文字列と置き換えられ、エスケープされません。

    例: https://www.example.com/auth-proxy/oauth/authorize?${query}

警告

非認証要求が OAuth サーバーに到達することを想定する場合は、要求ヘッダーのユーザー名がチェックされる前に受信要求の有効なクライアント証明書をチェックするように、clientCA パラメーターをこのアイデンティティープロバイダーに対して設定する必要があります。これを設定しない場合、OAuth サーバーへの直接的な要求は、要求ヘッダーを設定するだけでこのプロバイダーのアイデンティティーになりすます可能性があります。

例12.7 RequestHeaderIdentityProvider を使用したマスター設定

oauthConfig:
  ...
  identityProviders:
  - name: my_request_header_provider 1
    challenge: true 2
    login: true 3
    mappingMethod: claim 4
    provider:
      apiVersion: v1
      kind: RequestHeaderIdentityProvider
      challengeURL: "https://www.example.com/challenging-proxy/oauth/authorize?${query}" 5
      loginURL: "https://www.example.com/login-proxy/oauth/authorize?${query}" 6
      clientCA: /path/to/client-ca.file 7
      clientCommonNames: 8
      - my-auth-proxy
      headers: 9
      - X-Remote-User
      - SSO-User
      emailHeaders: 10
      - X-Remote-User-Email
      nameHeaders: 11
      - X-Remote-User-Display-Name
      preferredUsernameHeaders: 12
      - X-Remote-User-Login
1
このプロバイダー名は要求ヘッダーのユーザー名にプレフィックスとして付加され、アイデンティティー名が作成されます。
2
RequestHeaderIdentityProvider は、設定された challengeURL にリダイレクトすることで、WWW-Authenticate チャレンジを要求するクライアントにのみ応答します。設定される URL は WWW-Authenticate チャレンジを使用して応答します。
3
RequestHeaderIdentityProvider は、設定された loginURL にリダイレクトすることで、ログインフローを要求するクライアントにのみ応答できます。設定される URL はログインフローを使用して応答します。
4
このプロバイダーのアイデンティティーとユーザーオブジェクト間のマッピングの確立方法を制御します (上記を参照してください)。
5
オプション: 非認証の /oauth/authorize 要求のリダイレクト先となる URLです。これは、ブラウザーベースのクライアントを認証し、その要求を https://<master>/oauth/authorize にプロキシーします。https://<master>/oauth/authorize にプロキシーする URL は /authorize で終了し (末尾のスラッシュなし)、OAuth 承認フローが適切に機能するようサブパスもプロキシーします。${url} は現在の URL に置き換えられ、エスケープされてクエリーパラメーターで保護されます。${query} は現在のクエリー文字列に置き換えられます。
6
オプション: 非認証の /oauth/authorize 要求のリダイレクト先となる URL です。WWW-Authenticate チャレンジが想定されるクライアントを認証し、それらを https://<master>/oauth/authorize にプロキシーします。${url} は現在の URL に置き換えられ、エスケープされてクエリーパラメーターで保護されます。${query} は現在のクエリー文字列に置き換えられます。
7
オプション: PEM でエンコードされた証明書バンドルです。これが設定されている場合、要求ヘッダーのユーザー名をチェックする前に、有効なクライアント証明書が提示され、指定ファイルで認証局に対して検証される必要があります。
8
オプション: 共通名 (cn) の一覧です。これが設定されている場合は、要求ヘッダーのユーザー名をチェックする前に指定される一覧の Common Name (cn) を持つ有効なクライアント証明書が提示される必要があります。空の場合、すべての Common Name が許可されます。これは clientCA との組み合わせる場合にのみ使用できます。
9
ユーザーアイデンティティーを順番にチェックする際に使用するヘッダー名です。値を含む最初のヘッダーはアイデンティティーとして使用されます。これは必須であり、大文字小文字を区別します。
10
メールアドレスを順番にチェックする際に使用するヘッダー名です。値を含む最初のヘッダーはメールアドレスとして使用されます。これは任意であり、大文字小文字を区別します。
11
表示名を順番にチェックする際に使用するヘッダー名です。値を含む最初のヘッダーは表示名として使用されます。これは任意であり、大文字小文字を区別します。
12
推奨ユーザー名を順番にチェックする際に使用するヘッダー名です ( headers で指定されるヘッダーで決定される変更できないアイデンティティーと異なる場合)。値を含む最初のヘッダーは、プロビジョニング時に推奨ユーザー名として使用されます。これは任意であり、大文字小文字を区別します。

例12.8 RequestHeaderIdentityProvider を使用した Apache 認証

この例は、マスターと同じホストに認証プロキシーを設定しています。同じホストにプロキシーとマスターがあると便利ですが、ご使用中の環境に適さない場合があります。たとえば、すでにマスターでルーターを実行している場合、ポート 443 が利用できなくなります。

この参照設定は Apache の mod_auth_form を使用していますが、これは決して必須ではなく、以下の要件を満たしていれば他のプロキシーを簡単に使用することができます。

  1. クライアント要求の X-Remote-User ヘッダーをブロックして、スプーフィングを防ぎます。
  2. RequestHeaderIdentityProvider 設定でクライアント証明書認証を実施します。
  3. チャレンジフローを使用してすべての認証要求についての X-Csrf-Token ヘッダーを設定する必要があります。
  4. /oauth/authorize エンドポイントとそのサブパスのみがプロキシーされる必要があります。バックエンドサーバーがクライアントを正しい場所へ送信できるようリダイレクトは書き換えないでください。
  5. https://<master>/oauth/authorize へプロキシーする URL は /authorize で終了 (末尾のスラッシュなし) する必要があります。以下は例になります。

    • https://proxy.example.com/login-proxy/authorize?…​https://<master>/oauth/authorize?…​
  6. https://<master>/oauth/authorize にプロキシーされる URL のサブパスは、https://<master>/oauth/authorize のサブパスにプロキシーする必要があります。以下は例になります。

    • https://proxy.example.com/login-proxy/authorize/approve?…​https://<master>/oauth/authorize/approve?…​

前提条件のインストール

mod_auth_form モジュールは Optional チャンネル にある mod_session パッケージの一部として同梱されます。

# yum install -y httpd mod_ssl mod_session apr-util-openssl

信頼されたヘッダーを送信する要求を検証するために CA を生成します。この CA は マスターのアイデンティティープロバイダーの設定clientCA のファイル名として使用されます。

# oc adm ca create-signer-cert \
  --cert='/etc/origin/master/proxyca.crt' \
  --key='/etc/origin/master/proxyca.key' \
  --name='openshift-proxy-signer@1432232228' \
  --serial='/etc/origin/master/proxyca.serial.txt'

oc adm ca create-signer-cert コマンドは、5 年間有効な証明書を生成します。この期間は --expire-days オプションを使って変更することができますが、セキュリティー上の理由から、値をこれ以上大きくすることは推奨されません。

Ansible ホストインベントリーファイル (デフォルトで /etc/ansible/hosts) に最初に一覧表示されているマスターから oc adm コマンドを実行します。

このプロキシー用のクライアント証明書を生成します。x509 証明書ツーリングを使用して実行することができます。oc adm CLI を使用すると便利です。

# oc adm create-api-client-config \
  --certificate-authority='/etc/origin/master/proxyca.crt' \
  --client-dir='/etc/origin/master/proxy' \
  --signer-cert='/etc/origin/master/proxyca.crt' \
  --signer-key='/etc/origin/master/proxyca.key' \
  --signer-serial='/etc/origin/master/proxyca.serial.txt' \
  --user='system:proxy' 1

# pushd /etc/origin/master
# cp master.server.crt /etc/pki/tls/certs/localhost.crt 2
# cp master.server.key /etc/pki/tls/private/localhost.key
# cp ca.crt /etc/pki/CA/certs/ca.crt
# cat proxy/system\:proxy.crt \
  proxy/system\:proxy.key > \
  /etc/pki/tls/certs/authproxy.pem
# popd
1
ユーザー名は任意に指定できますが、ログにそのまま表示されるのでわかりやすい名前をつけると便利です。
2
マスターと異なるホスト名で認証プロキシーを実行する場合、上記のようにデフォルトのマスター証明書を使用するのではなく、ホスト名と一致する証明書を生成することが重要です。/etc/origin/master/master-config.yaml ファイルの masterPublicURL の値は、SSLCertificateFile に対して指定される証明書の X509v3 Subject Alternative Name に含まれる必要があります。新規の証明書を作成する必要がある場合は、oc adm ca create-server-cert コマンドを使用できます。

oc adm create-api-client-config コマンドは、2 年間有効な証明書を生成します。この期間は --expire-days オプションを使って変更することができますが、セキュリティー上の理由から、値をこれ以上大きくすることは推奨されません。Ansible ホストインベントリーファイル (デフォルトは /etc/ansible/hosts) に一覧表示される 1 つ目のマスターからのみ oc adm コマンドを実行します。

Apache の設定

このプロキシーはマスターと同じホストにある必要はありません。これはクライアント証明書を使用してマスターに接続し、X-Remote-User ヘッダーを信頼するように設定されます。

  1. Apache 設定の証明書を作成します。SSLProxyMachineCertificateFile パラメーターの値として指定する証明書は、プロキシーをサーバーに対して認証するために使用されるプロキシーのクライアント証明書です。これは、拡張されたキーのタイプとして TLS Web Client Authentication を使用する必要があります。
  2. 以下のそれぞれに対して Apache を設定します。
LoadModule auth_form_module modules/mod_auth_form.so
LoadModule session_module modules/mod_session.so
LoadModule request_module modules/mod_request.so

# Nothing needs to be served over HTTP.  This virtual host simply redirects to
# HTTPS.
<VirtualHost *:80>
  DocumentRoot /var/www/html
  RewriteEngine              On
  RewriteRule     ^(.*)$     https://%{HTTP_HOST}$1 [R,L]
</VirtualHost>

<VirtualHost *:443>
  # This needs to match the certificates you generated.  See the CN and X509v3
  # Subject Alternative Name in the output of:
  # openssl x509 -text -in /etc/pki/tls/certs/localhost.crt
  ServerName www.example.com

  DocumentRoot /var/www/html
  SSLEngine on
  SSLCertificateFile /etc/pki/tls/certs/localhost.crt
  SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
  SSLCACertificateFile /etc/pki/CA/certs/ca.crt

  SSLProxyEngine on
  SSLProxyCACertificateFile /etc/pki/CA/certs/ca.crt
  # It's critical to enforce client certificates on the Master.  Otherwise
  # requests could spoof the X-Remote-User header by accessing the Master's
  # /oauth/authorize endpoint directly.
  SSLProxyMachineCertificateFile /etc/pki/tls/certs/authproxy.pem

  # Send all requests to the console
  RewriteEngine              On
  RewriteRule     ^/console(.*)$     https://%{HTTP_HOST}:8443/console$1 [R,L]

  # In order to using the challenging-proxy an X-Csrf-Token must be present.
  RewriteCond %{REQUEST_URI} ^/challenging-proxy
  RewriteCond %{HTTP:X-Csrf-Token} ^$ [NC]
  RewriteRule ^.* - [F,L]

  <Location /challenging-proxy/oauth/authorize>
    # Insert your backend server name/ip here.
    ProxyPass https://[MASTER]:8443/oauth/authorize
    AuthType basic
  </Location>

  <Location /login-proxy/oauth/authorize>
    # Insert your backend server name/ip here.
    ProxyPass https://[MASTER]:8443/oauth/authorize

    # mod_auth_form providers are implemented by mod_authn_dbm, mod_authn_file,
    # mod_authn_dbd, mod_authnz_ldap and mod_authn_socache.
    AuthFormProvider file
    AuthType form
    AuthName openshift
    ErrorDocument 401 /login.html
  </Location>

  <ProxyMatch /oauth/authorize>
    AuthUserFile /etc/origin/master/htpasswd
    AuthName openshift
    Require valid-user
    RequestHeader set X-Remote-User %{REMOTE_USER}s env=REMOTE_USER

    # For ldap:
    # AuthBasicProvider ldap
    # AuthLDAPURL "ldap://ldap.example.com:389/ou=People,dc=my-domain,dc=com?uid?sub?(objectClass=*)"

    # It's possible to remove the mod_auth_form usage and replace it with
    # something like mod_auth_kerb, mod_auth_gssapi or even mod_auth_mellon.
    # The former would be able to support both the login and challenge flows
    # from the Master.  Mellon would likely only support the login flow.

    # For Kerberos
    # yum install mod_auth_gssapi
    # AuthType GSSAPI
    # GssapiCredStore keytab:/etc/httpd.keytab
  </ProxyMatch>

</VirtualHost>

RequestHeader unset X-Remote-User

その他の mod_auth_form 要件

サンプルログインページは、openshift_extras リポジトリーから利用できます。このファイルは DocumentRoot (デフォルトでは /var/www/html) に配置する必要があります。

ユーザーの作成

ここで、Apache がアカウント情報を保存するために使用しているシステムでユーザーを作成することができます。たとえば、ファイルベース (file-backed) 認証が使用されます。

# yum -y install httpd-tools
# touch /etc/origin/master/htpasswd
# htpasswd /etc/origin/master/htpasswd <user_name>

マスターの設定

/etc/origin/master/master-config.yaml ファイルの identityProviders スタンザも更新する必要があります。

  identityProviders:
  - name: requestheader
    challenge: true
    login: true
    provider:
      apiVersion: v1
      kind: RequestHeaderIdentityProvider
      challengeURL: "https://[MASTER]/challenging-proxy/oauth/authorize?${query}"
      loginURL: "https://[MASTER]/login-proxy/oauth/authorize?${query}"
      clientCA: /etc/origin/master/proxyca.crt
      headers:
      - X-Remote-User

サービスの再起動

最後に、以下のサービスを再起動します。

# systemctl restart httpd
# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers

設定の検証

  1. プロキシーをバイパスしてテストします。正しいクライアント証明書とヘッダーを指定すれば、トークンを要求できます。

    # curl -L -k -H "X-Remote-User: joe" \
       --cert /etc/pki/tls/certs/authproxy.pem \
       https://[MASTER]:8443/oauth/token/request
  2. クライアント証明書を指定しない場合、要求は拒否されます。

    # curl -L -k -H "X-Remote-User: joe" \
       https://[MASTER]:8443/oauth/token/request
  3. これは、設定された challengeURL (追加のクエリーパラメーターを含む) へのリダイレクトを示します。

    # curl -k -v -H 'X-Csrf-Token: 1' \
       '<masterPublicURL>/oauth/authorize?client_id=openshift-challenging-client&response_type=token'
  4. これは、WWW-Authenticate 基本チャレンジの 401 応答を示します。

    #  curl -k -v -H 'X-Csrf-Token: 1' \
        '<redirected challengeURL from step 3 +query>'
  5. これはアクセストークンを使用するリダイレクトを示します。

    #  curl -k -v -u <your_user>:<your_password> \
        -H 'X-Csrf-Token: 1' '<redirected_challengeURL_from_step_3 +query>'

12.3.11. GitHub

GitHub は OAuth を使用します。OpenShift Container Platform クラスターを統合して OAuth 認証を使用できます。OAuth は基本的にトークンの交換フローを促進します。

GitHub 認証を設定することによって、ユーザーは GitHub 認証情報を使用して OpenShift Container Platform にログインできます。GitHub ユーザー ID を持つすべてのユーザーが OpenShift Container Platform クラスターにログインできないようにするために、アクセスを特定の GitHub 組織のユーザーに制限することができます。

12.3.11.1. GitHub でのアプリケーションの登録

  1. GitHub で SettingsOAuth applicationsDeveloper applicationsRegister an application を順番にクリックし、new OAuth application のページに移動します。
  2. アプリケーション名を入力します。例: My OpenShift Install
  3. ホームページの URL を入力します。例: https://myapiserver.com:8443
  4. オプションで、アプリケーションの説明を入力します。
  5. 承認コールバック URL を入力します。ここで、URL の末尾にはアイデンティティープロバイダーの 名前 (マスター設定ファイルidentityProviders スタンザで定義されます。このトピックの以下のセクションで設定を行います) が含まれます。

    <apiserver>/oauth2callback/<identityProviderName>

    例を以下に示します。

    https://myapiserver.com:8443/oauth2callback/github/
  6. Register application をクリックします。GitHub はクライアント ID とクライアントシークレットを提供します。このウィンドウを開いたままにして、それらの値をコピーし、マスター設定ファイルに貼り付けます。

12.3.11.2. マスターでの認証の設定

  1. 状況に応じて以下のいずれかの手順を実行します。

    • Openshift のインストールがすでに完了している場合は、/etc/origin/master/master-config.yaml ファイルを新規ディレクトリーにコピーします。以下は例になります。

      $ cd /etc/origin/master
      $ mkdir githubconfig; cp master-config.yaml githubconfig
    • OpenShift Container Platform をまだインストールしていない場合は、OpenShift Container Platform API サーバーを起動し、(将来の) OpenShift Container Platform マスターのホスト名と、起動コマンドによって作成された設定ファイルを格納するディレクトリーを指定します。

      $ openshift start master --public-master=<apiserver> --write-config=<directory>

      例を以下に示します。

      $ openshift start master --public-master=https://myapiserver.com:8443 --write-config=githubconfig
      注記

      Ansible を使用してインストールする場合は、identityProvider 設定を Ansible Playbook に追加する必要があります。Ansible を使用してインストールした後、以下の手順に従って設定を手動で変更した場合、インストールツールまたはアップグレードを再実行するたびに変更内容がすべて失われます。

      注記

      openshift start master を使用するとホスト名が自動的に検出されますが、GitHub はアプリケーション登録時に指定した正確なホスト名にリダイレクトできる必要があります。このため、ID は間違ったアドレスにリダイレクトする可能性があるために自動検出することはできません。代わりに、Web ブラウザーが OpenShift Container Platform クラスターとの対話に使用するホスト名を指定する必要があります。

  2. 新規 master-config.yaml ファイルの identityProviders スタンザを編集し、GitHubIdentityProvider 設定例をコピーして貼り付け、既存のスタンザを置き換えます。

    oauthConfig:
      ...
      identityProviders:
      - name: github 1
        challenge: false 2
        login: true 3
        mappingMethod: claim 4
        provider:
          apiVersion: v1
          kind: GitHubIdentityProvider
          clientID: ... 5
          clientSecret: ... 6
          organizations: 7
          - myorganization1
          - myorganization2
          teams: 8
          - myorganization1/team-a
          - myorganization2/team-b
    1
    このプロバイダー名は GitHub の数字ユーザー ID にプレフィックスとして付加され、アイデンティティー名が作成されます。これはコールバック URL を作成するためにも使用されます。
    2
    GitHubIdentityProvider を使用してWWW-Authenticate チャレンジを送信することはできません。
    3
    true の場合、(Web コンソールの場合のように) Web クライアントからの非認証トークン要求はログインする GitHub にリダイレクトされます。
    4
    このプロバイダーのアイデンティティーとユーザーオブジェクト間のマッピングの確立方法を制御します (上記を参照してください)。
    5
    登録済みの GitHub OAuth アプリケーション のクライアント ID です。アプリケーションは、<master>/oauth2callback/<identityProviderName> のコールバック URL を使用して設定する必要があります。
    6
    GitHub で発行されるクライアントシークレットです。この値は環境変数、外部ファイル、または暗号化されたファイルでも指定できます。
    7
    組織のオプションの一覧です。これが指定されている場合、少なくとも一覧のいずれかの組織のメンバーである GitHub ユーザーのみがログインできます。その組織が clientID で設定された GitHub OAuth アプリケーションを所有していない場合、組織の所有者はこのオプションを使用するためにサードパーティーのアクセスを付与する必要があります。これは組織の管理者が初回の GitHub ログイン時に、または GitHub の組織設定で実行できます。これは teams フィールドと組み合わせて使用することはできません。
    8
    チームのオプションの一覧です。これが指定されている場合、少なくとも一覧のいずれかのチームのメンバーである GitHub ユーザーのみがログインできます。そのチームの組織が clientID で設定された GitHub OAuth アプリケーションを所有していない場合、組織の所有者はこのオプションを使用するためにサードパーティーのアクセスを付与する必要があります。これは組織の管理者が初回の GitHub ログイン時に、または GitHub の組織設定から実行できます。これは organizations フィールドと組み合わせて使用することはできません。
  3. 以下の変更を identityProviders スタンザに加えます。

    1. プロバイダーの name を変更して、GitHub で設定したコールバック URL に一致させます。

      たとえば、コールバック URL を https://myapiserver.com:8443/oauth2callback/github/ として定義した場合、namegithub にする必要があります。

    2. clientID以前に登録した GitHub のクライアント ID に変更します。
    3. clientSecret以前に登録した GitHub のクライアントシークレットに変更します。
    4. organizations または teams を変更して、ユーザーが認証を行うためにメンバーシップを設定している必要がある 1 つ以上の GitHub 組織またはチームの一覧を組み込むようにします。これが指定されている場合、少なくとも一覧のいずれかの組織またはチームのメンバーである GitHub ユーザーのみがログインできます。これが指定されていない場合、有効な GitHub アカウントを持つすべてのユーザーがログインできます。
  4. 変更を保存してファイルを閉じます。
  5. OpenShift Container Platform API サーバーを起動し、変更したばかりの設定ファイルを指定します。

    $ openshift start master --config=<path/to/modified/config>/master-config.yaml

これが設定されると、OpenShift Container Platform の Web コンソールにログインするユーザーには GitHub の認証情報を使用してログインすることを求めるプロンプトが出されます。初回ログイン時に、ユーザーは authorize application をクリックして GitHub が OpenShift Container Platform でのユーザー名、パスワードおよび組織のメンバーシップを使用することを許可する必要があります。その後、ユーザーは Web コンソールにリダイレクトされます。

12.3.11.3. GitHub 認証を持つユーザーの作成

GitHub などの外部認証プロバイダーを統合する場合は、ユーザーを OpenShift Container Platform では作成しません。GitHub は「system of record」であり、ユーザーは GitHub で定義され、指定される組織に属するすべてのユーザーがログインできることになります。

ユーザーを OpenShift Container Platform に追加するには、そのユーザーを GitHub で承認された組織に追加する必要があり、必要な場合は、そのユーザーの新しい GitHub アカウントを作成します。

12.3.11.4. ユーザーの確認

1 名以上のユーザーがログインしたら、oc get users を実行してユーザーの一覧を表示し、ユーザーが正しく作成されていることを確認できます。

例12.9 oc get users コマンドの出力

$ oc get users
NAME         UID                                    FULL NAME   IDENTITIES
bobsmith     433b5641-066f-11e6-a6d8-acfc32c1ca87   Bob Smith   github:873654 1
1
OpenShift Container Platform のアイデンティティーは、アイデンティティープロバイダー名と GitHub の内部の数字のユーザー ID で構成されます。そのため、ユーザーが GitHub のユーザー名またはメールアドレスを変更した場合でも、GitHub アカウントに割り当てられる認証情報に依存せず、OpenShift Container Platform にログインできます。これにより安定したログインが作成されます。

ここからは、ユーザーロールを制御する方法を学習することをお勧めします。

12.3.12. GitLab

OAuth 統合 を使用して、identityProviders スタンザで GitLabIdentityProvider を設定し、GitLab.com またはその他の GitLab インスタンスをアイデンティティープロバイダーとして使用するようにします。OAuth プロバイダー機能には GitLab バージョン 7.7.0 以降が必要です。

例12.10 GitLabIdentityProvider を使用したマスター設定

oauthConfig:
  ...
  identityProviders:
  - name: gitlab 1
    challenge: true 2
    login: true 3
    mappingMethod: claim 4
    provider:
      apiVersion: v1
      kind: GitLabIdentityProvider
      url: ... 5
      clientID: ... 6
      clientSecret: ... 7
      ca: ... 8
1
このプロバイダー名は GitLab 数字ユーザー ID にプレフィックスとして付加され、アイデンティティー名が作成されます。これはコールバック URL を作成するためにも使用されます。
2
true の場合、非 Web クライアント (CLI など) からの認証されていないトークン要求は、このプロバイダーの WWW-Authenticate チャレンジヘッダーと共に送信されます。これは Resource Owner Password Credentials 付与フローを使用して GitLab からアクセストークンを取得します。
3
true の場合、Web クライアント (Web コンソールなど) からの非認証トークン要求はログインする GitLab にリダイレクトされます。
4
このプロバイダーのアイデンティティーとユーザーオブジェクト間のマッピングの確立方法を制御します (上記を参照してください)。
5
GitLab OAuth プロバイダーのホスト URL です。これは https://gitlab.com/ か、または他の GitLab の自己ホストインスタンスのいずれかになります。
6
登録済みの GitLab OAuth アプリケーションのクライアント ID です。アプリケーションは<master>/oauth2callback/<identityProviderName> のコールバック URL で設定する必要があります。
7
GitLab で発行されるクライアントシークレットです。この値は環境変数、外部ファイル、または暗号化されたファイルでも指定できます。
8
CA は、GitLab インスタンスへの要求を行う際に使用する任意の信頼される認証局バンドルです。空の場合、デフォルトのシステムルートが使用されます。

12.3.13. Google

Google の OpenID Connect 統合を使用して、identityProviders スタンザで GoogleIdentityProvider を設定し、アイデンティティープロバイダーとして Google を使用するようにします。

注記

Google をアイデンティティープロバイダーとして使用するには、<master>/oauth/token/request を使用してトークンを取得し、コマンドラインツールで使用する必要があります。

警告

Google をアイデンティティープロバイダーとして使用することで、Google ユーザーはサーバーに対して認証されます。以下のように hostedDomain 設定属性を使用して、特定のホストドメインのメンバーに認証を限定することができます。

例12.11 GoogleIdentityProvider を使用したマスター設定

oauthConfig:
  ...
  identityProviders:
  - name: google 1
    challenge: false 2
    login: true 3
    mappingMethod: claim 4
    provider:
      apiVersion: v1
      kind: GoogleIdentityProvider
      clientID: ... 5
      clientSecret: ... 6
      hostedDomain: "" 7
1
このプロバイダー名は Google の数字のユーザー ID にプレフィックスとして付加され、アイデンティティー名が作成されます。これはリダイレクト URL を作成するためにも使用されます。
2
GoogleIdentityProvider を使用して WWW-Authenticate チャレンジを送信することはできません。
3
true の場合、Web クライアント (Web コンソールなど) からの非認証トークン要求はログインする Google へリダイレクトされます。
4
このプロバイダーのアイデンティティーとユーザーオブジェクト間のマッピングの確立方法を制御します (上記を参照してください)。
5
登録済みの Google プロジェクト のクライアント ID です。プロジェクトは、<master>/oauth2callback/<identityProviderName> のリダイレクト URI で設定する必要があります。
6
Google で発行されるクライアントシークレットです。この値は環境変数、外部ファイル、または暗号化されたファイルでも指定できます。
7
サインインアカウントを制限するオプションの ホスト型ドメイン です。空の場合、すべての Google アカウントの認証が許可されます。

12.3.14. OpenID Connect

identityProviders スタンザで OpenIDIdentityProvider を設定し、Authorization Code Flow を使用して OpenID Connect アイデンティティープロバイダーと統合します。

OpenShift Container Platform の OpenID Connect アイデンティティープロバイダーとして Red Hat シングルサインオンを設定できます。

注記

ID Token および UserInfo の復号化はサポートされていません。

デフォルトで、openid の範囲が要求されます。必要な場合は、extraScopes フィールドで追加の範囲を指定できます。

要求は、OpenID アイデンティティープロバイダーから返される JWT id_token から読み取られ、指定される場合は UserInfo URL によって返される JSON から読み取られます。

1 つ以上の要求をユーザーのアイデンティティーを使用するように設定される必要があります。標準のアイデンティティー要求は sub になります。

また、どの要求をユーザーの推奨ユーザー名、表示名およびメールアドレスとして使用するか指定することができます。複数の要求が指定されている場合、値が入力されている最初の要求が使用されます。標準のアイデンティティー要求は以下の通りです。

sub

「subject identifier」の省略形です。発行側のユーザーのリモートアイデンティティーです。

preferred_username

ユーザーのプロビジョニング時に優先されるユーザー名です。janedoe などのユーザーを参照する際に使用する必要のある省略形の名前です。通常は、ユーザー名またはメールなどの、認証システムでのユーザーのログインまたはユーザー名に対応する値です。

email

メールアドレス。

name

表示名。

詳細は、OpenID claim のドキュメントを参照してください。

注記

OpenID Connect アイデンティティープロバイダーを使用するには、<master>/oauth/token/request を使用してトークンを取得し、コマンドラインツールで使用する必要があります。

OpenIDIdentityProvider を使用する標準マスター設定

oauthConfig:
  ...
  identityProviders:
  - name: my_openid_connect 1
    challenge: true 2
    login: true 3
    mappingMethod: claim 4
    provider:
      apiVersion: v1
      kind: OpenIDIdentityProvider
      clientID: ... 5
      clientSecret: ... 6
      claims:
        id: 7
        - sub
        preferredUsername:
        - preferred_username
        name:
        - name
        email:
        - email
      urls:
        authorize: https://myidp.example.com/oauth2/authorize 8
        token: https://myidp.example.com/oauth2/token 9

1
このプロバイダー名はアイデンティティー要求の値にプレフィックスとして付加され、アイデンティティー名が作成されます。これは、リダイレクト URL を作成するためにも使用されます。
2
true の場合、非 Web クライアント (CLI など) からの認証されていないトークン要求は、このプロバイダーの WWW-Authenticate チャレンジヘッダーと共に送信されます。この場合、OpenID プロバイダーが Resource Owner Password Credentials 付与フローをサポートしている必要があります。
3
true の場合、Web クライアント (Web コンソールなど) からの非認証トークン要求は、ログインする認証 URL にリダイレクトされます。
4
このプロバイダーのアイデンティティーとユーザーオブジェクト間のマッピングの確立方法を制御します (上記を参照してください)。
5
OpenID プロバイダーに登録されているクライアントのクライアント ID です。このクライアントは <master>/oauth2callback/<identityProviderName> にリダイレクトすることを許可されている必要があります。
6
クライアントシークレットです。この値は環境変数、外部ファイル、または暗号化されたファイルでも指定できます。
7
アイデンティティーとして使用する要求の一覧です。空でない最初の要求が使用されます。1 つ以上の要求が必要になります。一覧表示される要求のいずれにも値がないと、認証は失敗します。たとえば、これは、ユーザーのアイデンティティーとして、返される id_tokensub 要求の値を使用します。
8
OpenID 仕様に記述される承認エンドポイントです。https を使用する必要があります。
9
OpenID 仕様に記述されるトークンエンドポイントです。httpsを使用する必要があります。

カスタム証明書バンドル、追加の範囲、追加の承認要求パラメーター、および userInfo URL も指定できます。

例12.12 OpenIDIdentityProvider を使用する完全なマスター設定

oauthConfig:
  ...
  identityProviders:
  - name: my_openid_connect
    challenge: false
    login: true
    mappingMethod: claim
    provider:
      apiVersion: v1
      kind: OpenIDIdentityProvider
      clientID: ...
      clientSecret: ...
      ca: my-openid-ca-bundle.crt 1
      extraScopes: 2
      - email
      - profile
      extraAuthorizeParameters: 3
        include_granted_scopes: "true"
      claims:
        id: 4
        - custom_id_claim
        - sub
        preferredUsername: 5
        - preferred_username
        - email
        name: 6
        - nickname
        - given_name
        - name
        email: 7
        - custom_email_claim
        - email
      urls:
        authorize: https://myidp.example.com/oauth2/authorize
        token: https://myidp.example.com/oauth2/token
        userInfo: https://myidp.example.com/oauth2/userinfo 8
1
設定される URL のサーバー証明書を検証するために使用する証明書バンドルです。空の場合、システムで信頼されるルートを使用します。
2
承認トークン要求時に openid の範囲のほかに要求する範囲のオプションの一覧です。
3
承認トークン要求に追加する追加パラメーターのオプションのマップです。
4
アイデンティティーとして使用する要求の一覧です。空でない最初の要求が使用されます。1 つ以上の要求が必要になります。一覧表示される要求のいずれにも値がないと、認証は失敗します。
5
このアイデンティティーのユーザーをプロビジョニングする際に推奨ユーザー名として使用される要求の一覧です。空でない最初の要求が使用されます。
6
表示名として使用する要求の一覧です。空でない最初の要求が使用されます。
7
メールアドレスとして使用する要求の一覧です。空でない最初の要求が使用されます。
8
OpenID 仕様に記述される UserInfo エンドポイントです。https を使用する必要があります。

12.4. トークンオプション

OAuth サーバーは以下の 2 種類のトークンを生成します。

アクセストークン

API へのアクセスを付与する永続的なトークン。

認証コード

アクセストークンの交換にのみ使われる一時的なトークン。

tokenConfig スタンザを使用してトークンオプションを設定します。

例12.13 マスター設定のトークンオプション

oauthConfig:
  ...
  tokenConfig:
    accessTokenMaxAgeSeconds: 86400 1
    authorizeTokenMaxAgeSeconds: 300 2
1
accessTokenMaxAgeSeconds を設定して、アクセストークンの有効期間を制御します。デフォルトの期間は 24 時間です。
2
authorizeTokenMaxAgeSeconds を設定して、認証コードの有効期間を制御します。デフォルトの期間は 5 分です。
注記

OAuthClient オブジェクト定義 により accessTokenMaxAgeSeconds 値を上書きできます。

12.5. 付与オプション

OAuth サーバーが、ユーザーが以前にパーミッションを付与していないクライアントに対するトークン要求を受信する場合、OAuth サーバーが実行するアクションは OAuth クライアントの付与ストラテジーによって変わります。

トークンを要求する OAuth クライアントが独自の付与ストラテジーを提供しない場合、サーバー全体でのデフォルトストラテジーが使用されます。デフォルトストラテジーを設定するには、grantConfig スタンザで method 値を設定します。method の有効な値は以下の通りです。

auto

付与を自動承認し、要求を再試行します。

prompt

ユーザーに対して付与の承認または拒否を求めるプロンプトを出します。

deny

付与を自動的に拒否し、失敗エラーをクライアントに返します。

例12.14 マスター設定の付与オプション

oauthConfig:
  ...
  grantConfig:
    method: auto

12.6. セッションオプション

OAuth サーバーは、ログインおよびリダイレクトフローで署名および暗号化される Cookie ベースセッションを使用します。

sessionConfig スタンザを使用してセッションオプションを設定します。

例12.15 マスター設定のセッションオプション

oauthConfig:
  ...
  sessionConfig:
    sessionMaxAgeSeconds: 300 1
    sessionName: ssn 2
    sessionSecretsFile: "..." 3
1
セッションの最大期間を制御します。トークン要求が完了すると、セッションは自動的に期限切れとなります。auto-grant が有効にされていない場合、ユーザーがクライアント承認要求を承認または拒否するためにかかると想定される時間の間、セッションは継続する必要があります。
2
セッションを保存するために使用される Cookie の名前です。
3
シリアライズされた SessionSecrets オブジェクトを含むファイル名です。空の場合、サーバーが起動されるたびにランダムの署名および暗号化シークレットが生成されます。

sessionSecretsFile が指定されていない場合、マスターサーバーが起動されるたびにランダムの署名および暗号化シークレットが生成されます。つまりマスターが再起動されると、進行中のログインではセッションが無効になります。また、これは他のマスターのいずれかによって生成されるセッションを復号化することはできないことも意味します。

使用する署名および暗号化シークレットを指定するには、sessionSecretsFile を指定します。これにより、シークレット値と設定ファイルを分離でき、たとえば、設定ファイルをデバッグなどの目的に合わせて配布可能な状態とすることができます。

複数のシークレットを sessionSecretsFile に指定してローテーションを有効にできます。一覧の最初のシークレットを使用して、新しいセッションに署名し、これを暗号化します。既存のセッションは、成功するまで各シークレットによって復号化され、認証されます。

例12.16 セッションシークレット設定:

apiVersion: v1
kind: SessionSecrets
secrets: 1
- authentication: "..." 2
  encryption: "..." 3
- authentication: "..."
  encryption: "..."
...
1
Cookie セッションの認証と暗号化に使用するシークレットの一覧です。シークレットを 1 つ以上指定する必要があります。各シークレットでは認証および暗号化シークレットを設定する必要があります。
2
署名シークレットです。HMAC を使用してセッションを認証するために使用されます。32 または 64 バイトでシークレットを使用することを推奨しています。
3
暗号化シークレットです。セッションを暗号化するために使用されます。16、24、または 32 文字で、AES-128、AES-192、または AES-256 を選択するために使用されます。

12.7. ユーザーエージェントによる CLI バージョンの不一致の防止

OpenShift Container Platform は、アプリケーション開発者の CLI が OpenShift Container Platform API にアクセスすることを防止するために使用されるユーザーエージェントを実装しています。

OpenShift Container Platform CLI のユーザーエージェントは、OpenShift Container Platform 内の値のセットで構成されています。

<command>/<version> (<platform>/<architecture>) <client>/<git_commit>

たとえば、以下の場合を考慮しましょう。

  • <command> = oc
  • <version> = クライアントのバージョン。たとえば、v3.3.0/api で Kubernetes API に対して行われる要求が Kubernetes のバージョンを受信し、/oapi で OpenShift Container Platform API に対して行われる要求が OpenShift Container Platform のバージョン (oc version によって指定される) を受信します。
  • <platform> = linux
  • <architecture> = amd64
  • <client> = openshift または kubernetes。要求が /api で Kubernetes API に対して行われるか、/oapi で OpenShift Container Platform API に対して行われるかによって決まります。
  • <git_commit> = クライアントバージョンの Git コミット (例: f034127)

上記の場合、ユーザーエージェントは以下のようになります。

oc/v3.3.0 (linux/amd64) openshift/f034127

OpenShift Container Platform 管理者として、マスター設定の userAgentMatching 設定を使用してクライアントが API にアクセスできないようにすることができます。そのため、クライアントが特定のライブラリーまたはバイナリーを使用している場合、クライアントは API にアクセスできなくなります。

以下のユーザーエージェントの例は、Kubernetes 1.2 クライアントバイナリー、OpenShift Origin 1.1.3 バイナリー、POST および PUT httpVerbs を拒否します。

policyConfig:
  userAgentMatchingConfig:
    defaultRejectionMessage: "Your client is too old.  Go to https://example.org to update it."
    deniedClients:
    - regex: '\w+/v(?:(?:1\.1\.1)|(?:1\.0\.1)) \(.+/.+\) openshift/\w{7}'
    - regex: '\w+/v(?:1\.1\.3) \(.+/.+\) openshift/\w{7}'
      httpVerbs:
      - POST
      - PUT
    - regex: '\w+/v1\.2\.0 \(.+/.+\) kubernetes/\w{7}'
      httpVerbs:
      - POST
      - PUT
    requiredClients: null

管理者は、予想されるクライアントに正確に一致しないクライアントを拒否することもできます。

policyConfig:
  userAgentMatchingConfig:
    defaultRejectionMessage: "Your client is too old.  Go to https://example.org to update it."
    deniedClients: []
    requiredClients:
    - regex: '\w+/v1\.1\.3 \(.+/.+\) openshift/\w{7}'
    - regex: '\w+/v1\.2\.0 \(.+/.+\) kubernetes/\w{7}'
      httpVerbs:
      - POST
      - PUT
注記

クライアントのユーザーエージェントが設定と一致しない場合にエラーが発生します。変更する要求が一致するように、ホワイトリストを実施します。ルールは特定の verb にマップされるので、変化する要求を禁止し、変化しない要求を許可することができます。