1. 创建一个 htpasswd 文件来存储用户和密码信息。Linux 和 Windows 的操作说明。
2. 创建一个 OpenShift Container Platform secret 来代表 htpasswd 文件。
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 -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. 从 htpass-secret secret 中检索 HTPasswd 文件，并将该文件保存到您的文件系统中：

   $ oc get secret htpass-secret -ojsonpath={.data.htpasswd} -n openshift-config | base64 -d > users.htpasswd

2. 从 users.htpasswd 文件中添加或删除用户。

   • 添加一个新用户：

     $ htpasswd -bB users.htpasswd <username> <password>
     Adding password for user <username>

   • 删除一个现有用户：

     $ htpasswd -D users.htpasswd <username>
     Deleting password for user <username>

3. 使用 users.htpasswd 文件中更新的用户替换 htpass-secret secret：

   $ oc create secret generic htpass-secret --from-file=htpasswd=users.htpasswd --dry-run -o yaml -n openshift-config | oc replace -f -

4. 如果删除了一个或多个用户，您还需要为每个用户删除其现有资源。

   1. 删除用户：

      $ oc delete user <username>
      user.user.openshift.io "<username>" deleted

      请确认已删除了用户，否则如果用户的令牌还没有过期，则用户还可以继续使用其令牌。

   2. 删除用户的身份：

      $ oc delete identity my_htpasswd_provider:<username>
      identity.user.openshift.io "my_htpasswd_provider:<username>" deleted

流程

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. 使用生成的过滤器搜索目录。如果搜索返回的不是一个条目，则拒绝访问。
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 客户端身份验证作为扩展密钥类型。

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 ticket 和不使用 Kerberos ticket 的情况下登录到 OpenShift CLI（oc）：

      1. 如果您使用 kinit生成了 Kerberos ticket，请将其销毁：

         # kdestroy -c cache_name 1

         1

         请确定提供 Kerberos 缓存的名称。

      2. 使用您的 Kerberos 凭证登录到 oc：

         # oc login

         在提示符后输入您的 Kerberos 用户名和密码。

      3. 注销 oc 工具：

         # oc logout

      4. 使用您的 Kerberos 凭证获得一个 ticket：

         # kinit

         在提示符后输入您的 Kerberos 用户名和密码。

      5. 确认您可以登录到 oc：

         # oc login

         如果配置正确，您会在不需要单独输入凭证的情况下成功登录。

流程

1. 在 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 和客户端 Secret。您需要使用这些值来完成身份提供程序配置。

流程

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 控制台的 (?)访问此页面。 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 控制台的 (?)访问此页面。 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 控制台的 (?)访问此页面。 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. 创建包含用于签发新证书的证书颁发机构的 ConfigMap：

   $ oc create configmap custom-ca \
        --from-file=ca-bundle.crt=</path/to/example-ca.crt> \1
        -n openshift-config

   1

   </path/to/cert.crt> 是 CA 在本地文件系统中的路径。

2. 使用新创建的 ConfigMap 更新集群范围代理配置：

   $ oc patch proxy/cluster \
        --type=merge \
        --patch='{"spec":{"trustedCA":{"name":"custom-ca"}}}'

3. 创建包含通配符证书和密钥的 secret ：

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

   1

   <certificate> 是将要包含证书和私钥的 secret 的名称。

   2

   </path/to/cert.crt> 是证书在本地文件系统中的路径。

   3

   </path/to/cert.key> 是与此证书关联的私钥的路径。

4. 使用新创建的 secret 更新 Ingress Controller 配置：

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

   1

   将 <certificate> 替换为上一步中用于 secret 的名称。

流程

1. 创建一个包含 openshift-config 命名空间中证书和密钥的 secret。

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

   1

   <certificate> 是将要包含该证书的 secret 的名称。

   2

   </path/to/cert.crt> 是证书在本地文件系统中的路径。

   3

   </path/to/cert.key> 是与此证书关联的私钥的路径。

2. 更新 API 服务器以引用所创建的 secret。

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

   1

   将 <hostname> 替换为 API 服务器应为其提供证书的主机名。

   2

   将 <certificate> 替换为上一步中用于 secret 的名称。

3. 检查 apiserver/cluster 对象并确认该 secret 现已被引用。

   $ 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> 是生成的 secret 的名称，该 secret 包含证书和密钥对。为方便起见，建议您使用与 <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. 在集群为服务生成 secret 后，PodSpec 可以挂载它，Pod 也会在可用后运行。

流程

1. 使用 service.beta.openshift.io/inject-cabundle=true 注解 ConfigMap。

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

   1

   将 <configmap-name> 替换为要注解的 ConfigMap 的名称。

   注意

   在 volumeMount 中明确引用 service-ca.crt 键会使 Pod 无法启动，直到 ConfigMap 通过 CA 捆绑包注入后为止。

   例如，若要注解 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. 检查该服务以确定包含证书的 secret。这可以在 service-cert-secret-name 注解中找到，如下所示。

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

2. 删除为服务生成的 secret。此过程将自动重新创建 secret。

   $ oc delete secret <secret> 1

   1

   将 <secret> 替换为前一步中的 secret 名称。

3. 通过获取新 secret 并检查 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

   警告

   此命令会导致服务中断，因为它将遍历并删除每个命名空间中运行的 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 - 如果不使用预分配值，则需要至少指定一个范围。使用第一个范围内的最小值作为默认值。针对所有范围进行验证。
2. RunAsAny - 不提供默认值。允许指定任何 supplementalGroups。

FSGroup

1. MustRunAs - 如果不使用预分配值，则需要至少指定一个范围。使用第一个范围内的最小值作为默认值。针对第一个范围内的第一个 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

   注意

   默认情况下，所有组同步操作都是空运行（dry-run），因此您必须在 oc adm groups sync 命令上设置 --confirm 标志，才能更改 OpenShift Container Platform 组记录。

流程

1. 将 OpenShift Container Platform 组与 LDAP 服务器同步：

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

   注意

   默认情况下，所有组同步操作都是空运行（dry-run），因此您必须在 oc adm groups sync 命令上设置 --confirm 标志，才能更改 OpenShift Container Platform 组记录。

流程

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

   注意

   默认情况下，所有组同步操作都是空运行（dry-run），因此您必须在 oc adm groups sync 命令上设置 --confirm 标志，才能更改 OpenShift Container Platform 组记录。

流程

1. 使用 rfc2307_config.yaml 文件运行同步：

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

   OpenShift Container Platform 创建以下组记录作为上述同步操作的结果：

   使用 rfc2307_config.yaml 文件创建的 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 组与 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 组

   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 组

   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 组

   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 组与 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 组与 LDAP 服务器最后一次同步的时间，采用 ISO 6801 格式。

   2

   LDAP 服务器上组的唯一标识符。

   3

   存储该组记录的 LDAP 服务器的 IP 地址和主机。

   4

   根据同步文件指定的组的名称。

   5

   属于组的成员的用户，名称由同步文件指定。