認証

1. ユーザーおよびパスワード情報を保存するために htpasswd ファイルを作成します。Linux および Windows用の手順が説明されます。
2. htpasswd ファイルを表すために OpenShift Container Platform シークレットを作成します 。
3. HTPasswd アイデンティティープロバイダーリソースを定義します。
4. リソースをデフォルトの OAuth 設定に適用します 。

手順

1. ユーザー名およびハッシュされたパスワードを含むフラットファイルを作成します。

   $ htpasswd -c -B -b </path/to/users.htpasswd> <user_name> <password>

   コマンドにより、ハッシュされたバージョンのパスワードが生成されます。

   例:

   $ htpasswd -c -B -b users.htpasswd user1 MyPassword!
   
   Adding password for user user1

2. ファイルに対する認証情報の追加またはその更新を継続します。

   $ htpasswd -b </path/to/users.htpasswd> <user_name> <password>

手順

1. ユーザー名およびハッシュされたパスワードを含むフラットファイルを作成します。

   > htpasswd.exe -c -B -b <\path\to\users.htpasswd> <user_name> <password>

   コマンドにより、ハッシュされたバージョンのパスワードが生成されます。

   例:

   > htpasswd.exe -c -B -b users.htpasswd user1 MyPassword!
   
   Adding password for user user1

2. ファイルに対する認証情報の追加またはその更新を継続します。

   > htpasswd.exe -b <\path\to\users.htpasswd> <user_name> <password>

手順

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

手順

1. Administration → Cluster Settings に移動します。
2. Global Configuration タブで、OAuth をクリックします。
3. Identity Providers セクションで、Add ドロップダウンメニューからアイデンティティープロバイダーを選択します。

手順

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

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

手順

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

手順

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

手順

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

1. Apache 設定の証明書を作成します。SSLProxyMachineCertificateFile パラメーターの値として指定する証明書は、プロキシーをサーバーに対して認証するために使用されるプロキシーのクライアント証明書です。これは、拡張されたキーのタイプとして TLS Web Client Authentication を使用する必要があります。

2. Apache 設定を作成します。以下のテンプレートを使用して必要な設定および値を指定します。

   重要

   テンプレートを十分に確認し、その内容を環境に合うようにカスタマイズします。

   LoadModule request_module modules/mod_request.so
   LoadModule auth_gssapi_module modules/mod_auth_gssapi.so
   # Some Apache configurations might require these modules.
   # LoadModule auth_form_module modules/mod_auth_form.so
   # LoadModule session_module modules/mod_session.so
   
   # Nothing needs to be served over HTTP.  This virtual host simply redirects to
   # HTTPS.
   <VirtualHost *:80>
     DocumentRoot /var/www/html
     RewriteEngine              On
     RewriteRule     ^(.*)$     https://%{HTTP_HOST}$1 [R,L]
   </VirtualHost>
   
   <VirtualHost *:443>
     # This needs to match the certificates you generated.  See the CN and X509v3
     # Subject Alternative Name in the output of:
     # openssl x509 -text -in /etc/pki/tls/certs/localhost.crt
     ServerName www.example.com
   
     DocumentRoot /var/www/html
     SSLEngine on
     SSLCertificateFile /etc/pki/tls/certs/localhost.crt
     SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
     SSLCACertificateFile /etc/pki/CA/certs/ca.crt
   
     SSLProxyEngine on
     SSLProxyCACertificateFile /etc/pki/CA/certs/ca.crt
     # It is critical to enforce client certificates. Otherwise, requests can
     # spoof the X-Remote-User header by accessing the /oauth/authorize endpoint
     # directly.
     SSLProxyMachineCertificateFile /etc/pki/tls/certs/authproxy.pem
   
     # To use the challenging-proxy, an X-Csrf-Token must be present.
     RewriteCond %{REQUEST_URI} ^/challenging-proxy
     RewriteCond %{HTTP:X-Csrf-Token} ^$ [NC]
     RewriteRule ^.* - [F,L]
   
     <Location /challenging-proxy/oauth/authorize>
         # Insert your backend server name/ip here.
         ProxyPass https://<namespace_route>/oauth/authorize
         AuthName "SSO Login"
         # For Kerberos
         AuthType GSSAPI
         Require valid-user
         RequestHeader set X-Remote-User %{REMOTE_USER}s
   
         GssapiCredStore keytab:/etc/httpd/protected/auth-proxy.keytab
         # Enable the following if you want to allow users to fallback
         # to password based authentication when they do not have a client
         # configured to perform kerberos authentication.
         GssapiBasicAuth On
   
         # For ldap:
         # AuthBasicProvider ldap
         # AuthLDAPURL "ldap://ldap.example.com:389/ou=People,dc=my-domain,dc=com?uid?sub?(objectClass=*)"
       </Location>
   
       <Location /login-proxy/oauth/authorize>
       # Insert your backend server name/ip here.
       ProxyPass https://<namespace_route>/oauth/authorize
   
         AuthName "SSO Login"
         AuthType GSSAPI
         Require valid-user
         RequestHeader set X-Remote-User %{REMOTE_USER}s env=REMOTE_USER
   
         GssapiCredStore keytab:/etc/httpd/protected/auth-proxy.keytab
         # Enable the following if you want to allow users to fallback
         # to password based authentication when they do not have a client
         # configured to perform kerberos authentication.
         GssapiBasicAuth On
   
         ErrorDocument 401 /login.html
       </Location>
   
   </VirtualHost>
   
   RequestHeader unset X-Remote-User

   注記

   https://<namespace_route> アドレスは OAuth サーバーへのルートであり、oc get route -n openshift-authentication を実行して取得できます。

3. カスタムリソース (CR) の identityProviders スタンザを更新します。

   identityProviders:
     - name: requestheaderidp
       type: RequestHeader
       requestHeader:
         challengeURL: "https://<namespace_route>/challenging-proxy/oauth/authorize?${query}"
         loginURL: "https://<namespace_route>/login-proxy/oauth/authorize?${query}"
         ca:
           name: ca-config-map
           clientCommonNames:
           - my-auth-proxy
           headers:
           - X-Remote-User

4. 設定を確認します。

   1. 適切なクライアント証明書およびヘッダーを指定して、トークンを要求し、プロキシーをバイパスできることを確認します。

      # curl -L -k -H "X-Remote-User: joe" \
         --cert /etc/pki/tls/certs/authproxy.pem \
         https://<namespace_route>/oauth/token/request

   2. クライアント証明書を提供しない要求が、証明書なしでトークンを要求して失敗することを確認します。

      # curl -L -k -H "X-Remote-User: joe" \
         https://<namespace_route>/oauth/token/request

   3. challengeURL リダイレクトがアクティブであることを確認します。

      # curl -k -v -H 'X-Csrf-Token: 1' \
         https://<namespace_route>/oauth/authorize?client_id=openshift-challenging-client&response_type=token

      以下の手順で使用する challengeURL リダイレクトをコピーします。

   4. このコマンドを実行して、WWW-Authenticate 基本チャレンジ、ネゴシエートチャレンジ、またはそれらの両方のチャレンジを含む 401 応答を表示します。

      # curl -k -v -H 'X-Csrf-Token: 1' \
         <challengeURL_redirect + query>

   5. Kerberos チケットを使用または使用せずに、OpenShift CLI (oc) へのログインをテストします。

      1. kinit を使用して Kerberos チケットを生成した場合は、これを破棄します。

         # kdestroy -c cache_name 1

         1

         Kerberos キャッシュの名前を指定します。

      2. Kerberos 認証情報を使用して oc ツールにログインします。

         # oc login

         プロンプトで、Kerberos ユーザー名およびパスワードを入力します。

      3. oc ツールからログアウトします。

         # oc logout

      4. Kerberos 認証情報を使用してチケットを取得します。

         # kinit

         プロンプトで、Kerberos ユーザー名およびパスワードを入力します。

      5. oc ツールにログインできることを確認します。

         # oc login

         設定が正しい場合は、別の認証情報を入力せずにログインできます。

手順

1. アプリケーションを GitHub で登録します。

   • GitHub の場合、「Settings」 → 「Developer settings」 → 「OAuth Apps」 → 「Register a new OAuth application」をクリックします。
   • GitHub Enterprise の場合は、GitHub Enterprise ホームページに移動してから 「Settings」 → 「Developer settings」 → 「Register a new application」 をクリックします。
2. アプリケーション名を入力します (例: My OpenShift Install)。
3. ホームページ URL (例: https://oauth-openshift.apps.<cluster-name>.<cluster-domain>) を入力します。
4. オプション: アプリケーションの説明を入力します。

5. 認可コールバック URL を入力します。 ここで、URL の終わりにはアイデンティティープロバイダーの name が含まれます。

   https://oauth-openshift.apps.<cluster-name>.<cluster-domain>/oauth2callback/<idp-provider-name>

   例:

   https://oauth-openshift.apps.example-openshift-cluster.com/oauth2callback/github/

6. Register application をクリックします。GitHub はクライアント ID とクライアントシークレットを提供します。これらの値は、アイデンティティープロバイダーの設定を完了するために必要です。

手順

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. OAuth サーバーからトークンを取得します。

   kubeadmin ユーザーが削除されている限り、 oc login コマンドは、トークンを取得できる Web ページにアクセスする方法についての情報を提供します。

   Web コンソールからこのページにアクセスするには、(?) Help → Command Line Tools → Copy Login Commandに移動します。

3. 認証するトークンを渡して、クラスターにログインします。

   $ oc login --token=<token>

   注記

   このアイデンティティープロバイダーは、ユーザー名とパスワードを使用してログインすることをサポートしません。

4. ユーザーが正常にログインされていることを確認し、ユーザー名を表示します。

   $ oc whoami

手順

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

手順

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. OAuth サーバーからトークンを取得します。

   kubeadmin ユーザーが削除されている限り、 oc login コマンドは、トークンを取得できる Web ページにアクセスする方法についての情報を提供します。

   Web コンソールからこのページにアクセスするには、(?) Help → Command Line Tools → Copy Login Commandに移動します。

3. 認証するトークンを渡して、クラスターにログインします。

   $ oc login --token=<token>

   注記

   このアイデンティティープロバイダーは、ユーザー名とパスワードを使用してログインすることをサポートしません。

4. ユーザーが正常にログインされていることを確認し、ユーザー名を表示します。

   $ oc whoami

手順

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. OAuth サーバーからトークンを取得します。

   kubeadmin ユーザーが削除されている限り、 oc login コマンドは、トークンを取得できる Web ページにアクセスする方法についての情報を提供します。

   Web コンソールからこのページにアクセスするには、(?) Help → Command Line Tools → Copy Login Commandに移動します。

3. 認証するトークンを渡して、クラスターにログインします。

   $ oc login --token=<token>

   注記

   このアイデンティティープロバイダーは、ユーザー名とパスワードを使用してログインすることをサポートしません。

4. ユーザーが正常にログインされていることを確認し、ユーザー名を表示します。

   $ oc whoami

手順

1. Administration → Cluster Settings に移動します。
2. Global Configuration タブで、OAuth をクリックします。
3. Identity Providers セクションで、Add ドロップダウンメニューからアイデンティティープロバイダーを選択します。

手順

1. ワイルドカード証明書およびキーが含まれるシークレットを作成します。

   $ oc create secret tls <certificate> \1
        --cert=</path/to/cert.crt> \2
        --key=</path/to/cert.key> \3
        -n openshift-ingress

   1

   <certificate> は、証明書およびプライベートキーが含まれるシークレットの名前です。

   2

   </path/to/cert.crt> は、ローカルファイルシステム上の証明書へのパスです。

   3

   </path/to/cert.key> は、この証明書に関連付けられるプライベートキーへのパスです。

2. Ingress コントローラー設定を、新規に作成されたシークレットで更新します。

   $ oc patch ingresscontroller.operator default \
        --type=merge -p \
        '{"spec":{"defaultCertificate": {"name": "<certificate>"}}}' \1
        -n openshift-ingress-operator

   1

   <certificate> を、直前の手順のシークレットで使用された名前に置き換えます。

手順

1. openshift-config namespace に証明書およびキーが含まれるシークレットを作成します。

   $ oc create secret tls <certificate> \1
        --cert=</path/to/cert.crt> \2
        --key=</path/to/cert.key> \3
        -n openshift-config

   1

   <certificate> は、証明書が含まれるシークレットの名前です。

   2

   </path/to/cert.crt> は、ローカルファイルシステム上の証明書へのパスです。

   3

   </path/to/cert.key> は、この証明書に関連付けられるプライベートキーへのパスです。

2. API サーバーを作成されたシークレットを参照するように更新します。

   $ oc patch apiserver cluster \
        --type=merge -p \
        '{"spec":{"servingCerts": {"namedCertificates":
        [{"names": ["<hostname>"], 1
        "servingCertificate": {"name": "<certificate>"}}]}}}' 2

   1

   <hostname> を、API サーバーが証明書を提供するホスト名に置き換えます。

   2

   <certificate> を、直前の手順のシークレットで使用された名前に置き換えます。

3. apiserver/cluster オブジェクトを検査し、シークレットが参照されていることを確認します。

   $ oc get apiserver cluster -o yaml
   ...
   spec:
     servingCerts:
       namedCertificates:
       - names:
         - <hostname>
         servingCertificate:
           name: <certificate>
   ...

手順

1. サービスに service.beta.openshift.io/serving-cert-secret-name のアノテーションを付けます。

   $ oc annotate service <service-name> \1
        service.beta.openshift.io/serving-cert-secret-name=<secret-name> 2

   1

   <service-name> を、セキュリティー保護するサービスの名前に置き換えます。

   2

   <secret-name> は、証明書とキーのペアを含む生成されたシークレットの名前です。便宜上、これを <service-name> と同じにすることが推奨されます。

   たとえば、以下のコマンドを使用してサービス foo にアノテーションを付けます。

   $ oc annotate service foo service.beta.openshift.io/serving-cert-secret-name=foo

2. アノテーションが存在することを確認するためにサービスを検査します。

   $ oc describe service <service-name>
   ...
   Annotations:              service.beta.openshift.io/serving-cert-secret-name: <service-name>
                             service.beta.openshift.io/serving-cert-signed-by: openshift-service-serving-signer@1556850837
   ...

3. クラスターがサービスのシークレットを生成した後に、 PodSpec がこれをマウントでき、Pod はシークレットが利用可能になった後にこれを実行できます。

手順

1. ConfigMap に service.beta.openshift.io/inject-cabundle=true のアノテーションを付けます。

   $ oc annotate configmap <configmap-name> \1
        service.beta.openshift.io/inject-cabundle=true

   1

   <configmap-name> を、アノテーションを付ける ConfigMap の名前に置き換えます。

   注記

   volumeMount の service-ca.crt キーを明示的に参照することにより、ConfigMap が CA バンドルと共に挿入されるまで、Pod を起動できなくなります。

   たとえば、ConfigMap foo にアノテーションを付けるには、以下のコマンドを使用します。

   $ oc annotate configmap foo service.beta.openshift.io/inject-cabundle=true

2. 証明書が生成されていることを確認するために ConfigMap を表示します。これは、YAML 出力の service-ca.crt として表示されます。

   $ oc get configmap <configmap-name> -o yaml
   apiVersion: v1
   data:
     service-ca.crt: |
       -----BEGIN CERTIFICATE-----
   ...

手順

1. 証明書を含むシークレットを確認するためにサービスを検査します。これは、以下に示すように serving-cert-secret-name アノテーションにあります。

   $ oc describe service <service-name>
   ...
   service.beta.openshift.io/serving-cert-secret-name: <secret>
   ...

2. サービスの生成されたシークレットを削除します。このプロセスで、シークレットが自動的に再作成されます。

   $ oc delete secret <secret> 1

   1

   <secret> を、直前の手順のシークレットの名前に置き換えます。

3. 新規シークレットを取得し、AGE を調べて、証明書が再作成されていることを確認します。

   $ oc get secret <service-name>
   
   NAME              TYPE                DATA   AGE
   <service.name>    kubernetes.io/tls   2      1s

手順

1. 以下のコマンドを使用して、現在のサービス CA 証明書の有効期限を表示します。

   $ oc get secrets/signing-key -n openshift-service-ca \
        -o template='{{index .data "tls.crt"}}' \
        | base64 -d \
        | openssl x509 -noout -enddate

2. サービス CA を手動でローテーションします。このプロセスは、新規サービス証明書に署名するために使用される新規サービス CA を生成します。

   $ oc delete secret/signing-key -n openshift-service-ca

3. 新規証明書をすべてのサービスに適用するには、クラスター内のすべての Pod を再起動します。このコマンドにより、すべてのサービスが更新された証明書を使用するようになります。

   $ for I in $(oc get ns -o jsonpath='{range .items[*]} {.metadata.name}{"\n"} {end}'); \
         do oc delete pods --all -n $I; \
         sleep 1; \
         done

   警告

   このコマンドは、すべての namespace で実行されているすべての Pod を調べ、これらを削除するため、サービスを中断させます。これらの Pod は削除後に自動的に再起動します。

1. アイデンティティーおよびプロジェクトでスコープ設定されたアクションは、ユーザーおよびそれらのグループに適用されるすべてのバインディングを検索します。
2. バインディングは、適用されるすべてのロールを見つけるために使用されます。
3. ロールは、適用されるすべてのルールを見つけるために使用されます。
4. 一致を見つけるために、アクションが各ルールに対してチェックされます。
5. 一致するルールが見つからない場合、アクションはデフォルトで拒否されます。

RunAsUser

1. MustRunAs: runAsUser が設定されることを要求します。デフォルトで設定済みの runAsUser を使用します。設定済みの runAsUser に対して検証します。
2. MustRunAsRange: 事前に割り当てられた値を使用していない場合に、最小および最大値が定義されることを要求します。デフォルトでは最小値を使用します。許可される範囲全体に対して検証します。
3. MustRunAsNonRoot: Pod がゼロ以外の runAsUser で送信されること、または USER ディレクティブをイメージに定義することを要求します。デフォルトは指定されません。
4. RunAsAny: デフォルトは指定されません。runAsUser の指定を許可します。

SELinuxContext

1. MustRunAs: 事前に割り当てられた値を使用していない場合に seLinuxOptions が設定されることを要求します。デフォルトとして seLinuxOptions を使用します。seLinuxOptions に対して検証します。
2. RunAsAny: デフォルトは指定されません。seLinuxOptions の指定を許可します。

SupplementalGroups

1. MustRunAs: 事前に割り当てられた値を使用していない場合に、少なくとも 1 つの範囲が指定されることを要求します。デフォルトとして最初の範囲の最小値を使用します。すべての範囲に対して検証します。
2. RunAsAny: デフォルトは指定されません。supplementalGroups の指定を許可します。

FSGroup

1. MustRunAs: 事前に割り当てられた値を使用していない場合に、少なくとも 1 つの範囲が指定されることを要求します。デフォルトとして最初の範囲の最小値を使用します。最初の範囲の最初の ID に対して検証します。
2. RunAsAny: デフォルトは指定されません。fsGroup ID の指定を許可します。

1. 使用できるすべての SCC を取得します。
2. 要求に指定されていないセキュリティーコンテキストの設定のフィールド値を生成します。
3. 利用可能な制約に対する最終的な設定を検証します。

1. 優先度が高い順。 nil は優先度 0 とみなされます。
2. 優先度が等しい場合、SCC は最も制限の多いものから少ないものの順に並べ替えられます。
3. 優先度と制限のどちらも等しい場合、SCC は名前順に並べ替えられます。

手順

1. LDAP サーバーからのすべてのグループを OpenShift Container Platform と同期するには、以下を実行します。

   $ oc adm groups sync --sync-config=config.yaml --confirm

   注記

   デフォルトでは、すべてのグループ同期操作がドライランされるので、OpenShift Container Platform Group レコードを変更するために oc adm groups sync コマンドで --confirm フラグを設定する必要があります。

手順

1. OpenShift Container Platform Group を LDAP サーバーと同期するには、以下を実行します。

   $ oc adm groups sync --type=openshift --sync-config=config.yaml --confirm

   注記

   デフォルトでは、すべてのグループ同期操作がドライランされるので、OpenShift Container Platform Group レコードを変更するために oc adm groups sync コマンドで --confirm フラグを設定する必要があります。

手順

1. LDAP グループのサブセットを OpenShift Container Platform と同期するには、以下のコマンドを使用します。

   $ oc adm groups sync --whitelist=<whitelist_file> \
                      --sync-config=config.yaml    \
                      --confirm
   $ oc adm groups sync --blacklist=<blacklist_file> \
                      --sync-config=config.yaml    \
                      --confirm
   $ oc adm groups sync <group_unique_identifier>    \
                      --sync-config=config.yaml    \
                      --confirm
   $ oc adm groups sync <group_unique_identifier>    \
                      --whitelist=<whitelist_file> \
                      --blacklist=<blacklist_file> \
                      --sync-config=config.yaml    \
                      --confirm
   $ oc adm groups sync --type=openshift             \
                      --whitelist=<whitelist_file> \
                      --sync-config=config.yaml    \
                      --confirm

   注記

   デフォルトでは、すべてのグループ同期操作がドライランされるので、OpenShift Container Platform Group レコードを変更するために oc adm groups sync コマンドで --confirm フラグを設定する必要があります。

手順

1. rfc2307_config.yaml ファイルと同期します。

   $ oc adm groups sync --sync-config=rfc2307_config.yaml --confirm

   OpenShift Container Platform は、上記の同期操作の結果として以下のグループレコードを作成します。

   rfc2307_config.yaml ファイルを使用して作成される OpenShift Container Platform Group

   apiVersion: user.openshift.io/v1
   kind: Group
   metadata:
     annotations:
       openshift.io/ldap.sync-time: 2015-10-13T10:08:38-0400 1
       openshift.io/ldap.uid: cn=admins,ou=groups,dc=example,dc=com 2
       openshift.io/ldap.url: LDAP_SERVER_IP:389 3
     creationTimestamp:
     name: admins 4
   users: 5
   - jane.smith@example.com
   - jim.adams@example.com

   1

   この OpenShift Container Platform Group と LDAP サーバーが最後に同期された時間です。ISO 6801 形式を使用します。

   2

   LDAP サーバーのグループの固有識別子です。

   3

   このグループのレコードが保存される LDAP サーバーの IP アドレスとホストです。

   4

   同期ファイルが指定するグループ名です。

   5

   グループのメンバーのユーザーです。同期ファイルで指定される名前が使用されます。

手順

1. rfc2307_config_user_defined.yaml ファイルとの同期を実行します。

   $ oc adm groups sync --sync-config=rfc2307_config_user_defined.yaml --confirm

   OpenShift Container Platform は、上記の同期操作の結果として以下のグループレコードを作成します。

   rfc2307_config_user_defined.yaml ファイルを使用して作成される OpenShift Container Platform Group

   apiVersion: user.openshift.io/v1
   kind: Group
   metadata:
     annotations:
       openshift.io/ldap.sync-time: 2015-10-13T10:08:38-0400
       openshift.io/ldap.uid: cn=admins,ou=groups,dc=example,dc=com
       openshift.io/ldap.url: LDAP_SERVER_IP:389
     creationTimestamp:
     name: Administrators 1
   users:
   - jane.smith@example.com
   - jim.adams@example.com

   1

   ユーザー定義の名前マッピングが指定するグループ名です。

手順

1. rfc2307_config_tolerating.yaml ファイルを使用して同期を実行します。

   $ oc adm groups sync --sync-config=rfc2307_config_tolerating.yaml --confirm

   OpenShift Container Platform は、上記の同期操作の結果として以下のグループレコードを作成します。

   rfc2307_config.yaml ファイルを使用して作成される OpenShift Container Platform Group

   apiVersion: user.openshift.io/v1
   kind: Group
   metadata:
     annotations:
       openshift.io/ldap.sync-time: 2015-10-13T10:08:38-0400
       openshift.io/ldap.uid: cn=admins,ou=groups,dc=example,dc=com
       openshift.io/ldap.url: LDAP_SERVER_IP:389
     creationTimestamp:
     name: admins
   users: 1
   - jane.smith@example.com
   - jim.adams@example.com

   1

   同期ファイルで指定されるグループのメンバーのユーザーです。検索中に許容されるエラーがないメンバーです。

手順

1. active_directory_config.yaml ファイルを使用して同期を実行します。

   $ oc adm groups sync --sync-config=active_directory_config.yaml --confirm

   OpenShift Container Platform は、上記の同期操作の結果として以下のグループレコードを作成します。

   active_directory_config.yaml ファイルを使用して作成される OpenShift Container Platform Group

   apiVersion: user.openshift.io/v1
   kind: Group
   metadata:
     annotations:
       openshift.io/ldap.sync-time: 2015-10-13T10:08:38-0400 1
       openshift.io/ldap.uid: admins 2
       openshift.io/ldap.url: LDAP_SERVER_IP:389 3
     creationTimestamp:
     name: admins 4
   users: 5
   - jane.smith@example.com
   - jim.adams@example.com

   1

   この OpenShift Container Platform Group と LDAP サーバーが最後に同期された時間です。ISO 6801 形式を使用します。

   2

   LDAP サーバーのグループの固有識別子です。

   3

   このグループのレコードが保存される LDAP サーバーの IP アドレスとホストです。

   4

   LDAP サーバーに一覧表示されるグループ名です。

   5

   グループのメンバーのユーザーです。同期ファイルで指定される名前が使用されます。

手順

1. augmented_active_directory_config.yaml ファイルを使用して同期を実行します。

   $ oc adm groups sync --sync-config=augmented_active_directory_config.yaml --confirm

   OpenShift Container Platform は、上記の同期操作の結果として以下のグループレコードを作成します。

   apiVersion: user.openshift.io/v1
   kind: Group
   metadata:
     annotations:
       openshift.io/ldap.sync-time: 2015-10-13T10:08:38-0400 1
       openshift.io/ldap.uid: cn=admins,ou=groups,dc=example,dc=com 2
       openshift.io/ldap.url: LDAP_SERVER_IP:389 3
     creationTimestamp:
     name: admins 4
   users: 5
   - jane.smith@example.com
   - jim.adams@example.com

   1

   この OpenShift Container Platform Group と LDAP サーバーが最後に同期された時間です。ISO 6801 形式を使用します。

   2

   LDAP サーバーのグループの固有識別子です。

   3

   このグループのレコードが保存される LDAP サーバーの IP アドレスとホストです。

   4

   同期ファイルが指定するグループ名です。

   5

   グループのメンバーのユーザーです。同期ファイルで指定される名前が使用されます。