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

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

# htpasswd auth
openshift_master_identity_providers=[{'name': 'htpasswd_auth', 'login': 'true', 'challenge': 'true', 'kind': 'HTPasswdPasswordIdentityProvider'}]
# 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

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

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

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

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

oauthConfig:
  ...
  identityProviders:
  - name: my_allow_provider 1
    challenge: true 2
    login: true 3
    mappingMethod: claim 4
    provider:
      apiVersion: v1
      kind: AllowAllPasswordIdentityProvider

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

oauthConfig:
  ...
  identityProviders:
  - name: my_deny_provider 1
    challenge: true 2
    login: true 3
    mappingMethod: claim 4
    provider:
      apiVersion: v1
      kind: DenyAllPasswordIdentityProvider

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

# yum install httpd-tools

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

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

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

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

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

$ oc get users
NAME         UID                                    FULL NAME   IDENTITIES
bobsmith     a0c1d95c-1cb5-11e6-a04a-002186a28631   Bob Smith   keystone:bobsmith 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{"error":"Error message"}

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

{"sub":"userid"} 1

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

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":"userid"}

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

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

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

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

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

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

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

要求ヘッダーを使用した Apache 認証

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

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

前提条件のインストール

Apache の設定

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

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
# master-restart api
# master-restart controllers

設定の確認

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

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

$ oc get users
NAME         UID                                    FULL NAME   IDENTITIES
bobsmith     433b5641-066f-11e6-a6d8-acfc32c1ca87   Bob Smith   github:873654 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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