7.3. LDAP アイデンティティープロバイダーの設定
ldap アイデンティティープロバイダーを、単純なバインド認証を使用して LDAPv3 サーバーに対してユーザー名とパスワードを検証するように設定します。
7.3.1. OpenShift Container Platform のアイデンティティープロバイダーについて
デフォルトでは、kubeadmin ユーザーのみがクラスターに存在します。アイデンティティープロバイダーを指定するには、アイデンティティープロバイダーを記述し、これをクラスターに追加するカスタムリソースを作成する必要があります。
/、:、および % を含む OpenShift Container Platform ユーザー名はサポートされません。
7.3.2. LDAP 認証について
認証時に、指定されたユーザー名に一致するエントリーが LDAP ディレクトリーで検索されます。単一の一意の一致が見つかった場合、エントリーの識別名 (DN) と指定されたパスワードを使用した単純なバインドが試みられます。
以下の手順が実行されます。
-
設定された
urlの属性およびフィルターとユーザーが指定したユーザー名を組み合わせて検索フィルターを生成します。 - 生成されたフィルターを使用してディレクトリーを検索します。検索によって 1 つもエントリーが返されない場合は、アクセスを拒否します。
- 検索で取得したエントリーの DN とユーザー指定のパスワードを使用して LDAP サーバーへのバインドを試みます。
- バインドが失敗した場合は、アクセスを拒否します。
- バインドが成功した場合は、アイデンティティー、電子メールアドレス、表示名、および推奨ユーザー名として設定された属性を使用してアイデンティティーを作成します。
設定される url は、LDAP ホストと使用する検索パラメーターを指定する RFC 2255 URL です。URL の構文は以下のようになります。
ldap://host:port/basedn?attribute?scope?filter
この URL の場合:
| URL コンポーネント | 説明 |
|---|---|
|
|
通常の LDAP の場合は、文字列 |
|
|
LDAP サーバーの名前とポートです。デフォルトは、ldap の場合は |
|
| すべての検索が開始されるディレクトリーのブランチの DN です。これは少なくともディレクトリーツリーの最上位になければなりませんが、ディレクトリーのサブツリーを指定することもできます。 |
|
|
検索対象の属性です。RFC 2255 はコンマ区切りの属性の一覧を許可しますが、属性をどれだけ指定しても最初の属性のみが使用されます。属性を指定しない場合は、デフォルトで |
|
|
検索の範囲です。 |
|
|
有効な LDAP 検索フィルターです。指定しない場合、デフォルトは |
検索の実行時に属性、フィルター、指定したユーザー名が組み合わされて以下のような検索フィルターが作成されます。
(&(<filter>)(<attribute>=<username>))
たとえば、以下の URL について見てみましょう。
ldap://ldap.example.com/o=Acme?cn?sub?(enabled=true)
クライアントが bob というユーザー名を使用して接続を試みる場合、生成される検索フィルターは (&(enabled=true)(cn=bob)) になります。
LDAP ディレクトリーの検索に認証が必要な場合は、エントリー検索の実行に使用する bindDN と bindPassword を指定します。
7.3.3. LDAP シークレットの作成
アイデンティティープロバイダーを使用するには、bindPassword が含まれる OpenShift Container Platform Secret オブジェクトを定義する必要があります。
手順
bindPasswordフィールドが含まれるSecretオブジェクトを作成します。$ oc create secret generic ldap-secret --from-literal=bindPassword=<secret> -n openshift-config 1- 1
--from-literal引数についての bindPassword を含むシークレットキーはbindPasswordとして指定する必要があります。
ヒントまたは、以下の YAML を適用してシークレットを作成できます。
apiVersion: v1 kind: Secret metadata: name: ldap-secret namespace: openshift-config type: Opaque data: bindPassword: <base64_encoded_bind_password>
7.3.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
ヒントまたは、以下の YAML を適用して設定マップを作成できます。
apiVersion: v1 kind: ConfigMap metadata: name: ca-config-map namespace: openshift-config data: ca.crt: | <CA_certificate_PEM>
7.3.5. LDAP CR のサンプル
以下のカスタムリソース (CR) は、LDAP アイデンティティープロバイダーのパラメーターおよび許可される値を示しています。
LDAP CR
apiVersion: config.openshift.io/v1 kind: OAuth metadata: name: cluster spec: identityProviders: - name: ldapidp 1 mappingMethod: claim 2 type: LDAP ldap: attributes: id: 3 - dn email: 4 - mail name: 5 - cn preferredUsername: 6 - uid bindDN: "" 7 bindPassword: 8 name: ldap-secret ca: 9 name: ca-config-map insecure: false 10 url: "ldaps://ldaps.example.com/ou=users,dc=acme,dc=com?uid" 11
- 1
- このプロバイダー名は返されるユーザー名に接頭辞として付加され、アイデンティティー名が作成されます。
- 2
- このプロバイダーのアイデンティティーと
Userオブジェクト間にマッピングが確立される方法を制御します。 - 3
- アイデンティティーとして使用する属性の一覧です。最初の空でない属性が使用されます。少なくとも 1 つの属性が必要です。一覧表示される属性のいずれにも値がない場合、認証は失敗します。定義される属性は raw データとして取得され、バイナリー値の使用を許可します。
- 4
- メールアドレスとして使用する属性の一覧です。最初の空でない属性が使用されます。
- 5
- 表示名として使用する属性の一覧です。最初の空でない属性が使用されます。
- 6
- このアイデンティティーのユーザーをプロビジョニングする際に推奨ユーザー名として使用する属性の一覧です。最初の空でない属性が使用されます。
- 7
- 検索フェーズでバインドするために使用するオプションの DN です。
bindPasswordが定義される場合に設定される必要があります。 - 8
- オプション: バインドパスワードを含む OpenShift Container Platform
Secretオブジェクトへの参照。bindDNが定義される場合に設定される必要があります。 - 9
- オプション: 設定済みの URL のサーバー証明書を検証するために使用する PEM エンコードされた認証局バンドルを含む OpenShift Container Platform
ConfigMapオブジェクトへの参照。insecureがfalseの場合にのみ使用されます。 - 10
trueの場合、サーバーへの TLS 接続は行われません。falseの場合、ldaps://URL は TLS を使用して接続し、ldap://URL は TLS にアップグレードされます。これは、ldaps://URL が使用されている場合はfalseに設定される必要があります。 これらの URL は常に TLS を使用して接続を試行します。- 11
- LDAP ホストと使用する検索パラメーターを指定する RFC 2255 URL です。
LDAP 統合のためのユーザーのホワイトリストを作成するには、lookup マッピング方法を使用します。LDAP からのログインが許可される前に、クラスター管理者は各 LDAP ユーザーの Identity オブジェクトと User オブジェクトを作成する必要があります。
関連情報
-
すべてのアイデンティティープロバイダーに共通するパラメーターの詳細は、アイデンティティープロバイダーのパラメーター (
mappingMethodなど) について参照してください。
7.3.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
