OKD 权限认证

• OKD 权限认证
  • HtPasswd
  • 服务账户(Service Account)
  • 基于角色的权限访问控制
    • 相关概念
    • 权限给予
    • 权限校验
  • OpenShift安全上下文的约束
  • OpenShift服务目录
    • OpenShift 服务目录概述

Openshift API Server 利用管理员配置的认证模块来认证每个达到的请求。认证过程及用户、API认证方式、身份提供程序等多个概念。认证过程涉及用户、API认证方式、身份提供程序等多个概念。

OpenShift 中的user对象代表集群中的一个用户，在用户第一次登录集群时自动创建，或通过API手动创建。

HtPasswd

OKD 一般是在开发测试环境中，可利用HTPasswd作为身份提供程序，它将用户名和密码保存在一个使用htpasswd工具创建的文本文件中。要在Master配置文件中配置htpasswd身份提供程序，可通过编辑/etc/origin/master/master-config.yaml，在identityProviders部分添加以下内容来实现。

  identityProviders:
  - challenge: true
    login: true
    mappingMethod: claim
    name: htpasswd_auth
    provider:
      apiVersion: v1
      file: /etc/origin/master/htpasswd
      kind: HTPasswdPasswordIdentityProvider

修改后，重启Master API和Controllers服务

master-restart api
master-restart controllers

然后创建用户tom及有关对象。
1.在Master节点上运行htpasswd命令来创建文件并添加用户tom，需要输入tom的密码。

# 一般没有该文件需要这样进行创建
htpasswd -c /etc/origin/master/htpasswd tom
# 如果该文件已存在
htpasswd -b /etc/origin/master/htpasswd tom tom
# 如果有多个节点
ansible -m shell -a 'htpasswd -b /etc/origin/master/htpasswd tom tom' masters

第一次一般需要登录一下。

# 先登录到tom用户
oc login -u tom -p tom
# 再登录到admin用户
oc login -u admin -p admin

或者我们也可以通过不用登录直接创建也可以

oc create user tom
oc create identity htpasswd_auth:tom

查看用户信息

oc get user
oc get identity htpasswd_auth:tom

服务账户(Service Account)

当一个普通用户访问OpenShift API时，OpenShift对它进行用户认证和权限控制。但是，在Openshift集群中又时做操作的并不是自然人用户，例如：

• Replication Controller 调用API去创建或者删除Pod。
• 容器中的应用调用OpenShift API。
• 外部应用调用OpenShift API来进行监控或者整合。

为了管理这种非普通用户进行的操作，OpenShift创造了服务账户(sa)的概念。服务属于项目范畴。每个项目默认都会自动创建3个服务账户，如下表所示：

每个项目都需要使用服务账户来运行构建Pod、部署和其他Pod操作。Master配置文件中的 serviceAccountConfig 部分的managedNames定义了为每个项目自动创建的服务账户的名称。可通过oc get sa命令来获取当前项目中的服务账户列表。

通过oc create sa <sa_name>命令来创建一个新服务账户。

# 创建hmy服务账户
oc create sa hmy
oc get sa

服务账户利用一个被私有RSA密钥签名的Token来进行认证。API Server中的认证模块用RSA公钥来签证签名。在Master配置文件的serviceAccountConfig部分，配置了用于签名的私钥文件privateKeyFile和用于验证的公钥文件publicKeyFiles。

vim /etc/origin/master/master-config.yaml

那么服务账户的Token是怎么来的呢？服务账户被创建后，OpenShift自动为它创建两个Secret，一个包含用于API访问的Token；另一个包含用于从OpenShift内置镜像仓库中拉取镜像的Token。

oc describe sa hmy

查看hmy-token-lndvh这个Secret的详细信息，可看到其用于访问OpenShift API的Token。

oc describe secret hmy-token-lndvh

在API Token Secret 中有4个部分的内容。

每个Pod的运行都需要有一个服务账户。Pod的服务账户决定了Pod可用的Token，它使用服务账户的镜像拉取Token然后去拉取Pod要用到的镜像，将API Token挂载到Pod内部目录中供Pod内的应用使用。默认情况下，当Pod实例被创建后，其服务账户的API Secret会被挂载到Pod中的目录/var/run/secrets/kubernetes.io/serviceaccount下，从而使得Pod中的应用可读取其中的Token去访问OpenShift API。

oc rsh my-web-app

Pod中的应用可读取该文件夹下的Token等信息去访问OpenShift API。以下示例代码展示了简单的使用方式。

TOKEN="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)"
curl --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt "https://openshift.default.svc.cluster.local/oapi/v1/users/~" -H "Authorization: Bearer $TOKEN"

apiVersion: v1
imagePullSecrets:
- name: default-dockercfg-kr6q7
kind: ServiceAccount
metadata:
  creationTimestamp: 2021-08-07T08:40:38Z
  name: default
  namespace: mynetcore
  resourceVersion: "10329"
  selfLink: /api/v1/namespaces/mynetcore/serviceaccounts/default
  uid: 24091a15-f75b-11eb-ae81-001c42adbe97
automoutServiceAccountToken: false
secrets:
- name: default-dockercfg-kr6q7
- name: default-token-8snbs

基于角色的权限访问控制

OpenShift RBAC是OpenShift支持的众多授权模块中的一种，它通过给用户绑定相应的角色，使用户获得对资源的操作权限，从而实现了授权功能。
RBAC适用于普通账户和服务账户。
RBAC利用Rule（规则）、角色（Role）和Binding来实现用户操作授权。

相关概念

角色策略规则，是对一组资源的操作集合，比如增删改查（get、list、delete）等。每个角色定义了受控制的对象（Subject）、允许的操作（Verb）和范围（集群和集群的项目）。
角色安装其范围分为两类：
1.集群范围内存在的角色被称为集群角色（ClusterRole）；存在于某个项目中的角色被称为本地角色（Role）。OpenShift默认会创建很多的集群角色，常用角色的简单描述如下表：

通过oc get clusterrole命令可以查看所有集群角色。system:router角色的详细信息如下。

oc describe clusterrole system:router

用户、用户组和角色之间通过OpenShift RoleBinding 资源类型连接起来。为 User/Group、Role、RoleBinding这几个概念之间的关系。

下图为用户通过Local Role Binding或Cluster Role Binding绑定给项目角色或集群角色而产生的不同权限。

权限给予

OpenShift用户默认不具有任何权限。要使得用户具有所需要的权限，需要给其授予相应的角色。OpenShift具有很多默认角色，用户也可以自定义角色。比如创建一个只能查看Pod的Role。

# 创建podview角色且只能查看pod的权限
oc create role podview --verb=get --resource=pod
# 查看role
oc describe role podview

确认角色以后，通过oc adm policy <子命令>命令向用户、服务账户和用户组授予项目或集群角色。

通过以下命令查看当前项目mynetcore中默认的服务账户的rolebinding。

oc get rolebinding

从上面的输出可以看出，deployer服务账户被赋予了 system:deployer 角色，builder 被赋予了system:image-builder 角色，而3个服务账户都在用户组 system: serviceaccounts:mynetcore 中因而都被赋予了 system:image-puller 角色。利用 default 服务账户来做如下实验：
1》获取其API token secret default-token-8snbs

oc describe secrets default-token-8snbs

2》利用该Token登录进OpenShift集群。

oc login --token=eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9........xthblMyBHUIFz8uYs_qXwOUXvlDnWk0OC9FecQZY0PGsRXNw_4BD640K6iALN8cw6y6_AA8M6cJ5BT3qXFnBgR6TQ

3》调用API获取Pod，结果失败，因为它不具有Pod对象的list权限。

oc get pod

4》向Default服务账户授予 cluster-reader 角色。

oc adm policy add-cluster-role-to-user cluster-reader system:serviceaccount:mynetcore:default

5》这时就有权查看集群信息了。

权限校验

Openshift API Server利用以下对象来校验用户是否有权对目标对象进行访问。
——Identity：用户的用户名和群组列表。
——Action：用户期望执行的操作。通常包括Project（目标对象所在的项目）、Verb（期望对象，比如get、list、create、update、delete等）、ResourceName（目标对象的名称）等。
——Binding：用户/组与角色对象之间的绑定关系。
OpenShift API Server校验授权的过程如下：

1》利用Identity和Project找到该用户或组的所有Binding
2》利用Binding去找出所有的Role
3》通过Role找到所有的Rule
4》比对Action和每一条Rule，直到找到匹配的。
5》如果没有匹配的Rule，那么该操作将被拒绝。

OpenShift安全上下文的约束

利用RBAC控制用户访问资源权限类似，管理员可利用SCC来控制Pod的权限，包括Pod能做什么事情、能访问声明资源。Pod中的应用除了要有权限访问OpenShift API和内部镜像仓库之外，还可能有访问部分系统资源的需求。比如：
——要求以任意用户甚至是root来运行Pod中的主进程
——要求访问宿主机上的文件系统
——要求访问宿主机上的网络
利用SCC，管理员能对Pod做如下控制：
——运行特权容器
——为容器增加能力
——使用主机上的目录作为卷。
——容器的SELinux上下文
——用户ID。
——主机命名空间和网络
——为Pod的卷分配FSGroup
——配置允许的补充组。
——要求使用只读文件系统。
——控制允许使用的卷类型。
——控制允许使用的安全计算模式配置文件。
——控制允许使用的安全计算模式配置文件。
可见，SCC的功能非常强大，但配置也非常复杂。为了减少其复杂性，OpenShift容器云平台默认创建了7种SCC，只对集群管理员可见：

oc get scc

每种预定义的SCC都针对其面向的某种场景所需的各种功能进行了定制。SCC定义中的users和groups字段用于控制对SCC对象的访问权限。默认情况下，集群管理员和节点能使用anyuid SCC，而普通用户默认只能使用restricted SCC。而restricted SCC的权限非常有限：
——不能作为特权容器运行。
——不能将主机文件夹用作卷。
——UID只能在预定的UID范围内。
——可使用FSGroup和补充组。
OpenShift将容器所需要的各项能力授予运行容器的用户。在Pod定义中没有显示指定服务账户和SCC的情况下，根据创建pod用户的不同情形，Pod会使用不同的默认SCC：
——非集群管理员角色的用户创建的Pod，默认使用default服务账户和restricted SCC。
——集群管理员角色用户创建的Pod，默认使用default服务账户和anyuid SCC。

对于由普通用户创建的Pod，要授权Pod除了restricted SCC定义的权限以外的权限，通常会将运行该Pod的用户放到目标SCC的用户列表中。注意，这里说的“用户”说直接创建Pod的用户。如果是普通用户直接创建了Pod，那么“用户”是这个普通用户：如果说Deployments、StatefulSets、DaemonSets等控制器代表不同用户创建的Pod，那么“用户”说Pod的服务账户。可将spec.serviceAccountName的纸设置为服务账户名称以制定服务账户，不指定的话将末日使用default服务账户。

对于直接用户是服务账户这种情形，考虑到对现有Pod的影响，如果需要修改服务账户的SCC，建议创建一个新服务账户而不要使用默认账户。确定好直接创建Pod的直接用户后，可运行 oc adm policy add-scc-to-user <scc_name> <user_name>或oc adm policy add-scc-to-group <scc_name> <group_name>命令授权用户或用户组访问指定SCC的权限。

比如，因为Registry和Router服务的Pod需要使用主机网络模式，因此为它们创建了单独的服务账户system: serviceaccount: default: router 和 system: serviceaccount: default: registry 并将他们加入hostnetwork scc的用户列表中。

另一个很常见的例子说运行要使用root用户的容器。很多Docker镜像使用的都是root用户。但是，OpenShift restricted SCC不允许使用root用户，而是要使用一个用户区间内的用户。通常的修复做法如下：
1》创建一个新的服务账户，比如 userroot：oc create serviceaccount useroot
2》将该服务账户加入anyuid SCC的用户列表中：oc adm policy add-scc-to-user anyuid -z useroot
3》在应用的DeploymentConfig中指定serviceAccountName为userroot

OpenShift服务目录

OpenShift3.7版本中引入两个概念：Service Catalog（服务目录）和 Service Broker（服务中介）。可将服务目录看作OpenShift的服务市场（Service Marketplace），用户（服务消费者）可在市场内找到所需要的服务，并方便地创建出服务实例，将其绑定到自己的应用服务上；服务中介说服务目录中服务的提供者和管理者。

假设你是一个开发者，正在开发一个应用程序，该程序需要一个数据库来保存用户数据。你不是一个数据库管理员，因此不知道如何搭建一个数据库服务。现在，在你们公司的OpenShift容器云平台的服务中，有某个提供商（服务中介）提供的数据库服务。你只需要找到该服务，单击几下鼠标就可创建出一个服务实例，再单击几下鼠标将绑定到你的应用程序上，你的程序就可以使用数据库了。等应用程序开发结束后，你只需要解除绑并删除该服务实例即可。

OpenShift服务目标是提供一个服务市场，终端用户可以方便地消费市场中的服务而不用关注服务背后的细节，比如服务是怎么被创建的，以及是如何进行管理的；同时为服务中介提供售卖服务的平台，只需要他们遵循统一规范Open Service Brocker API（OSB API）。

OpenShift 服务目录概述

在本书所用到的OpenShift 3.11 版本中会默认安装两个服务中介：ansible-service-broker 和 template-service-broker.两个中介都提供了多个服务，两者的区别是，前者通过Ansible playbook部署服务，后者通过OpenShift template部署服务。服务中介甚至不必在企业内部，公有云提供商AWS、Azure和Google已实现了服务中介，用于在他们的公有云上创建各种服务实例，然后将服务中介注册到企业OpenShift容器云平台上，这样企业内用户就可以搜索这些服务，按需创建并绑定到企业应用上了。
在OpenShift容器云平台中启动服务目录功能之前，需要在Ansible 清单文件中添加如下配置。

openshift_enable_service_catalog=true
openshift_service_catalog_image_prefix=openshift/origin-
openshift_service_catalog_image_version="3.11"