理解OpenShift（4）：用户及权限管理

理解OpenShift（1）：网络之 Router 和 Route

理解OpenShift（2）：网络之 DNS（域名服务）

理解OpenShift（3）：网络之 SDN

理解OpenShift（4）：用户及权限管理

理解OpenShift（5）：从 Docker Volume 到 OpenShift Persistent Volume

 

** 本文基于 OpenShift 3.11，Kubernetes 1.11 进行测试 ***

 

OpenShift 支持 RBAC（Role Based Access Controll），基于角色的访问控制。它涉及诸多概念，本文尝试着作一些概念上的梳理，不少细节还须要进一步研究。

1. 主要概念及其之间的联系

1.1 用户（User）

我试着把一个OpenShift 环境中的全部用户分为三大类：

• 应用用户：部署在集群之中的应用本身的用户。通常来讲每一个应用都有本身的用户管理系统，与平台无关。也有一些应用，好比 Jenkins，支持与OpenShift 用户系统集成，也就是Jenkins容许用户在经过了OpenShift 用户认证后对其进行访问。这部分不是本文的讨论范围以内。
• OpenShift 用户：访问OpenShift 资源的用户。根据其特征，又将其分为三个子类：
  • Regular user：表明一个天然人用户，好比部署应用的一个开发者。
  • System user：OpenShift 系统用户，大部分在集群建立时被自动建立，好比每一个node都有一个system user。由于这部分主要和OpenShift自身系统相关，与通常用户关系不太大，所以本文不会具体介绍这部分。
  • Service account：服务帐户。这是跟一个项目关联的特殊系统用户，每一个用户被一个 ServiceAccount 对象表示，一般是指 pod 中运行主进程的用户。后文会有具体介绍。
• 操做系统用户：访问操做系统资源的用户，又分为容器内的操做系统用户，和宿主机上的操做系统用户。

1.2 身份（Identity）与认证（Authentication）

认证是确认用户身份是否合法的过程。这能够有多种实现方式，好比用户名/密码、令牌（token）、证书等。不一样类型的用户有不一样的身份管理方式：

• 对于 regular user，每一个用户有一个身份（identity）用于认证。OpenShift  以插件形式支持多种 identity provider，好比在测试环境中经常使用的 htpasswd，生产环境中经常使用的 LDAP 等。这些 provider 中会保存用户身份信息，好比用户名和密码。useridentitymapping 对象将 user 对象和 identity 对象联系在一块儿。
• 对于 service account，一方面它须要访问 OpenShift 集群资源好比 API 和内部镜像仓库中的镜像，另外一方面它可能须要访问 pod 中和宿主机上的操做系统资源，好比宿主机上的文件或网络。对于前者，每一个 service account 使用 secret 来进行身份认证，包括用户 API 访问的 token 和用于从镜像仓库拉取代码的 secret。对于后者，原本有 user namespace（用户命名空间）来支持，可是彷佛OpenShift 还不支持该功能。

1.3 角色（Role）/权限（Permission）与受权（Authorization）

受权是对被认证了的用户访问受控制的资源的权限进行控制。按照资源类型，OpenShift 将受权管理方式分为两大类：

• 对于 OpenShift 集群资源，好比 pod，deployment，route 等，经过 role （角色）进行控制。从范围（scope）上分，role 可分为集群角色（clusterRole）和项目角色（role）。每一个角色定义了受控制的对象（subject）、容许的操做（verb）和范围（集群仍是项目）。用户（user）和角色（role/clusterRole）之间经过 rolebinding/clusterrolebinding 对象进行绑定。
• 对于操做系统资源，这只针对服务帐户。宿主机上的用户访问宿主机上的资源，这由宿主机操做系统进行控制。pod 中的用户（serviceaccount）访问pod内和宿主机上操做系统资源，由 scc（security context constraints）进行控制。

2. 身份 （Identity） 与认证（Authentication）

就像人的身份证同样，identity 是一个 user 的身份信息，该信息用于用户认证。OpenShift 本身并无实现用户身份信息库，而是经过灵活支持多种 identity provider，来实现各类不一样的身份管理方案。每种实现都以不一样的方式保存着用户的身份信息，好比保存在LDAP 中，保存在  htpasswd 文件中，保存在 OpenStack Keystone 中。

 

所以，OpenShift 对 user 身份的校验是经过这些配置了的 identity provider 进行的。所以，还须要 OpenShift user 和这些 provider 里面的 identity 的映射关系。OpenShfit 支持四种映射管理，claim，lookup，generate，add。具体请参考官网 https://docs.openshift.com/container-platform/3.11/install_config/configuring_authentication.html#identity-providers_parameters。

上图中以 htpasswd 这种 identity provider 为例，说明了从零建立一个 openshift user，在 htpasswd 中建立 user 及其密码，而后建立 openshift identity 对象以及 useridentitymapping 对象的过程。

用户获取用于身份认证的token的过程：

• 全部申请 OAuth token 的请求都要发到 <master>/oauth/authorize和<master>/oauth/token。每一个申请 OAuth token 的请求中都必须带有 OAuth client 标识，这是一个 OAuthClient  对象。具体请参阅官方文档。
• OpenShift master 节点上内置有一个 OAuth server。用户从 OAuth 获取 token 后再用它去访问 API 就能够认证经过了。当一个 user 申请一个 OAuth token 时，OAuth 使用配置的 identity provider 去肯定该申请用户的身份。它在肯定该用户所映射到的 identity后，会为该用户建立一个 token，而后返回该token。

3. 角色（Role）和受权（Authorization）

前文说了，角色用于控制对 OpenShift 资源的访问权限，它分为项目角色和集群角色。

OpenShift 系统默认会建立不少的集群角色。经常使用的角色的简单描述以下： 

admin	project manager 若是用于本地 rolebinding，那么用户将能查看和修改所在项目中的全部资源
basic-user	user 能够获取关于项目和用户的基本信息
cluster-admin	用户能够在任何项目中作任何操做（超级用户） 如何用于本地 rolebinding，那么用户将拥有所在project的全部权限，包括控制quota和role
cluster-status	用户能够获取集群的基本状态信息
edit	用户能够修改项目中的大部分对象；可是不能查看或修改 role 和 rolebinding
self-provisioner	全部用户的默认role，能够建立本身的project
view	用户能够查看项目中的大部分对象，除了 role 和 rolebinding 用户不能作任何修改任何对象

能够查看全部角色，好比 system:router 角色：

可使用 oc adm policy 命令向用户或用户授予角色：

user、group、role、rolebinding 之间的关系：

更多对 role 的说明，可参见官方文档。 

4. Service Account 用户

 

OpenShift 的 service account 比较复杂，和不少概念都有关联。官方文档在  https://docs.openshift.com/container-platform/3.11/dev_guide/service_accounts.html。该文档对为何须要这个概念的说明是：当一个天然人用户访问 OpenShfit API 时，OpenShift 对它进行用户认证和权限控制。可是，有时候作操做的并非天然人用户，好比：

• Replication Controller 调用 API 去建立或者删除 pod
• 容器中的应用调用 API
• 外部应用调用 API 去进行监控或者整合

为了这种访问，OpenShift 创造了 Service Account （简称sa）概念。每一个项目（project）默认都会自动建立3个sa user： 

Service Account	Usage
builder	用于 build pod。它被授予了 system:image-builder 角色，所以被容许向内部镜像仓库中的任意 image stream 上push 镜像。
deployer	用于 deployment pod。被授予了 system:deployer 角色，所以被容许查看和修改集群中的 RC 及其 pod。
default	当一个 pod 没有显式指定 service account 默认都会使用该 sa user。

4.1 身份

sa 利用 secret（token）来保存其身份信息。默认状况下，每一个 sa 用户都有两种token，即访问 OpenShift API 的token和访问内部镜像仓库的token。以系统默认的 『builder』 sa user 为例，它包含一个用于拉取镜像的token secret，两个访问API 的token secret，三个secret 中只有两个能被以卷的形式挂接给pod：

能够按需求修改一个 sa 帐户的这些token。可参考 https://docs.openshift.com/enterprise/3.0/dev_guide/image_pull_secrets.html 为service account 建立和添加新的用于拉取镜像的token secret。具体请参考官方文档。

其中，sa 的 API token 会被挂接到 pod 的 目录的 token 文件，从而使得 pod 中的应用能够读取该 token 去访问 OpenShift API：

image pull secret 是如何挂载到 pod 的，我尚未找到。并且在 pod spec 中，只看到 API token secret 的 mountpoint，而并无 imagePullSecret 的 mountpoint：

4.2 权限 - 访问OpenShift 集群资源的权限

和天然人 user 相似，对 sa 用户访问OpenShift 集群资源的权限控制是经过 role 进行的。前面的表格代表，项目的两个默认 sa builder 和 deployer 都被授予了相应的 role，从而能访问指定的资源。而默认的 sa 用户，只被授予了 /system:image-puller 角色。这意味着默认的 sa 用户只能拉取镜像，而不能访问集群其它资源。

下图是项目 stage 中的 rolebinding：

用户组 system:serviceaccounts:stage 中包括该项目中的全部 sa 用户。利用 default sa user 来作下实验。先获取其 API token，而后登陆进 OpenShift 集群：

调用 API 获取 pod，结果失败：

向 default sa user 授予 cluster-reader 角色：

而后就能够作集群资源查询操做了。 

4.3 权限 - 访问系统资源的权限

pod 中的应用除了有访问 OpenShift API 和内部镜像仓库以外，还有一些系统资源访问要求。好比：

• 要求以任意用户甚至是 root 来运行 pod 中的主进程
• 要求访问宿主机上的文件系统
• 要求访问宿主机上的网络

对于这些操做系统资源的访问权限，OpenShift 利用 scc 来进行控制。这就要求：

• 在 scc 中进行权限控制。这部分在后面介绍。
• 在 servie account 和 sa 之间创建联系。每一个 scc 都有指定使用它的用户列表。全部经过身份认证了的用户都只在 restricted 这个 scc 的用户列表之中，包括 service account。所以，pod 默认使用的是 restricted scc。要使它使用其它的scc，就要将它的 service account user 加入到要使用的 scc 的用户列表之中。这在 scc 部分具体介绍。

5. Security Context Constraint（SCC）

前面说过，SCC 用于控制访问系统资源的权限，那说明只有  service account  才须要使用 scc。没在文档中看到天然人用户 user 使用 scc 的例子。

Linux 中的权限控制非常复杂，这里就不说明了，我本身也没怎么弄清楚。OpenShift scc 将系统权限分为几大类，具体见上图中的『权限』部分，而后能够建立 scc 对象来精细地控制对每种权限的控制。

5.1 OpenShift默认的 scc

由于这很是繁琐，所以 OpenShift 默认建立了几个典型的 scc，列表以下。上图中的『系统预约义scc』部分有简要说明，这里再也不重复。

其中，若是 pod 所使用的 scc 的 runAsUser 策略被设置为了 MustRunAsRange，那么 pod 所使用的 uid 和 supplemental-group id 必须在某区间以内。

集群管理员能够在 scc 中设置区间，好比：

可是，OpenShift 默认提供的 scc 都没有设置该区间，而是使用 pod 所在的 project 中定义的区间以内。好比：

[root@master2 cloud-user]# oc describe project dev
Name:                   dev
Created:                3 weeks ago
Labels:                 <none>
Annotations:            openshift.io/description=
                        openshift.io/display-name=
                        openshift.io/requester=demo
                        openshift.io/sa.scc.mcs=s0:c16,c0
                        openshift.io/sa.scc.supplemental-groups=1000000000/10000
                        openshift.io/sa.scc.uid-range=1000000000/10000

每一个 project 会被分配不一样的 ID 区间。当未指定 uid 和 supplemental gid 时，会默认使用区间的最小值。

每一个 pod 中，运行主进程的用户都有三个属性：

• uid 即 user id，上面例子中uid 为 100000000，使用的是 project 定义的 uid 区间的第一个值。其策略分为三种：
  • MustRunAs - 须要配置一个区间，要么在 project 中配置，要么在 scc 中指定。默认使用区间的第一个值。指定特定值的话，会检查是否在该区间内。
  • MustRunAsNonRoot - 要求指定非 root user id，不提供默认值。
  • RunAsAny - 容许全部用户，不提供默认值。
• gid 即用户的primary group id（主组ID）。上面例子中 gid 为 0，组名字为 root。从 https://github.com/kubernetes/enhancements/issues/213 上看，目前 Kubernetes 还不支持设置 gid，其值固定为 0.
• fsGroup 定义 pod 的 文件系统 group ID，用于块存储，好比 Ceph RDB 和 iSCSI。supplementalGroups ID 用于共享存储，也是组/group ID 的一种，用于共享存储，好比 NFS 和 GlusterFS。上面例子中的 supplementalGroup ID 为 10000000，取的也是默认值。这两种 group ID 支持 MustRunAs 和 RunAsAny 两种策略。会在下一篇存储部分详细介绍。

备注：Supplemental group（附加组）也是Linux 组的一种。当一个进程运行在 Linux 中时，它会拥有一个 UID，一个 GID，以及一个或多个附加组ID。具体请查阅Linux 相关文档。

若是某 scc 设置的 RunAsUser 策略为 MustRunAsRange，它会要求配置合法的 uid 区间（要么在 project 中配置，要么在 scc 中指定）。若是你要指定特定的 uid ，你能够在 pod 定义 yaml 中使用 securityContext: runAsUser <uid> 来指定特定的 user id，可是该 id 必须在区间以内。不然会报错：

Error from server (Forbidden): error when creating "testcontainervolume-restricted.yaml": pods "test-pod-volume-restricted2" is forbidden: unable to validate against any security context constraint: [spec.containers[0].securityContext.securityContext.runAsUser: Invalid value: 65534: must be in the ranges: [1000000000, 1000009999]]

5.2 容器使用的默认 scc

根据建立 pod 的用户不一样，pod 使用不一样的默认 scc：

• 非 cluster admin 角色的 openshift 用户建立的没有显式指定 service account 和 scc 的 pod，其默认使用的 sa user 为 default，默认使用的 scc 为 restricted。
• cluster admin 用户，根据 scc 优先级，anyuid 将是这种 pod 默认使用的 scc。

SCC 优先级：一个 sa user 能够被加到多的 scc 当中。当一个 service account user 有多个 SCC 可用时，其 scc 按照下面的规则排序

• 最高优先级的scc排在最前面。默认地，对于 cluster admin 角色的用户的 pod，anyuid scc 会被授予最高优先级，排在最前面。这会容许集群管理员可以以任意 user 运行 pod，而不须要指定 pod 的 SecurityContext 中的 RunAsUser 字段。
• 若是优先级相同，scc 将从限制最高的向限制最少的顺序排序。
• 若是优先级和限制都同样，那么将按照名字排序。

每一个 scc 有其用户/用户组列表。以 restricted 为例，全部经过身份验证的用户都在列表中；而 anyuid，只有 cluster-admins 用户组中的用户在里面。

  

5.3 修改容器使用的scc

要受权 pod 有除了 restricted 定义的权限以外的权限，主要有两种作法：

• 一是将其 service account 放到目标 scc 的用户列表中。此时建议建立一个新的 service account，而不要使用已有的，考虑到对现有 pod 的影响。好比由于 registry 和 router 服务的 pod 须要使用 host networkinig 网络模式，所以有为它们建立单独的 sa user 而且加入到了 hostnetwork scc 的用户列表中。

• 二是将 service account 加入到目标 scc 的用户组中。

官方建议采用第一种。一个很经常使用的例子是运行要使用 root 用户的容器。不少的Docker 镜像都使用的是 root 用户。可是，openshift restricted scc 不容许使用 root 用户，而要使用一个用户区间内的用户：

修复步骤：

$ oc create serviceaccount useroot
$ oc adm policy add-scc-to-user anyuid -z useroot
$ oc patch dc/myAppNeedsRoot --patch '{"spec":{"template":{"spec":{"serviceAccountName": "useroot"}}}}'

备注：

• 第二个语句中的 -z userroot 用于指定当前project 中的 sa user，它和使用 system:serviceaccount:<project>:userroot 效果相同。
• 在 pod 中设置 service account，其属性名字为 serviceAccount，不是 dc 中的 serviceAccount。

说明：

• 第一步建立名为 userroot 的 sa user
• 第二步将该 sa user 加入到 anyuid scc 的 user 列表中
• 第三步在应用的 DeploymentConfig 中指定 serviceAccountName 为 userroot

 

感谢您的阅读，欢迎关注个人微信公众号：