This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.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
ldap://host:port/basedn?attribute?scope?filter
この URL の場合:
URL コンポーネント | 説明 |
---|---|
|
通常の LDAP の場合は、文字列 |
|
LDAP サーバーの名前とポートです。デフォルトは、ldap の場合は |
| すべての検索が開始されるディレクトリーのブランチの DN です。これは少なくともディレクトリーツリーの最上位になければなりませんが、ディレクトリーのサブツリーを指定することもできます。 |
|
検索対象の属性です。RFC 2255 はカンマ区切りの属性の一覧を許可しますが、属性をどれだけ指定しても最初の属性のみが使用されます。属性を指定しない場合は、デフォルトで |
|
検索の範囲です。 |
|
有効な LDAP 検索フィルターです。指定しない場合、デフォルトは |
検索の実行時に属性、フィルター、指定したユーザー名が組み合わされて以下のような検索フィルターが作成されます。
(&(<filter>)(<attribute>=<username>))
(&(<filter>)(<attribute>=<username>))
たとえば、以下の URL について見てみましょう。
ldap://ldap.example.com/o=Acme?cn?sub?(enabled=true)
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
$ oc create secret generic ldap-secret --from-literal=bindPassword=<secret> -n openshift-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記上記のコマンドが示すように、
--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
$ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3.5. LDAP CR のサンプル リンクのコピーリンクがクリップボードにコピーされました!
以下のカスタムリソース (CR) は、LDAP アイデンティティープロバイダーのパラメーターおよび許可される値を示しています。
LDAP CR
- 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>
$ oc apply -f </path/to/CR>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記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 login -u <username>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ユーザーが正常にログインされていることを確認し、ユーザー名を表示します。
oc whoami
$ oc whoami
Copy to Clipboard Copied! Toggle word wrap Toggle overflow