検索

7.3. LDAP アイデンティティープロバイダーの設定

download PDF

ldap アイデンティティープロバイダーを、単純なバインド認証を使用して LDAPv3 サーバーに対してユーザー名とパスワードを検証するように設定します。

7.3.1. OpenShift Container Platform のアイデンティティープロバイダーについて

デフォルトでは、kubeadmin ユーザーのみがクラスターに存在します。アイデンティティープロバイダーを指定するには、アイデンティティープロバイダーを記述し、これをクラスターに追加するカスタムリソースを作成する必要があります。

注記

/:、および % を含む OpenShift Container Platform ユーザー名はサポートされません。

7.3.2. LDAP 認証について

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

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

  1. 設定された url の属性およびフィルターとユーザーが指定したユーザー名を組み合わせて検索フィルターを生成します。
  2. 生成されたフィルターを使用してディレクトリーを検索します。検索によって 1 つもエントリーが返されない場合は、アクセスを拒否します。
  3. 検索で取得したエントリーの DN とユーザー指定のパスワードを使用して LDAP サーバーへのバインドを試みます。
  4. バインドが失敗した場合は、アクセスを拒否します。
  5. バインドが成功した場合は、アイデンティティー、電子メールアドレス、表示名、および推奨ユーザー名として設定された属性を使用してアイデンティティーを作成します。

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

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

この URL の場合:

URL コンポーネント説明

ldap

通常の LDAP の場合は、文字列 ldap を使用します。セキュアな LDAP (LDAPS) の場合は、代わりに ldaps を使用します。

host:port

LDAP サーバーの名前とポートです。デフォルトは、ldap の場合は localhost:389、LDAPS の場合は localhost:636 です。

basedn

すべての検索が開始されるディレクトリーのブランチの DN です。これは少なくともディレクトリーツリーの最上位になければなりませんが、ディレクトリーのサブツリーを指定することもできます。

attribute

検索対象の属性です。RFC 2255 はコンマ区切りの属性の一覧を許可しますが、属性をどれだけ指定しても最初の属性のみが使用されます。属性を指定しない場合は、デフォルトで uid が使用されます。使用しているサブツリーのすべてのエントリー間で一意の属性を選択することを推奨します。

scope

検索の範囲です。one または sub のいずれかを指定できます。範囲を指定しない場合は、デフォルトの範囲として sub が使用されます。

filter

有効な LDAP 検索フィルターです。指定しない場合、デフォルトは (objectClass=*) です。

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

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

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

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

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

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

7.3.3. LDAP シークレットの作成

アイデンティティープロバイダーを使用するには、bindPassword が含まれる OpenShift Container Platform Secret オブジェクトを定義する必要があります。

  • bindPassword フィールドが含まれる OpenShift Container Platform Secret オブジェクトを定義します。

    $ oc create secret generic ldap-secret --from-literal=bindPassword=<secret> -n openshift-config
    注記

    上記のコマンドが示すように、--from-literal 引数についての bindPassword を含むシークレットキーは bindPassword として指定する必要があります。

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

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: "ldap://ldap.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 オブジェクトへの参照。insecurefalse の場合にのみ使用されます。
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 オブジェクトを作成する必要があります。

関連情報

7.3.6. アイデンティティープロバイダーのクラスターへの追加

クラスターのインストール後に、アイデンティティープロバイダーをそのクラスターに追加し、ユーザーの認証を実行できるようにします。

前提条件

  • OpenShift Container Platform クラスターを作成します。
  • アイデンティティープロバイダーのカスタムリソース (CR) を作成します。
  • 管理者としてログインしている必要があります。

手順

  1. 定義された 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この場合は、この警告を無視しても問題ありません。

  2. アイデンティティープロバイダーのユーザーとしてクラスターにログインし、プロンプトが出されたらパスワードを入力します。

    $ oc login -u <username>
  3. ユーザーが正常にログインされていることを確認し、ユーザー名を表示します。

    $ oc whoami
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.