身份验证

OpenShift Container Platform 中的用户是可以向 OpenShift Container Platform API 发出请求的实体。OpenShift Container Platform 用户对象代表操作者，通过向它们或所在的组添加角色为其授予系统中的权限。通常，这代表与 OpenShift Container Platform 交互的开发人员或管理员的帐户。

可能存在的用户类型有几种：

每一用户必须通过某种形式的身份验证才能访问 OpenShift Container Platform。无身份验证或身份验证无效的 API 请求会被看作为由 anonymous 系统用户发出的请求。经过身份验证后，策略决定用户被授权执行的操作。

用户可以分配到一个或多个组中，每个组代表特定的用户集合。在管理授权策略时，可使用组同时为多个用户授予权限，例如允许访问一个项目中的多个对象，而不必单独授予用户权限。

除了明确定义的组外，还有系统组或虚拟组，它们由集群自动置备。

以下列出了最重要的默认虚拟组：

对 OpenShift Container Platform API 的请求通过以下方式进行身份验证：

任何具有无效访问令牌或无效证书的请求都会被身份验证层以 401 错误形式拒绝。

如果没有出示访问令牌或证书，身份验证层会将 system:anonymous 虚拟用户和 system:unauthenticated 虚拟组分配给请求。这使得授权层能够决定匿名用户可以发出哪些（如有）请求。

oc get route oauth-openshift -n openshift-authentication -o json | jq .spec.host

OpenShift Container Platform 监控证书是否正确有效，以了解其发布和管理的集群证书。OpenShift Container Platform 警报框架包含有助于识别证书问题何时发生的规则。这些规则由以下检查组成：

用途

集群以外的客户端通过 api.<cluster_name>.<base_domain> 可访问 API 服务器。您可能希望客户端使用不同主机名访问 API 服务器，无需向客户端发布集群管理的证书颁发机构 (CA) 证书。管理员必须在提供内容时设置 API 服务器使用的自定义默认证书。

位置

用户提供的证书必须在 openshift-config 命名空间中的 kubernetes.io/tls 类型 Secret 中提供。更新 API 服务器集群配置( apiserver/cluster 资源），以启用用户提供的证书。

管理

用户提供的证书由用户管理。

过期

用户提供的证书由用户管理。

自定义

根据需要，更新包含用户管理的证书的 secret。

用途

通过代理证书，用户可以指定，在平台组件创建出口连接时使用的一个或多个自定义证书颁发机构 (CA) 证书。

Proxy 对象的 trustedCA 字段是对包含用户提供的可信证书颁发机构 (CA) 捆绑包的 ConfigMap 的引用。这个捆绑包与 Red Hat Enterprise Linux CoreOS (RHCOS) 信任捆绑包合并，并注入到生成出口 HTTPS 调用的平台组件的信任存储中。例如，image-registry-operator 调用外部镜像 registry 来下载镜像。如果没有指定 trustedCA，则只有 RHCOS 信任的捆绑包用于代理 HTTPS 连接。如果您想要使用自己的证书基础架构，请向 RHCOS 信任捆绑包提供自定义 CA 证书。

trustedCA 字段应当仅由代理验证器使用。验证器负责从所需的键 ca-bundle.crt 中读取证书捆绑包，并将其复制到 openshift-config-managed 命名空间中名为trusted-ca-bundle 的 ConfigMap 中。被 trustedCA 引用的 ConfigMap 的命名空间是 openshift-config:

apiVersion: v1
	kind: ConfigMap
 metadata:
	name: user-ca-bundle
	namespace: openshift-config
	data:
	  ca-bundle.crt: |
    -----BEGIN CERTIFICATE-----
    Custom CA certificate bundle.
    -----END CERTIFICATE-----

在安装过程中管理代理证书

安装程序配置的 additionalTrustBundle 值用于在安装过程中指定任何代理信任的 CA 证书。例如：

$ cat install-config.yaml
. . .
proxy:
  httpProxy: http://<HTTP_PROXY>
  httpsProxy: https://<HTTPS_PROXY>
additionalTrustBundle: |
    -----BEGIN CERTIFICATE-----
   <MY_HTTPS_PROXY_TRUSTED_CA_CERT>
    -----END CERTIFICATE-----
. . .

位置

用户提供的信任捆绑包以 ConfigMap 的形式出现。ConfigMap 被挂载到进行 HTTPS 调用的平台组件的文件系统中。通常，Operator 会将 ConfigMap 挂载到 /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem，但代理并不要求这样做。代理可以修改或检查 HTTPS 连接。在这两种情况下，代理都必须为连接生成新证书并为新证书签名。

完整的代理支持意味着连接到指定的代理服务器并信任它所生成的所有签名。因此，需要让用户指定一个信任的根用户，以便任何连接到该可信根的证书链都被信任。

如果使用 RHCOS 信任捆绑包，请将 CA 证书放在 /etc/pki/ca-trust/source/anchors 中。

详情请参阅 Red Hat Enterprise Linxu 文档的使用共享系统证书。

过期

用户为用户提供的信任捆绑包设定了过期期限。

默认到期条件由 CA 证书本身定义。在 OpenShift Container Platform 或 RHCOS 使用前，由 CA 管理员为证书配置这个证书。

服务

默认情况下，所有使用出口 HTTPS 调用的平台组件将使用 RHCOS 信任捆绑包。如果定义了 trustedCA，它将会被使用。

任何在 RHCOS 节点上运行的服务都可以使用该节点的信任捆绑包。

管理

这些证书由系统而不是用户管理。

自定义

更新用户提供的信任捆绑包包括：

将 CA 证书写入 RHCOS 信任捆绑包的机制与将其它文件写入 RHCOS（使用 MachineConfig）完全相同。当 Machine Config Operator (MCO) 应用包含新 CA 证书的新 MachineConfig 时，节点将重启。在下次引导过程中，服务 coreos-update-ca-trust.service 在 RHCOS 节点上运行，该节点上使用新的 CA 证书自动更新信任捆绑包。例如：

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 50-examplecorp-ca-cert
spec:
  config:
    ignition:
      version: 2.2.0
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUVORENDQXh5Z0F3SUJBZ0lKQU51bkkwRDY2MmNuTUEwR0NTcUdTSWIzRFFFQkN3VUFNSUdsTVFzd0NRWUQKV1FRR0V3SlZVekVYTUJVR0ExVUVDQXdPVG05eWRHZ2dRMkZ5YjJ4cGJtRXhFREFPQmdOVkJBY01CMUpoYkdWcApBMmd4RmpBVUJnTlZCQW9NRFZKbFpDQklZWFFzSUVsdVl5NHhFekFSQmdOVkJBc01DbEpsWkNCSVlYUWdTVlF4Ckh6QVpCZ05WQkFNTUVsSmxaQ0JJWVhRZ1NWUWdVbTl2ZENCRFFURWhNQjhHQ1NxR1NJYjNEUUVKQVJZU2FXNW0KWGpDQnBURUxNQWtHQTFVRUJoTUNWVk14RnpBVkJnTlZCQWdNRGs1dmNuUm9JRU5oY205c2FXNWhNUkF3RGdZRApXUVFIREFkU1lXeGxhV2RvTVJZd0ZBWURWUVFLREExU1pXUWdTR0YwTENCSmJtTXVNUk13RVFZRFZRUUxEQXBTCkFXUWdTR0YwSUVsVU1Sc3dHUVlEVlFRRERCSlNaV1FnU0dGMElFbFVJRkp2YjNRZ1EwRXhJVEFmQmdrcWhraUcKMHcwQkNRRVdFbWx1Wm05elpXTkFjbVZrYUdGMExtTnZiVENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUApCRENDQVFvQ2dnRUJBTFF0OU9KUWg2R0M1TFQxZzgwcU5oMHU1MEJRNHNaL3laOGFFVHh0KzVsblBWWDZNSEt6CmQvaTdsRHFUZlRjZkxMMm55VUJkMmZRRGsxQjBmeHJza2hHSUlaM2lmUDFQczRsdFRrdjhoUlNvYjNWdE5xU28KSHhrS2Z2RDJQS2pUUHhEUFdZeXJ1eTlpckxaaW9NZmZpM2kvZ0N1dDBaV3RBeU8zTVZINXFXRi9lbkt3Z1BFUwpZOXBvK1RkQ3ZSQi9SVU9iQmFNNzYxRWNyTFNNMUdxSE51ZVNmcW5obzNBakxRNmRCblBXbG82MzhabTFWZWJLCkNFTHloa0xXTVNGa0t3RG1uZTBqUTAyWTRnMDc1dkNLdkNzQ0F3RUFBYU5qTUdFd0hRWURWUjBPQkJZRUZIN1IKNXlDK1VlaElJUGV1TDhacXczUHpiZ2NaTUI4R0ExVWRJd1FZTUJhQUZIN1I0eUMrVWVoSUlQZXVMOFpxdzNQegpjZ2NaTUE4R0ExVWRFd0VCL3dRRk1BTUJBZjh3RGdZRFZSMFBBUUgvQkFRREFnR0dNQTBHQ1NxR1NJYjNEUUVCCkR3VUFBNElCQVFCRE52RDJWbTlzQTVBOUFsT0pSOCtlbjVYejloWGN4SkI1cGh4Y1pROGpGb0cwNFZzaHZkMGUKTUVuVXJNY2ZGZ0laNG5qTUtUUUNNNFpGVVBBaWV5THg0ZjUySHVEb3BwM2U1SnlJTWZXK0tGY05JcEt3Q3NhawpwU29LdElVT3NVSks3cUJWWnhjckl5ZVFWMnFjWU9lWmh0UzV3QnFJd09BaEZ3bENFVDdaZTU4UUhtUzQ4c2xqCjVlVGtSaml2QWxFeHJGektjbGpDNGF4S1Fsbk92VkF6eitHbTMyVTB4UEJGNEJ5ZVBWeENKVUh3MVRzeVRtZWwKU3hORXA3eUhvWGN3bitmWG5hK3Q1SldoMWd4VVp0eTMKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
        filesystem: root
        mode: 0644
        path: /etc/pki/ca-trust/source/anchors/examplecorp-ca.crt

机器的信任存储还必须支持更新节点的信任存储。

续订

没有 Operator 可以自动更新 RHCOS 节点上的证书。

用途

service-ca 是部署 OpenShift Container Platform 集群时创建自签名 CA 的一个 Operator。

过期

不支持自定义过期条件。自签名 CA 存储在一个限定名为 service-ca/signing-key 的 secret 中。它在 tls.crt (certificate(s))、tls.key (private key) 和 ca-bundle.crt (CA bundle) 项中。

其他服务可通过使用 service.beta.openshift.io/serving-cert-secret-name: <secret name> 注解一个服务资源来请求一个 service serving 证书。作为响应，Operator 会为指定的 secret 生成一个新证书， tls.crt，以及一个私钥，tls.key。该证书的有效期为两年。

其他服务可通过使用 service.beta.openshift.io/inject-cabundle:true 注解来请求将服务 CA 的 CA 捆绑包注入 APIService 或 ConfigMap 资源，以支持通过服务 CA 生成的证书。作为响应，Operator 将其当前 CA 捆绑包写入 APIService 的 CABundle 字段，或将 service-ca.crt 写入一个 ConfigMap。

自 OpenShift Container Platform 4.3.5 起，支持自动轮转，并将其向后移植到一些 4.2.z 和 4.3.z 版本中。对于任何支持自动轮转的版本，服务 CA 证书在 26 个月内有效，并在有效期少于 13 个月时进行刷新。如果需要，您可以手动刷新服务 CA。

服务 CA 26 个月的过期时间比支持的 OpenShift Container Platform 集群的预期升级间隔更长，因此使用服务 CA 证书的非 control plane 系统将会在 CA 轮转后刷新。这会发生在轮转前使用的 CA 过期前。

管理

这些证书由系统而不是用户管理。

服务

使用服务 CA 证书的服务包括：

这不是一个完整的列表。

用途

节点证书由集群签名; 证书来自由 bootstrap 过程生成的证书颁发机构 (CA)。安装集群后，节点证书会被自动轮转。

管理

这些证书由系统而不是用户管理。

用途

OpenShift Container Platform 4 及之后的版本中的 kubelet 使用位于 /etc/kubernetes/kubeconfig 中的 bootstrap 证书来启动 bootstrap。然后是 bootstrap 初始化过程 和 kubelet 授权来创建一个 CSR。

在此过程中，kubelet 在通过 bootstrap 频道进行通信时会生成一个 CSR。控制器管理器为 CSR 签名，以生成 kubelet 管理的证书。

管理

这些证书由系统而不是用户管理。

过期

此 bootstrap CA 有效时间为 10 年。

kubelet 管理的证书的有效期为一年，并在一年经过了大约 80% 时进行自动轮转。

自定义

您无法自定义 bootstrap 证书。

用途

etcd 证书由 etcd-signer 签名; 证书来自由 bootstrap 过程生成的证书颁发机构 (CA)。

位置

过期

CA 证书有效期为 10 年。对等证书、客户端证书和服务器证书的有效期为三年。

管理

这些证书由系统而不是用户管理。

服务

etcd 证书用于 etcd 对等成员间通信的加密，以及加密客户端流量。以下证书由 etcd 和其他与 etcd 通信的进程生成和使用：

管理

OpenShift Lifecycle Manager (OLM) 组件(olm-operator、catalog-operator、packageserver 和 marketplace-operator) 的所有证书均由系统管理。

通过 OLM 安装的 Operator 如果提供 API 服务，就可以为它们生成证书。packageserver 就是一个例子。

openshift-operator-lifecycle-manager 命名空间中的证书由 OLM 管理，但需要验证或修改 webhook 的 Operator 所使用的证书除外。

安装了验证或修改 Webhook 的 Operator 目前需要自己管理这些证书。它们不要求用户管理证书。

OLM 不会更新它在代理环境中管理的 Operator 证书。这些证书必须由用户通过订阅配置进行管理。。

用途

应用程序通常通过 <route_name>.apps.<cluster_name>.<base_domain> 来公开。<cluster_name> 和 <base_domain> 来自于按照的 config 文件。 <route_name> 是路由的主机（如果指定），或路由名。例如，hello-openshift-default.apps.username.devcluster.openshift.com。 hello-openshift 是路由名称，路由位于 default 命名空间。您可能希望客户端访问应用程序而无需向客户端发布集群管理的 CA 证书。在提供应用程序内容时，管理员必须设置自定义默认证书。

位置

用户提供的证书必须在 openshift-config 命名空间中的 kubernetes.io/tls 类型 Secret 中提供。更新 openshift-ingress-operator 命名空间中的 ingresscontroller.operator/default 资源来启用使用 user-provided 证书的功能。

管理

用户提供的证书由用户管理。

过期

用户提供的证书由用户管理。

服务

在集群中部署的应用程序使用用户提供的证书作为默认入口。

自定义

根据需要，更新包含用户管理的证书的 secret。

用途

Ingress Operator 使用以下证书：

位置

为了保证对 Ingress Operator 和 Ingress Controller 指标的访问安全，Ingress Operator 使用 service serving 证书。Operator 为自己的指标从 service-ca 控制器请求证书，service-ca 控制器将证书放置在 openshift-ingress -operator 命名空间中的名为 metrics-tls 的 secret 中。另外，Ingress Operator 会为每个 Ingress Controller 请求一个证书，service-ca 控制器会将证书放在名为 router-metrics-certs-<name> 的 secret 中，其中 <name> 是 Ingress Controller 的名称（在 openshift-ingress 命名空间中）。

每个 Ingress Controller 都有一个默认证书，用于没有指定其自身证书的安全路由。除非指定了自定义证书，Operator 默认使用自签名证书。Operator 使用自己的自签名签名证书为其生成的任何默认证书签名。Operator 生成此签名证书，并将其置于 openshift-ingress-operator 命名空间中的名为 router-ca 的 secret 中。当 Operator 生成默认证书时，它会将默认证书放在 openshift-ingress 命名空间的名为 router-certs-<name>（其中 <name> 是 Ingress Controller 的名称）的 secret 中。

工作流

空的 defaultCertificate 项会使 Ingress Operator 使用它自己签名的 CA 来为指定的域生成 serving 证书。

Ingress Operator 生成的默认 CA 证书和密钥。用来为 Operator 生成的默认 serving 证书签名。

在默认工作流中，通配符默认服务证书，由 Ingress Operator 创建，并使用生成的默认 CA 证书签名。在自定义工作流中，这是用户提供的证书。

路由器部署。使用 secrets/router-certs-default 中的证书作为其默认前端服务器证书。

在默认工作流中，通配符默认服务证书（公共和私有组件）的内容在此复制，以启用 OAuth 集成。在自定义工作流中，这是用户提供的证书。

包含 Operator 生成的默认 CA 证书（公共部分）的资源; 由 OAuth 和 Web 控制台读取以建立信任。这个对象将在以后的发行版本中被删除。

默认服务证书的公共（certificate）部分。替换 configmaps/router-ca 资源。

用户使用对 ingresscontroller serving 证书签名的 CA 证书更新集群代理配置。这可让 auth、console 和 registry 等组件信任 serving 证书。

包含合并的 Red Hat Enterprise Linux CoreOS (RHCOS) 和用户提供的 CA 捆绑包（如果未提供用户捆绑包）的集群范围可信 CA 捆绑包。

自定义 CA 证书捆绑包,用于指示其他组件（如 auth 和 console）信任配置了自定义证书的 ingresscontroller。

trustedCA 字段用来引用用户提供的 CA 捆绑包。

Cluster Network Operator 将可信 CA 捆绑包注入 proxy-ca ConfigMap。

OpenShift Container Platform 4.3 及更早的版本使用 router-ca。

过期

Ingress Operator 证书的过期条件如下：

您不能自定义 Ingress Operator 或 service-ca 控制器创建的证书的过期条款。

安装 OpenShift Container Platform 时，不能为 Ingress Operator 或 service-ca 控制器创建的证书指定过期条款。

服务

Prometheus 使用的用来确保指标安全的证书。

Ingress Operator 使用它的签名证书来为 Ingress Controller 签名默认证书，您不要为其设置自定义默认证书。

使用安全路由的集群组件可使用默认 Ingress Controller 默认证书。

通过安全路由进入集群的入口使用 Ingress Controller 的默认证书，该证书将访问该路由，除非该路由指定了自己的证书。

管理

入口证书由用户管理。如需 更多信息，请参阅重新放置默认入口证书。

续订

service-ca 控制器自动轮转其发放的证书。但是，可以使用 oc delete secret <secret> 来手动轮转 service serving 证书。

Ingress Operator 不轮转其自身的签名证书或它生成的默认证书。Operator 生成的默认证书的目的是作为您配置的自定义默认证书的占位者。

OpenShift Container Platform master 包含内置的 OAuth 服务器。用户获取 OAuth 访问令牌来对自身进行 API 身份验证。

有人请求新的 OAuth 令牌时，OAuth 服务器使用配置的身份提供程序来确定提出请求的人的身份。

然后，它会确定该身份所映射到的用户，为该用户创建一个访问令牌，再返回要使用的令牌。

OAuth 服务器支持标准的授权代码授权和隐式授权 OAuth 授权流。

在使用隐式授权流 (response_type=token) 以及配置为请求 WWW-Authenticate 质询（如 openshift-challenging-client）的 client_id 以请求 OAuth 令牌时，可能来自 /oauth/authorize 的服务器响应及它们的处理方式如下方所列：

内部 OAuth 服务器可使用几个配置选项。

您可以配置内部 OAuth 服务器令牌期间的默认选项。

如果默认时间不足，可以使用以下步骤进行修改。

如果需要其他 OAuth 客户端来管理 OpenShift Container Platform 集群的身份验证，则可以注册一个。

在 OpenShift Container Platform 中运行的应用程序可能需要发现有关内置 OAuth 服务器的信息。例如，它们可能需要发现 <namespace_route> 的哪个地址没有手动配置。为此，OpenShift Container Platform 实施了 IETF OAuth 2.0 授权服务器元数据草案规范。

因此，集群中运行的任何应用程序都可以向 https://openshift.default.svc/.well-known/oauth-authorization-server 发出 GET 请求来获取以下信息：

{
  "issuer": "https://<namespace_route>", 1
  "authorization_endpoint": "https://<namespace_route>/oauth/authorize", 2
  "token_endpoint": "https://<namespace_route>/oauth/token", 3
  "scopes_supported": [ 4
    "user:full",
    "user:info",
    "user:check-access",
    "user:list-scoped-projects",
    "user:list-projects"
  ],
  "response_types_supported": [ 5
    "code",
    "token"
  ],
  "grant_types_supported": [ 6
    "authorization_code",
    "implicit"
  ],
  "code_challenge_methods_supported": [ 7
    "plain",
    "S256"
  ]
}

在有些情况下，API 服务器会返回一个 unexpected condition 错误消息；若不直接访问 API 主日志，很难对此消息进行调试。该错误的基本原因被有意遮挡，以避免向未经身份验证的用户提供有关服务器状态的信息。

这些错误的子集与服务帐户 OAuth 配置问题有关。这些问题在非管理员用户可查看的事件中捕获。OAuth 期间遇到 unexpected condition 服务器错误时，可运行 oc get events 在 ServiceAccount 下查看这些事件。

以下示例警告缺少正确 OAuth 重定向 URI 的服务帐户：

$ oc get events | grep ServiceAccount
1m         1m          1         proxy                    ServiceAccount                                  Warning   NoSAOAuthRedirectURIs   service-account-oauth-client-getter   system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>

运行 oc describe sa/<service-account-name> 可以报告与给定服务帐户名称相关的任何 OAuth 事件。

$ oc describe sa/proxy | grep -A5 Events
Events:
  FirstSeen     LastSeen        Count   From                                    SubObjectPath   Type            Reason                  Message
  ---------     --------        -----   ----                                    -------------   --------        ------                  -------
  3m            3m              1       service-account-oauth-client-getter                     Warning         NoSAOAuthRedirectURIs   system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>

下方列出可能的事件错误：

无重定向 URI 注解或指定了无效的 URI

Reason                  Message
NoSAOAuthRedirectURIs   system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>

指定了无效的路由

Reason                  Message
NoSAOAuthRedirectURIs   [routes.route.openshift.io "<name>" not found, system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]

指定了无效的引用类型

Reason                  Message
NoSAOAuthRedirectURIs   [no kind "<name>" is registered for version "v1", system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]

缺少 SA 令牌

Reason                  Message
NoSAOAuthTokens         system:serviceaccount:myproject:proxy has no tokens

默认情况下，集群中只有 kubeadmin 用户。要指定身份提供程序，您必须创建一个自定义资源 (CR) 来描述该身份提供程序并把它添加到集群中。

您可以配置以下类型的身份提供程序：

定义了身份提供程序后，可以使用 RBAC 来定义并应用权限。

在定义了身份提供程序并创建新的 cluster-admin 用户后，您可以移除 kubeadmin 来提高集群安全性。

以下是所有身份提供程序通用的参数：

以下自定义资源 (CR) 显示用来配置身份提供程序的参数和默认值。示例中使用了 HTPasswd 身份提供程序。

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: my_identity_provider 1
    mappingMethod: claim 2
    type: HTPasswd
    htpasswd:
      fileData:
        name: htpass-secret 3

配置 keystone 身份提供程序，将 OpenShift Container Platform 集群与 Keystone 集成以启用共享身份验证，用配置的 OpenStack Keystone v3 服务器将用户存储到内部数据库中。此配置允许用户使用其 Keystone 凭证登录 OpenShift Container Platform。

Keystone 是一个提供身份、令牌、目录和策略服务的 OpenStack 项目。

您可以配置与 Keystone 的集成，以便 OpenShift Container Platform 的新用户基于 Keystone 用户名或者唯一 Keystone ID。使用这两种方法时，用户可以输入其 Keystone 用户名和密码进行登录。使 OpenShift Container Platform 用户基于 Keystone ID 更为安全。如果删除了某一 Keystone 用户并使用其用户名创建了新的 Keystone 用户，新用户或许能够访问旧用户的资源。

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: keystoneidp 1
    mappingMethod: claim 2
    type: Keystone
    keystone:
      domainName: default 3
      url: https://keystone.example.com:5000 4
      ca: 5
        name: ca-config-map
      tlsClientCert: 6
        name: client-cert-secret
      tlsClientKey: 7
        name: client-key-secret

配置 ldap 身份提供程序，使用简单绑定身份验证来针对 LDAPv3 服务器验证用户名和密码。

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

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

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

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

配置 basic-authentication 身份提供程序，以便用户使用针对远程身份提供程序验证的凭证来登录 OpenShift Container Platform。基本身份验证是一种通用后端集成机制。

{"error":"Error message"}

{"sub":"userid"} 1

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: basicidp 1
    mappingMethod: claim 2
    type: BasicAuth
    basicAuth:
      url: https://www.example.com/remote-idp 3
      ca: 4
        name: ca-config-map
      tlsClientCert: 5
        name: client-cert-secret
      tlsClientKey: 6
        name: client-key-secret

<VirtualHost *:443>
  # CGI Scripts in here
  DocumentRoot /var/www/cgi-bin

  # SSL Directives
  SSLEngine on
  SSLCipherSuite PROFILE=SYSTEM
  SSLProxyCipherSuite PROFILE=SYSTEM
  SSLCertificateFile /etc/pki/tls/certs/localhost.crt
  SSLCertificateKeyFile /etc/pki/tls/private/localhost.key

  # Configure HTTPD to execute scripts
  ScriptAlias /basic /var/www/cgi-bin

  # Handles a failed login attempt
  ErrorDocument 401 /basic/fail.cgi

  # Handles authentication
  <Location /basic/login.cgi>
    AuthType Basic
    AuthName "Please Log In"
    AuthBasicProvider file
    AuthUserFile /etc/httpd/conf/passwords
    Require valid-user
  </Location>
</VirtualHost>

#!/bin/bash
echo "Content-Type: application/json"
echo ""
echo '{"sub":"userid", "name":"'$REMOTE_USER'"}'
exit 0

#!/bin/bash
echo "Content-Type: application/json"
echo ""
echo '{"error": "Login failure"}'
exit 0

curl --cacert /path/to/ca.crt --cert /path/to/client.crt --key /path/to/client.key -u <user>:<password> -v https://www.example.com/remote-idp

{"sub":"userid"}

配置 request-header 身份提供程序，标识请求标头值中的用户，例如 X-Remote-User。它通常与设定请求标头值的身份验证代理一起使用。

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: requestheaderidp 1
    mappingMethod: claim 2
    type: RequestHeader
    requestHeader:
      challengeURL: "https://www.example.com/challenging-proxy/oauth/authorize?${query}" 3
      loginURL: "https://www.example.com/login-proxy/oauth/authorize?${query}" 4
      ca: 5
        name: ca-config-map
      clientCommonNames: 6
      - my-auth-proxy
      headers: 7
      - X-Remote-User
      - SSO-User
      emailHeaders: 8
      - X-Remote-User-Email
      nameHeaders: 9
      - X-Remote-User-Display-Name
      preferredUsernameHeaders: 10
      - X-Remote-User-Login

配置 github 身份提供程序，针对 GitHub 或 GitHub Enterprise 的 OAuth 身份验证服务器验证用户名和密码。OAuth 可以协助 OpenShift Container Platform 和 GitHub 或 GitHub Enterprise 之间的令牌交换流。

您可以使用 GitHub 集成来连接 GitHub 或 GitHub Enterprise。对于 GitHub Enterprise 集成，您必须提供实例的 hostname，并可选择提供要在服务器请求中使用的 ca 证书捆绑包。

配置 GitHub 身份验证后，用户可使用 GitHub 凭证登录 OpenShift Container Platform。为防止具有任何 GitHub 用户 ID 的任何人登录 OpenShift Container Platform 集群，您可以将访问权利限制给仅属于特定 GitHub 组织的用户。

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: githubidp 1
    mappingMethod: claim 2
    type: GitHub
    github:
      ca: 3
        name: ca-config-map
      clientID: {...} 4
      clientSecret: 5
        name: github-secret
      hostname: ... 6
      organizations: 7
      - myorganization1
      - myorganization2
      teams: 8
      - myorganization1/team-a
      - myorganization2/team-b

配置 gitlab 身份提供程序，使用 GitLab.com 或任何其他 GitLab 实例作为身份提供程序。如果使用 GitLab 版本 7.7.0 到 11.0，您可以使用 OAuth 集成进行连接。如果使用 GitLab 版本 11.1 或更高版本，您可以使用 OpenID Connect (OIDC) 进行连接，而不使用 OAuth。

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: gitlabidp 1
    mappingMethod: claim 2
    type: GitLab
    gitlab:
      clientID: {...} 3
      clientSecret: 4
        name: gitlab-secret
      url: https://gitlab.com 5
      ca: 6
        name: ca-config-map

配置 google 身份提供程序，使用 Google 的 OpenID Connect 集成。

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: googleidp 1
    mappingMethod: claim 2
    type: Google
    google:
      clientID: {...} 3
      clientSecret: 4
        name: google-secret
      hostedDomain: "example.com" 5

配置 oidc 身份提供程序，使用授权代码流与 OpenID Connect 身份提供程序集成。

您可以将 Red Hat Single Sign-On 配置为 OpenShift Container Platform 的 OpenID Connect 身份提供程序。

默认情况下，需要 openid 范围。如果必要，可在 extraScopes 字段中指定额外的范围。

声明可读取自从 OpenID 身份提供程序返回的 JWT id_token；若有指定，也可读取自从 UserInfo URL 返回的 JSON。

必须至少配置一个声明，以用作用户的身份。标准的身份声明是 sub。

您还可以指定将哪些声明用作用户的首选用户名、显示名称和电子邮件地址。如果指定了多个声明，则使用第一个带有非空值的声明。标准的声明是：

如需更多信息，请参阅 OpenID 声明文档。

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: oidcidp 1
    mappingMethod: claim 2
    type: OpenID
    openID:
      clientID: ... 3
      clientSecret: 4
        name: idp-secret
      claims: 5
        preferredUsername:
        - preferred_username
        name:
        - name
        email:
        - email
      issuer: https://www.idp-issuer.com 6

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: oidcidp
    mappingMethod: claim
    type: OpenID
    openID:
      clientID: ...
      clientSecret:
        name: idp-secret
      ca: 1
        name: ca-config-map
      extraScopes: 2
      - email
      - profile
      extraAuthorizeParameters: 3
        include_granted_scopes: "true"
      claims:
        preferredUsername: 4
        - preferred_username
        - email
        name: 5
        - nickname
        - given_name
        - name
        email: 6
        - custom_email_claim
        - email
      issuer: https://www.idp-issuer.com

默认 API 服务器证书由内部 OpenShift Container Platform 集群 CA 发布。默认情况下，位于集群外的客户端无法验证 API 服务器的证书。此证书可以替换为由客户端信任的 CA 发布的证书。

基于角色的访问控制 (RBAC) 对象决定是否允许用户在项目内执行给定的操作。

集群管理员可以使用集群角色和绑定来控制谁对 OpenShift Container Platform 平台本身和所有项目具有各种访问权限等级。

开发人员可以使用本地角色和绑定来控制谁有权访问他们的项目。请注意，授权是与身份验证分开的一个步骤，身份验证更在于确定执行操作的人的身份。

授权通过使用以下几项来管理：

控制授权的 RBAC 角色和绑定有两个级别：

集群角色绑定是存在于集群级别的绑定。角色绑定存在于项目级别。集群角色 view 必须使用本地角色绑定来绑定到用户，以便该用户能够查看项目。只有集群角色不提供特定情形所需的权限集合时才应创建本地角色。

这种双级分级结构允许通过集群角色在多个项目间重复使用，同时允许通过本地角色在个别项目中自定义。

在评估过程中，同时使用集群角色绑定和本地角色绑定。例如：

9.1.1. 默认集群角色

OpenShift Container Platform 包括了一组默认的集群角色，您可以在集群范围或本地将它们绑定到用户和组。若有必要，可以手动修改默认集群角色，但每次重启 master 节点时都必须执行额外的步骤。

默认集群角色	描述
admin	项目管理者。如果在本地绑定中使用，则 admin 有权查看项目中的任何资源，并且修改项目中除配额外的任何资源。
basic-user	此用户可以获取有关项目和用户的基本信息。
cluster-admin	此超级用户可以在任意项目中执行任何操作。当使用本地绑定来绑定一个用户时，这些用户可以完全控制项目中每一资源的配额和所有操作。
cluster-status	此用户可以获取基本的集群状态信息。
edit	此用户可以修改项目中大多数对象，但无权查看或修改角色或绑定。
self-provisioner	此用户可以创建自己的项目。
view	此用户无法进行任何修改，但可以查看项目中的大多数对象。不能查看或修改角色或绑定。

请注意本地和集群绑定之间的区别。例如，如果使用本地角色绑定将 cluster-admin 角色绑定到一个用户，这可能看似该用户具有了集群管理员的特权。事实并非如此。将 cluster-admin 绑定到项目里的某一用户，仅会将该项目的超级管理员特权授予这一用户。该用户具有集群角色 admin 的权限，以及该项目的一些额外权限，例如能够编辑项目的速率限制。通过 web 控制台 UI 操作时此绑定可能会令人混淆，因为它不会列出绑定到真正集群管理员的集群角色绑定。然而，它会列出可用来本地绑定 cluster-admin 的本地角色绑定。

下方展示了集群角色、本地角色、集群角色绑定、本地角色绑定、用户、组和服务帐户之间的关系。

Kubernetes 命名空间提供设定集群中资源范围的机制。Kubernetes 文档中提供有关命名空间的更多信息。

命名空间为以下对象提供唯一范围：

系统中的大多数对象都通过命名空间来设定范围，但一些对象不在此列且没有命名空间，如节点和用户。

项目是附带额外注解的 Kubernetes 命名空间，是管理常规用户资源访问权限的集中载体。通过项目，一个社区的用户可以在与其他社区隔离的前提下组织和管理其内容。用户必须由管理员授予对项目的访问权限；或者，如果用户有权创建项目，则自动具有自己创建项目的访问权限。

项目可以有单独的 name、displayName 和 description。

每个项目限制了自己的一组：

集群管理员可以创建项目，并可将项目的管理权限委派给用户社区的任何成员。集群管理员也可以允许开发人员创建自己的项目。

开发人员和管理员可以通过 CLI 或 Web 控制台与项目交互。

OpenShift Container Platform 附带若干默认项目，名称以 openshift-- 开头的项目对用户而言最为重要。这些项目托管作为 Pod 运行的主要组件和其他基础架构组件。在这些命名空间中创建的带有关键 (critical) Pod 注解的 Pod 是很重要的，它们可以保证被 kubelet 准入。在这些命名空间中为主要组件创建的 Pod 已标记为“critical”。

通过 oc describe 命令，可以使用 oc CLI 来查看集群角色和绑定。

在集群范围内绑定了 cluster-admin 默认集群角色的用户可以对任何资源执行任何操作，包括查看集群角色和绑定。

使用 oc describe 命令通过 oc CLI 来查看本地角色和绑定。

可以使用 oc adm 管理员 CLI 管理角色和绑定。

将角色绑定或添加到用户或组可让用户或组具有该角色授予的访问权限。您可以使用 oc adm policy 命令向用户和组添加和移除角色。

您可以将任何默认集群角色绑定到项目中的本地用户或组。

您可以为项目创建本地角色，然后将其绑定到用户。

您可以创建集群角色。

在使用以下操作为本地角色绑定管理用户或组的关联角色时，可以使用 -n 标志来指定项目。如果未指定，则使用当前项目。

您可以使用以下命令进行本地 RBAC 管理。

您也可以使用以下操作管理集群角色绑定。因为集群角色绑定使用没有命名空间的资源，所以这些操作不使用 -n 标志。

需要具备 cluster-admin 角色才能在 OpenShift Container Platform 集群上执行管理员级别的任务，例如修改集群资源。

OpenShift Container Platform 在安装过程完成后会创建一个集群管理员 kubeadmin。

此用户自动具有 cluster-admin 角色，并视为集群的 root 用户。其密码是动态生成的，对 OpenShift Container Platform 环境中是唯一的。安装完成后，安装程序的输出中会包括这个密码。例如：

INFO Install complete!
INFO Run 'export KUBECONFIG=<your working directory>/auth/kubeconfig' to manage the cluster with 'oc', the OpenShift CLI.
INFO The cluster is ready when 'oc login -u kubeadmin -p <provided>' succeeds (wait a few minutes).
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.demo1.openshift4-beta-abcorp.com
INFO Login to the console with user: kubeadmin, password: <provided>

在定义了身份提供程序并创建新的 cluster-admin 用户后，您可以移除 kubeadmin 来提高集群安全性。

OpenShift Container Platform 实施了一个用户代理，可用来防止应用程序开发者的 CLI 访问 OpenShift Container Platform API。如果客户端使用特定的库或二进制文件，则无法访问 OpenShift Container Platform API。

您可以根据 OpenShift Container Platform 中的一组值为 OpenShift Container Platform CLI 构造用户代理：

<command>/<version> (<platform>/<architecture>) <client>/<git_commit>

例如，满足以下条件时：

其用户代理是：

oc/v3.3.0 (linux/amd64) openshift/f034127

作为管理员，您可以使用 master 配置中的 userAgentMatching 配置设置来防止客户端访问 API。

服务帐户是一种 OpenShift Container Platform 帐户，它允许组件直接访问 API。服务帐户是各个项目中存在的 API 对象。服务帐户为控制 API 访问提供了灵活的方式，不需要共享常规用户的凭证。

使用 OpenShift Container Platform CLI 或 web 控制台时，您的 API 令牌会为您与 API 进行身份验证。您可以将组件与服务帐户关联，以便组件能够访问 API 且无需使用常规用户的凭证。例如，借助服务帐户：

每个服务帐户的用户名都源自于其项目和名称：

system:serviceaccount:<project>:<name>

每一服务帐户也是以下两个组的成员：

每个服务帐户自动包含两个 secret：

生成的 API 令牌和 registry 凭证不会过期，但可通过删除 secret 来撤销它们。当删除 secret 时，系统会自动生成一个新 secret 来取代它。

您可以在项目中创建服务帐户，并通过将其绑定到角色为该帐户授予权限。

您可以像为常规用户帐户授予角色一样，为服务帐户授予角色。

服务帐户是一种 OpenShift Container Platform 帐户，它允许组件直接访问 API。服务帐户是各个项目中存在的 API 对象。服务帐户为控制 API 访问提供了灵活的方式，不需要共享常规用户的凭证。

使用 OpenShift Container Platform CLI 或 web 控制台时，您的 API 令牌会为您与 API 进行身份验证。您可以将组件与服务帐户关联，以便组件能够访问 API 且无需使用常规用户的凭证。例如，借助服务帐户：

每个服务帐户的用户名都源自于其项目和名称：

system:serviceaccount:<project>:<name>

每一服务帐户也是以下两个组的成员：

每个服务帐户自动包含两个 secret：

生成的 API 令牌和 registry 凭证不会过期，但可通过删除 secret 来撤销它们。当删除 secret 时，系统会自动生成一个新 secret 来取代它。

OpenShift Container Platform 集群包含用于集群管理的默认服务帐户，并且为各个项目生成更多服务帐户。

您可以在项目中创建服务帐户，并通过将其绑定到角色为该帐户授予权限。

您可以将服务帐户的令牌分发给必须通过 API 身份验证的外部应用程序。

若要拉取镜像，经过身份验证的用户必须具有所请求的 imagestreams/layers 的 get 权限。若要推送镜像，经过身份验证的用户必须具有所请求的 imagestreams/layers 的 update 权限。

默认情况下，一个项目中的所有服务帐户都有权拉取同一项目中的任何镜像，而 builder 服务帐户则有权在同一项目中推送任何镜像。

您可以使用服务帐户，作为受约束形式的 OAuth 客户端。服务帐户只能请求范围的子集，允许访问服务帐户本身的命名空间中的一些基本用户信息和基于角色的功能：

在将服务帐户用作 OAuth 客户端时：

serviceaccounts.openshift.io/oauth-redirecturi.<name>

"serviceaccounts.openshift.io/oauth-redirecturi.first":  "https://example.com"
"serviceaccounts.openshift.io/oauth-redirecturi.second": "https://other.com"

"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"

{
  "kind": "OAuthRedirectReference",
  "apiVersion": "v1",
  "reference": {
    "kind": "Route",
    "name": "jenkins"
  }
}

{
  "kind": "OAuthRedirectReference",
  "apiVersion": "v1",
  "reference": {
    "kind": ..., 1
    "name": ..., 2
    "group": ... 3
  }
}

"serviceaccounts.openshift.io/oauth-redirecturi.first":  "custompath"
"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"

"serviceaccounts.openshift.io/oauth-redirecturi.first":  "custompath"
"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"
"serviceaccounts.openshift.io/oauth-redirecturi.second":  "//:8000"
"serviceaccounts.openshift.io/oauth-redirectreference.second": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"

"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"
"serviceaccounts.openshift.io/oauth-redirecturi.second": "https://other.com"

您可以创建有作用域令牌，将某些权限委派给其他用户或服务帐户。例如，项目管理员可能希望委派创建 Pod 的权限。

有范围的令牌用来标识给定用户，但仅限于其范围指定的特定操作。只有具有 cluster-admin 角色的用户才能创建有范围的令牌。

通过将令牌的范围集合转换为 PolicyRule 集合来评估其范围。然后，请求会与这些规则进行匹配。请求属性必须至少匹配其中一条范围规则，才能传递给 "normal" 授权程序进行进一步授权检查。

与 RBAC 资源控制用户访问的方式类似，管理员可以使用安全性上下文约束 (SCC) 来控制 Pod 的权限。这些权限包括 Pod（容器集合）可以执行的操作以及它们可以访问的资源。您可以使用 SCC 定义 Pod 运行必须满足的一组条件，以便其能被系统接受。

管理员可以借助 SCC 来控制：

Docker 具有允许用于 Pod 的每个容器的默认功能列表。容器使用此默认列表中的功能，但 Pod 清单作者可以通过请求额外功能或移除某些默认行为来修改列表。使用 allowedCapabilities、defaultAddCapabilities 和 requiredDropCapabilities 参数控制来自 Pod 的此类请求，并且指定可以请求哪些功能、每个容器必须添加哪些功能，以及必须禁止哪些功能。

集群包含八个默认 SCC：

特权 SCC 允许：

受限的 SCC：

SCC 由设置和策略组成，它们控制 Pod 能够访问的安全功能。这些设置分为三个类别：

准入控制器清楚安全性上下文约束 (SCC) 中的某些条件，这些条件会触发它从命名空间中查找预分配值并在处理 Pod 前填充 SCC。每个 SCC 策略都独立于其他策略进行评估，每个策略的预分配值（若为允许）与 Pod 规格值聚合，为运行中 Pod 中定义的不同 ID 生成最终值。

以下 SCC 导致准入控制器在 Pod 规格中没有定义范围时查找预分配值：

在生成阶段，安全性上下文提供程序会对 Pod 中未具体设置的参数值使用默认值。默认值基于所选的策略：

以下示例演示了安全性上下文约束 (SCC) 格式和注解：

allowHostDirVolumePlugin: true
allowHostIPC: true
allowHostNetwork: true
allowHostPID: true
allowHostPorts: true
allowPrivilegedContainer: true
allowedCapabilities: 1
- '*'
apiVersion: security.openshift.io/v1
defaultAddCapabilities: [] 2
fsGroup: 3
  type: RunAsAny
groups: 4
- system:cluster-admins
- system:nodes
kind: SecurityContextConstraints
metadata:
  annotations:
    kubernetes.io/description: 'privileged allows access to all privileged and host
      features and the ability to run as any user, any group, any fsGroup, and with
      any SELinux context.  WARNING: this is the most relaxed SCC and should be used
      only for cluster administration. Grant with caution.'
  creationTimestamp: null
  name: privileged
priority: null
readOnlyRootFilesystem: false
requiredDropCapabilities: [] 5
runAsUser: 6
  type: RunAsAny
seLinuxContext: 7
  type: RunAsAny
seccompProfiles:
- '*'
supplementalGroups: 8
  type: RunAsAny
users: 9
- system:serviceaccount:default:registry
- system:serviceaccount:default:router
- system:serviceaccount:openshift-infra:build-controller
volumes:
- '*'

SCC 中的 users 和 groups 字段控制能够访问该 SCC 的用户。默认情况下，集群管理员、节点和构建控制器被授予特权 SCC 的访问权限。所有经过身份验证的用户被授予受限 SCC 的访问权限。

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext: 1
  containers:
  - name: sec-ctx-demo
    image: gcr.io/google-samples/node-hello:1.0

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000 1
  containers:
    - name: sec-ctx-demo
      image: gcr.io/google-samples/node-hello:1.0

此配置对 SELinux、fsGroup 和补充组有效。

您可以使用 CLI 创建安全性上下文约束 (SCC)。

您可以将 SCC 指定为由 RBAC 处理的资源。这样，您可以将对 SCC 访问的范围限定为某一项目或整个集群。直接将用户、组或服务帐户分配给 SCC 可保留整个集群的范围。

要使您的角色包含对 SCC 的访问，请在创建角色时指定 scc 资源。

$ oc create role <role-name> --verb=use --resource=scc --resource-name=<scc-name> -n <namespace>

这会生成以下角色定义：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
...
  name: role-name 1
  namespace: namespace 2
...
rules:
- apiGroups:
  - security.openshift.io 3
  resourceNames:
  - scc-name 4
  resources:
  - securitycontextconstraints 5
  verbs: 6
  - use

当本地或集群角色具有这样的规则时，通过 RoleBinding 或 ClusterRoleBinding 与其绑定的主体可以使用用户定义的 SCC scc-name。

您可以使用 CLI，将实例中的 SCC 作为常规 API 对象来管理。

$ oc get scc

NAME               PRIV    CAPS   SELINUX     RUNASUSER          FSGROUP     SUPGROUP    PRIORITY   READONLYROOTFS   VOLUMES
anyuid             false   []     MustRunAs   RunAsAny           RunAsAny    RunAsAny    10         false            [configMap downwardAPI emptyDir persistentVolumeClaim projected secret]
hostaccess         false   []     MustRunAs   MustRunAsRange     MustRunAs   RunAsAny    <none>     false            [configMap downwardAPI emptyDir hostPath persistentVolumeClaim projected secret]
hostmount-anyuid   false   []     MustRunAs   RunAsAny           RunAsAny    RunAsAny    <none>     false            [configMap downwardAPI emptyDir hostPath nfs persistentVolumeClaim projected secret]
hostnetwork        false   []     MustRunAs   MustRunAsRange     MustRunAs   MustRunAs   <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim projected secret]
node-exporter      false   []     RunAsAny    RunAsAny           RunAsAny    RunAsAny    <none>     false            [*]
nonroot            false   []     MustRunAs   MustRunAsNonRoot   RunAsAny    RunAsAny    <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim projected secret]
privileged         true    [*]    RunAsAny    RunAsAny           RunAsAny    RunAsAny    <none>     false            [*]
restricted         false   []     MustRunAs   MustRunAsRange     MustRunAs   RunAsAny    <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim projected secret]

$ oc describe scc restricted
Name:					restricted
Priority:				<none>
Access:
  Users:				<none> 1
  Groups:				system:authenticated 2
Settings:
  Allow Privileged:			false
  Default Add Capabilities:		<none>
  Required Drop Capabilities:		KILL,MKNOD,SYS_CHROOT,SETUID,SETGID
  Allowed Capabilities:			<none>
  Allowed Seccomp Profiles:		<none>
  Allowed Volume Types:			configMap,downwardAPI,emptyDir,persistentVolumeClaim,projected,secret
  Allow Host Network:			false
  Allow Host Ports:			false
  Allow Host PID:			false
  Allow Host IPC:			false
  Read Only Root Filesystem:		false
  Run As User Strategy: MustRunAsRange
    UID:				<none>
    UID Range Min:			<none>
    UID Range Max:			<none>
  SELinux Context Strategy: MustRunAs
    User:				<none>
    Role:				<none>
    Type:				<none>
    Level:				<none>
  FSGroup Strategy: MustRunAs
    Ranges:				<none>
  Supplemental Groups Strategy: RunAsAny
    Ranges:				<none>

$ oc delete scc <scc_name>

$ oc edit scc <scc_name>

您可以配置对 OpenShift Container Platform API 的请求，使其表现为像是源自于另一用户。如需更多信息，请参阅 Kubernetes 文档中的用户模仿。

您可以授予用户权限来模拟 system:admin，这将使它们获得集群管理员权限。

当通过一个组为 system:admin 用户授予集群管理权限时，您必须在命令中包含 --as=<user> --as-group=<group1> --as-group=<group2> 参数来模拟关联的组。

在运行 LDAP 同步之前，您需要有一个同步配置文件。此文件包含以下 LDAP 客户端配置详情：

配置文件的格式取决于您使用的模式，即 RFC 2307、Active Directory 或增强 Active Directory。

配置中的 LDAP 客户端配置部分定义与 LDAP 服务器的连接。

url: ldap://10.0.0.0:389 1
bindDN: cn=admin,dc=example,dc=com 2
bindPassword: password 3
insecure: false 4
ca: my-ldap-ca-bundle.crt 5

baseDN: ou=users,dc=example,dc=com 1
scope: sub 2
derefAliases: never 3
timeout: 0 4
filter: (objectClass=inetOrgPerson) 5
pageSize: 0 6

groupUIDNameMapping:
  "cn=group1,ou=groups,dc=example,dc=com": firstgroup
  "cn=group2,ou=groups,dc=example,dc=com": secondgroup
  "cn=group3,ou=groups,dc=example,dc=com": thirdgroup

kind: LDAPSyncConfig
apiVersion: v1
url: ldap://LDAP_SERVICE_IP:389 1
insecure: false 2
rfc2307:
    groupsQuery:
        baseDN: "ou=groups,dc=example,dc=com"
        scope: sub
        derefAliases: never
        pageSize: 0
    groupUIDAttribute: dn 3
    groupNameAttributes: [ cn ] 4
    groupMembershipAttributes: [ member ] 5
    usersQuery:
        baseDN: "ou=users,dc=example,dc=com"
        scope: sub
        derefAliases: never
        pageSize: 0
    userUIDAttribute: dn 6
    userNameAttributes: [ mail ] 7
    tolerateMemberNotFoundErrors: false
    tolerateMemberOutOfScopeErrors: false

kind: LDAPSyncConfig
apiVersion: v1
url: ldap://LDAP_SERVICE_IP:389
activeDirectory:
    usersQuery:
        baseDN: "ou=users,dc=example,dc=com"
        scope: sub
        derefAliases: never
        filter: (objectclass=inetOrgPerson)
        pageSize: 0
    userNameAttributes: [ mail ] 1
    groupMembershipAttributes: [ memberOf ] 2

kind: LDAPSyncConfig
apiVersion: v1
url: ldap://LDAP_SERVICE_IP:389
augmentedActiveDirectory:
    groupsQuery:
        baseDN: "ou=groups,dc=example,dc=com"
        scope: sub
        derefAliases: never
        pageSize: 0
    groupUIDAttribute: dn 1
    groupNameAttributes: [ cn ] 2
    usersQuery:
        baseDN: "ou=users,dc=example,dc=com"
        scope: sub
        derefAliases: never
        filter: (objectclass=inetOrgPerson)
        pageSize: 0
    userNameAttributes: [ mail ] 3
    groupMembershipAttributes: [ memberOf ] 4

创建了同步配置文件后，您可以开始同步。OpenShift Container Platform 允许管理员与同一服务器进行多种不同类型的同步。

如果创建组的 LDAP 服务器上的记录已不存在，管理员也可以选择从 OpenShift Container Platform 记录中移除这些组。修剪任务将接受用于同步任务的相同同步配置文件以及白名单或黑名单。

例如：

$ oc adm prune groups --sync-config=/path/to/ldap-sync-config.yaml --confirm
$ oc adm prune groups --whitelist=/path/to/whitelist.txt --sync-config=/path/to/ldap-sync-config.yaml --confirm
$ oc adm prune groups --blacklist=/path/to/blacklist.txt --sync-config=/path/to/ldap-sync-config.yaml --confirm

本节包含 RFC 2307、Active Directory 和增强 Active Directory 模式的示例。

  dn: ou=users,dc=example,dc=com
  objectClass: organizationalUnit
  ou: users
  dn: cn=Jane,ou=users,dc=example,dc=com
  objectClass: person
  objectClass: organizationalPerson
  objectClass: inetOrgPerson
  cn: Jane
  sn: Smith
  displayName: Jane Smith
  mail: jane.smith@example.com
  dn: cn=Jim,ou=users,dc=example,dc=com
  objectClass: person
  objectClass: organizationalPerson
  objectClass: inetOrgPerson
  cn: Jim
  sn: Adams
  displayName: Jim Adams
  mail: jim.adams@example.com
  dn: ou=groups,dc=example,dc=com
  objectClass: organizationalUnit
  ou: groups
  dn: cn=admins,ou=groups,dc=example,dc=com 1
  objectClass: groupOfNames
  cn: admins
  owner: cn=admin,dc=example,dc=com
  description: System Administrators
  member: cn=Jane,ou=users,dc=example,dc=com 2
  member: cn=Jim,ou=users,dc=example,dc=com

kind: LDAPSyncConfig
apiVersion: v1
groupUIDNameMapping:
  "cn=admins,ou=groups,dc=example,dc=com": Administrators 1
rfc2307:
    groupsQuery:
        baseDN: "ou=groups,dc=example,dc=com"
        scope: sub
        derefAliases: never
        pageSize: 0
    groupUIDAttribute: dn 2
    groupNameAttributes: [ cn ] 3
    groupMembershipAttributes: [ member ]
    usersQuery:
        baseDN: "ou=users,dc=example,dc=com"
        scope: sub
        derefAliases: never
        pageSize: 0
    userUIDAttribute: dn 4
    userNameAttributes: [ mail ]
    tolerateMemberNotFoundErrors: false
    tolerateMemberOutOfScopeErrors: false

Error determining LDAP group membership for "<group>": membership lookup for user "<user>" in group "<group>" failed because of "search for entry with dn="<user-dn>" would search outside of the base dn specified (dn="<base-dn>")".

Error determining LDAP group membership for "<group>": membership lookup for user "<user>" in group "<group>" failed because of "search for entry with base dn="<user-dn>" refers to a non-existent entry".
Error determining LDAP group membership for "<group>": membership lookup for user "<user>" in group "<group>" failed because of "search for entry with base dn="<user-dn>" and filter "<filter>" did not return any results".

  dn: ou=users,dc=example,dc=com
  objectClass: organizationalUnit
  ou: users
  dn: cn=Jane,ou=users,dc=example,dc=com
  objectClass: person
  objectClass: organizationalPerson
  objectClass: inetOrgPerson
  cn: Jane
  sn: Smith
  displayName: Jane Smith
  mail: jane.smith@example.com
  dn: cn=Jim,ou=users,dc=example,dc=com
  objectClass: person
  objectClass: organizationalPerson
  objectClass: inetOrgPerson
  cn: Jim
  sn: Adams
  displayName: Jim Adams
  mail: jim.adams@example.com
  dn: ou=groups,dc=example,dc=com
  objectClass: organizationalUnit
  ou: groups
  dn: cn=admins,ou=groups,dc=example,dc=com
  objectClass: groupOfNames
  cn: admins
  owner: cn=admin,dc=example,dc=com
  description: System Administrators
  member: cn=Jane,ou=users,dc=example,dc=com
  member: cn=Jim,ou=users,dc=example,dc=com
  member: cn=INVALID,ou=users,dc=example,dc=com 1
  member: cn=Jim,ou=OUTOFSCOPE,dc=example,dc=com 2

kind: LDAPSyncConfig
apiVersion: v1
url: ldap://LDAP_SERVICE_IP:389
rfc2307:
    groupsQuery:
        baseDN: "ou=groups,dc=example,dc=com"
        scope: sub
        derefAliases: never
    groupUIDAttribute: dn
    groupNameAttributes: [ cn ]
    groupMembershipAttributes: [ member ]
    usersQuery:
        baseDN: "ou=users,dc=example,dc=com"
        scope: sub
        derefAliases: never
    userUIDAttribute: dn 1
    userNameAttributes: [ mail ]
    tolerateMemberNotFoundErrors: true 2
    tolerateMemberOutOfScopeErrors: true 3

dn: ou=users,dc=example,dc=com
objectClass: organizationalUnit
ou: users

dn: cn=Jane,ou=users,dc=example,dc=com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: testPerson
cn: Jane
sn: Smith
displayName: Jane Smith
mail: jane.smith@example.com
memberOf: admins 1

dn: cn=Jim,ou=users,dc=example,dc=com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: testPerson
cn: Jim
sn: Adams
displayName: Jim Adams
mail: jim.adams@example.com
memberOf: admins

dn: ou=users,dc=example,dc=com
objectClass: organizationalUnit
ou: users

dn: cn=Jane,ou=users,dc=example,dc=com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: testPerson
cn: Jane
sn: Smith
displayName: Jane Smith
mail: jane.smith@example.com
memberOf: cn=admins,ou=groups,dc=example,dc=com 1

dn: cn=Jim,ou=users,dc=example,dc=com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: testPerson
cn: Jim
sn: Adams
displayName: Jim Adams
mail: jim.adams@example.com
memberOf: cn=admins,ou=groups,dc=example,dc=com

dn: ou=groups,dc=example,dc=com
objectClass: organizationalUnit
ou: groups

dn: cn=admins,ou=groups,dc=example,dc=com 2
objectClass: groupOfNames
cn: admins
owner: cn=admin,dc=example,dc=com
description: System Administrators
member: cn=Jane,ou=users,dc=example,dc=com
member: cn=Jim,ou=users,dc=example,dc=com

dn: ou=users,dc=example,dc=com
objectClass: organizationalUnit
ou: users

dn: cn=Jane,ou=users,dc=example,dc=com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: testPerson
cn: Jane
sn: Smith
displayName: Jane Smith
mail: jane.smith@example.com
memberOf: cn=admins,ou=groups,dc=example,dc=com 1

dn: cn=Jim,ou=users,dc=example,dc=com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: testPerson
cn: Jim
sn: Adams
displayName: Jim Adams
mail: jim.adams@example.com
memberOf: cn=otheradmins,ou=groups,dc=example,dc=com 2

dn: ou=groups,dc=example,dc=com
objectClass: organizationalUnit
ou: groups

dn: cn=admins,ou=groups,dc=example,dc=com 3
objectClass: group
cn: admins
owner: cn=admin,dc=example,dc=com
description: System Administrators
member: cn=Jane,ou=users,dc=example,dc=com
member: cn=otheradmins,ou=groups,dc=example,dc=com

dn: cn=otheradmins,ou=groups,dc=example,dc=com 4
objectClass: group
cn: otheradmins
owner: cn=admin,dc=example,dc=com
description: Other System Administrators
memberOf: cn=admins,ou=groups,dc=example,dc=com 5 6
member: cn=Jim,ou=users,dc=example,dc=com

kind: LDAPSyncConfig
apiVersion: v1
url: ldap://LDAP_SERVICE_IP:389
augmentedActiveDirectory:
    groupsQuery: 1
        derefAliases: never
        pageSize: 0
    groupUIDAttribute: dn 2
    groupNameAttributes: [ cn ] 3
    usersQuery:
        baseDN: "ou=users,dc=example,dc=com"
        scope: sub
        derefAliases: never
        filter: (objectclass=inetOrgPerson)
        pageSize: 0
    userNameAttributes: [ mail ] 4
    groupMembershipAttributes: [ "memberOf:1.2.840.113556.1.4.1941:" ] 5

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

配置文件的对象规格如下。请注意，不同的模式对象有不同的字段。例如，v1.ActiveDirectoryConfig 没有 groupsQuery 字段，而 v1.RFC2307Config 和 v1.AugmentedActiveDirectoryConfig 都有这个字段。

默认的 OpenShift Container Platform 配置仅允许 OpenShift Web 控制台向 API 服务器发送请求。

如果需要使用其他主机名从 JavaScript 应用程序访问 API 服务器或 OAuth 服务器，可以配置额外的主机名来允许这么做。

默认情况下，OpenShift Container Platform 不加密 etcd 数据。在集群中启用对 etcd 进行加密的功能可为数据的安全性提供额外的保护层。例如，如果 etcd 备份暴露给不应该获得这个数据的人员，它会帮助保护敏感数据。

启用 etcd 加密时，以下 OpenShift API 服务器和 Kubernetes API 服务器资源将被加密：

当您启用 etcd 加密时，会创建加密密钥。这些密钥会每周进行轮转。您必须有这些密钥才能从 etcd 备份中恢复数据。

您可以启用 etcd 加密来加密集群中的敏感资源。

您可以在集群中禁用 etcd 数据的加密。