4.3. LDAP アイデンティティープロバイダーの設定
ldap
アイデンティティープロバイダーを、単純なバインド認証を使用して LDAPv3 サーバーに対してユーザー名とパスワードを検証するように設定します。
4.3.1. OpenShift Container Platform のアイデンティティープロバイダーについて
デフォルトでは、kubeadmin
ユーザーのみがクラスターに存在します。アイデンティティープロバイダーを指定するには、アイデンティティープロバイダーを記述し、これをクラスターに追加するカスタムリソース (CR、Custom Resource) を作成する必要があります。
/
、:
、および %
を含む OpenShift Container Platform ユーザー名はサポートされません。
4.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
を指定します。
4.3.3. LDAP シークレットの作成
アイデンティティープロバイダーを使用するには、 bindPassword が含まれる OpenShift Container Platform シークレットを定義する必要があります。
bindPassword が含まれる OpenShift Container Platform シークレットを定義します。
$ oc create secret generic ldap-secret --from-literal=bindPassword=<secret> -n openshift-config
注記上記のコマンドが示すように、
--from-literal
引数についての bindPassword を含むシークレットキーはbindPassword
として指定する必要があります。
4.3.4. ConfigMap の作成
アイデンティティープロバイダーは、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
4.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: "ldap://ldap.example.com/ou=users,dc=acme,dc=com?uid" 11
- 1
- このプロバイダー名は返されるユーザー名にプレフィックスとして付加され、アイデンティティー名が作成されます。
- 2
- このプロバイダーのアイデンティティーとユーザーオブジェクト間にマッピングが確立される方法を制御します。
- 3
- アイデンティティーとして使用する属性の一覧です。最初の空でない属性が使用されます。少なくとも 1 つの属性が必要です。一覧表示される属性のいずれにも値がない場合、認証は失敗します。定義される属性は raw データとして取得され、バイナリー値の使用を許可します。
- 4
- メールアドレスとして使用する属性の一覧です。最初の空でない属性が使用されます。
- 5
- 表示名として使用する属性の一覧です。最初の空でない属性が使用されます。
- 6
- このアイデンティティーのユーザーをプロビジョニングする際に推奨ユーザー名として使用する属性の一覧です。最初の空でない属性が使用されます。
- 7
- 検索フェーズでバインドするために使用するオプションの DN です。
bindPassword
が定義される場合に設定される必要があります。 - 8
- オプション: バインドパスワードを含む OpenShift Container Platform シークレットへの参照。
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 ユーザーのアイデンティティーとユーザーオブジェクトを作成する必要があります。
4.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