7.4. Basic 認証アイデンティティープロバイダーの設定
basic-authentication
アイデンティティープロバイダーを、ユーザーがリモートアイデンティティープロバイダーに対して検証された認証情報を使って OpenShift Container Platform にログインできるように設定します。Basic 認証は、汎用的なバックエンド統合メカニズムです。
7.4.1. OpenShift Container Platform のアイデンティティープロバイダーについて
デフォルトでは、kubeadmin
ユーザーのみがクラスターに存在します。アイデンティティープロバイダーを指定するには、アイデンティティープロバイダーを記述し、これをクラスターに追加するカスタムリソースを作成する必要があります。
/
、:
、および %
を含む OpenShift Container Platform ユーザー名はサポートされません。
7.4.2. Basic 認証について
Basic 認証は、ユーザーがリモートのアイデンティティープロバイダーに対して検証した認証情報を使用して OpenShift Container Platform にログインすることを可能にする汎用バックエンド統合メカニズムです。
Basic 認証は汎用性があるため、このアイデンティティープロバイダー使用して詳細な認証設定を実行できます。
Basic 認証では、ユーザー ID とパスワードのスヌーピングを防ぎ、中間者攻撃を回避するためにリモートサーバーへの HTTPS 接続を使用する必要があります。
Basic 認証が設定されると、ユーザーはユーザー名とパスワードを OpenShift Container Platform に送信し、サーバー間の要求を行い、認証情報を Basic 認証ヘッダーとして渡すことで、これらの認証情報をリモートサーバーに対して検証することができます。このため、ユーザーはログイン時に認証情報を OpenShift Container Platform に送信する必要があります。
これはユーザー名/パスワードログインの仕組みにのみ有効で、OpenShift Container Platform はリモート認証サーバーに対するネットワーク要求を実行できる必要があります。
ユーザー名およびパスワードは Basic 認証で保護されるリモート 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 であり、判読可能な名前が存在する場合に便利です。これは、認証されたアイデンティティーの OpenShift Container Platform ユーザーをプロビジョニングする場合にヒントとして使われます。以下に例を示します。{"sub":"014fbff9a07c", "preferred_username":"bob", ...}
7.4.3. シークレットの作成
アイデンティティープロバイダーは openshift-config
namespace で OpenShift Container Platform Secret
オブジェクトを使用して、クライアントシークレット、クライアント証明書およびキーをこれに組み込みます。
以下のコマンドを使用して、文字列を含む OpenShift Container Platform
Secret
オブジェクトを定義できます。$ oc create secret tls <secret_name> --from-literal=tls.crt=<secret> --from-literal=tls.key=<secret> -n openshift-config
以下のコマンドを実行して、証明書ファイルなどのファイルの内容を含む OpenShift Container Platform
Secret
オブジェクトを定義できます。$ oc create secret tls <secret_name> --from-file=tls.crt=<path_to_file> --from-file=tls.key=<path_to_file> -n openshift-config
7.4.4. 設定マップの作成
アイデンティティープロバイダーは、openshift-config
namespace で OpenShift Container Platform ConfigMap
オブジェクトを使用し、認証局バンドルをこれに組み込みます。これらは、主にアイデンティティープロバイダーで必要な証明書バンドルを組み込むために使用されます。
手順
以下のコマンドを使用して、認証局が含まれる OpenShift Container Platform
ConfigMap
オブジェクトを定義します。認証局はConfigMap
オブジェクトのca.crt
キーに保存する必要があります。$ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config
7.4.5. Basic 認証 CR のサンプル
以下のカスタムリソース (CR) は、Basic 認証アイデンティティープロバイダーのパラメーターおよび許可される値を示します。
Basic 認証 CR
apiVersion: config.openshift.io/v1 kind: OAuth metadata: name: cluster spec: identityProviders: - name: basicidp 1 mappingMethod: claim 2 type: BasicAuth basicAuth: url: https://www.example.com/remote-idp 3 ca: 4 name: ca-config-map tlsClientCert: 5 name: client-cert-secret tlsClientKey: 6 name: client-key-secret
- 1
- このプロバイダー名は返されるユーザー名に接頭辞として付加され、アイデンティティー名が作成されます。
- 2
- このプロバイダーのアイデンティティーと
User
オブジェクト間にマッピングが確立される方法を制御します。 - 3
- Basic 認証ヘッダーで認証情報を受け入れる URL。
- 4
- オプション: 設定済みの URL のサーバー証明書を検証するために使用する PEM エンコードされた認証局バンドルを含む OpenShift Container Platform
ConfigMap
オブジェクトへの参照。 - 5
- オプション: 設定済み URL への要求を実行する際に存在させるクライアント証明書を含む OpenShift Container Platform
Secret
オブジェクトへの参照。 - 6
- クライアント証明書のキーを含む OpenShift Container Platform
Secret
オブジェクトへの参照。tlsClientCert
が指定されている場合には必須になります。
関連情報
-
すべてのアイデンティティープロバイダーに共通するパラメーターの詳細は、アイデンティティープロバイダーのパラメーター (
mappingMethod
など) について参照してください。
7.4.6. アイデンティティープロバイダーのクラスターへの追加
クラスターのインストール後に、アイデンティティープロバイダーをそのクラスターに追加し、ユーザーの認証を実行できるようにします。
前提条件
- OpenShift Container Platform クラスターを作成します。
- アイデンティティープロバイダーのカスタムリソース (CR) を作成します。
- 管理者としてログインしている必要があります。
手順
定義された CR を適用します。
$ oc apply -f </path/to/CR>
注記CR が存在しない場合、
oc apply
は新規 CR を作成し、さらに以下の警告をトリガーする可能性があります。Warning: oc apply should be used on resources created by either oc create --save-config or oc apply
この場合は、この警告を無視しても問題ありません。アイデンティティープロバイダーのユーザーとしてクラスターにログインし、プロンプトが出されたらパスワードを入力します。
$ oc login -u <username>
ユーザーが正常にログインされていることを確認し、ユーザー名を表示します。
$ oc whoami
7.4.7. 基本的なアイデンティティープロバイダーの Apache HTTPD 設定の例
OpenShift Container Platform 4 の基本的なアイデンティティープロバイダー (IDP) 設定では、IDP サーバーが成功および失敗について JSON で応答する必要があります。これを可能にするために、Apache HTTPD で CGI スクリプトを使用できます。本セクションでは、いくつかの例を紹介します。
例: /etc/httpd/conf.d/login.conf
<VirtualHost *:443> # CGI Scripts in here DocumentRoot /var/www/cgi-bin # SSL Directives SSLEngine on SSLCipherSuite PROFILE=SYSTEM SSLProxyCipherSuite PROFILE=SYSTEM SSLCertificateFile /etc/pki/tls/certs/localhost.crt SSLCertificateKeyFile /etc/pki/tls/private/localhost.key # Configure HTTPD to execute scripts ScriptAlias /basic /var/www/cgi-bin # Handles a failed login attempt ErrorDocument 401 /basic/fail.cgi # Handles authentication <Location /basic/login.cgi> AuthType Basic AuthName "Please Log In" AuthBasicProvider file AuthUserFile /etc/httpd/conf/passwords Require valid-user </Location> </VirtualHost>
例: /var/www/cgi-bin/login.cgi
#!/bin/bash echo "Content-Type: application/json" echo "" echo '{"sub":"userid", "name":"'$REMOTE_USER'"}' exit 0
例: /var/www/cgi-bin/fail.cgi
#!/bin/bash echo "Content-Type: application/json" echo "" echo '{"error": "Login failure"}' exit 0
7.4.7.1. ファイルの要件
Apache HTTPD Web サーバーで作成するファイルの要件は以下のとおりです。
-
login.cgi
およびfail.cgi
は実行可能 (chmod +x
) である必要があります。 -
login.cgi
およびfail.cgi
には、SELinux が有効にされている場合、適切な SELinux コンテキストがなければなりません:restorecon -RFv /var/www/cgi-bin
、またはコンテキストがls -laZ
を使用してhttpd_sys_script_exec_t
であることを確認します。 -
login.cgi
は、ユーザーがRequire and Auth
ディレクティブを使用して正常にログインできる場合にのみ実行されます。 -
fail.cgi
は、ユーザーがログインに失敗する場合に実行されます (HTTP 401
応答が返されます)。
7.4.8. Basic 認証のトラブルシューティング
最もよく起こる問題は、バックエンドサーバーへのネットワーク接続に関連しています。簡単なデバッグの場合は、マスターで 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 であり、判読可能な名前が存在する場合に便利です。これは、認証されたアイデンティティーの OpenShift Container Platform ユーザーをプロビジョニングする場合にヒントとして使われます。
失敗の応答
-
401
応答は認証の失敗を示しています。 -
200
以外のステータスまたは空でないエラーキーはエラーを示しています:{"error":"Error message"}