1.用户认证

1.1.令牌

OpenShift中有用户和权限的概念。用户需要通过登录账户及密码登录OpenShift才能访问相应的资源以及执行相关的操作。通过用户提供的登录信息确认用户身份的过程即认证过程。OpenShift通过OAuth进行用户的认证。OAuth是一个开源的认证和授权框架。在OpenShift的Master节点上运行着一个内置的OAuth服务对用户的请求进行认证检查。一旦OAuth服务器通过登录信息确认了用户的身份，OAuth服务器就返回用户的访问token（令牌）。通过这个token，用户可以在有效的时间内对系统进行访问。
在命令行中以dev用户登录，通过oc whoami -t，即可查看当前用户当前Session的token。

[root@master ~]# oc login -u dev Authentication required for https://192.168.1.x:8443 (openshift)Username: dev
Password: 
Login successful.

You have one project on this server: "hello-world-php"Using project "hello-world-php".
[root@master ~]# oc whoami -tBPWrtdTAjvas6fSGq2pbW_5l6dYV0q6CpCZQou9mHR8

注：system:admin是集群默认的管理员。该用户是一个特殊的用户，它不能通过用户名和密码登录。system:admin用户并没有token。

1.2.Identify Provider

作为身份验证的信息，如用户名和密码，并非保存在OpenShift集群内，而是保存在用户信息管理系统内。OpenShift并不包含具体的用户信息库管理系统，但是OpenShift提供了不同的适配器连接不同的用户信息管理系统。这些后端的用户信息管理系统在OpenShift中称为Identify Provider。通过配置，OpenShift可以连接到企业常用的用户信息管理系统。如LDAP系统、微软活动目录（Active Directory）等。同时也支持AllowALL、DenyAll、HTPasswd文件，GitHub、Google等众多后端。
查看master-config.ymal配置，可以看到当前实例集群使用的Provider的类型及配置。

[root@master ~]#  cat /var/lib/origin/openshift.local.config/master/master-config.yaml |grep provider -A 3
 provider:
 apiVersion: v1 kind: AllowAllPasswordIdentityProvider masterCA: ca-bundle.crt

1.3.用户与组管理

在OpenShift中，通过oc get user命令可以查看OpenShift系统中存在的用户列表。

[root@master node-master.example.com]# oc get user</pre>NAME      UID                                    FULL NAME   IDENTITIES<pre class=" CodeMirror-line " role="presentation">de        37d305ef-2c1f-11e8-a07b-d25612141d3e               anypassword:de</pre>dev       9ba776f3-279d-11e8-9821-d25612141d3e               anypassword:dev

OpenShift用户信息来源于后端的Identify Provider。假设用户为OpenShift配置了某个Identify Provider，当用户第一次登录时，OpenShift会为这个用创建一个对象及一个identity对象。这个identify对象记录了用户来源于哪一个后端Identify Provider，以及相关的用户信息。

[root@master tmp]# oc get identity</pre>NAME                             IDP NAME                  IDP USER NAME   USER NAME   USER UID
swift_keystone_provider:devops   swift_keystone_provider   devops          devops      a5df55d3-2e4c-11e8-b8d1-92ca339d90d5
swift_keystone_provider:test     swift_keystone_provider   test            test        82993dd6-3099-11e8-b8d1-92ca339d90d5

组（groups）的信息来源有2个，一个是后端的Identify Provider，二是通过用户在OpenShift中定义。通过oadm groups命令，可以在Openshift中对组及组的成员进行管理。
创建一个developers组。

[root@master ~]# oadm groups new developersNAME         USERS
developers

将dev用户添加到developers组内。

[root@master ~]# oadm groups add-users developers dev[root@master ~]# oc get groupsNAME         USERS
developers   dev

除了在OpenShift新增及管理组信息外，OpenShift也支持从外部的LDAP及活动目录中导入组信息。

2.权限认证

在多用户系统中，认证和授权是两个必不可少的功能。通过认证（Authentication），系统确认了用户的身份。通过授权（Authoriztion），系统确认用户具体可以查看那些数据，执行那些操作。OpenShift的权限管理是基于角色的访问控制系统（Role Based Access Control，RBAC），即权限可以赋予角色，再将角色赋予组或用户。

2.1.权限对象

要理解OpenShift的权限管理系统，首先要了解以下几个概念。

2.1.1.权限类别

在OpenShift中的权限有两种类别：集群权限（Cluster）和本地权限（Local）。集群权限是由系统管理员定义的，在集群内全局范围可见的。本地权限由用户在某一个项目（命名空间）中定义，只在目标项目可见。集群权限和本地权限都有各自的规则、策略、角色、绑定关系。集群权限的对象类型的名称以Cluster起始，比如Clusterpolicy和Clusterrole。对应的本地权限的对象类型则为Policy及Role。

2.1.2.Role

Role（角色）是一组权限的集合。在基于RBAC系统中，权限一般会先赋予角色，再通过角色传递到用户或组。这样的架构使得授权的模型更加灵活和易于重用。角色分为集群级别的Clusterrole和项目级别的Role。

2.1.3.Rule

通过权限Rule（规则），系统或用户可以定义什么样的角色可以对什么资源执行什么动作。Rule的三个重要的要素是角色（Role）、资源（Resource）和动作（Verb）。所有的Rule会被包含在某个Role的定义中，一个Role可以包含若干条Rule定义，以描述这个角色在系统中可以执行的动作。资源即OpenShift中的对象类型，如Build Config、Pod、Node等。动作即可以对资源进行的操作，如View、Edit、List等。

2.1.4.Policy

若干Role组成的集合构成一个策略（Policy）。策略分为集群级别的Clusterpolicy和项目级别的Policy。

2.1.5.Role Binding

Role Binding（角色绑定关系）定义了角色与具体的用户及组的关联关系。Role Binding同样分为集群和项目两个级别。

2.1.6.Policy Binding

若干Role Binding组成的集合将构成一个Policy Binding（策略绑定关系）。该对象类型同样分为集群和项目两个级别。

2.1.7.用户及组

用户（User）和组（Group）是具体角色的授予对象。

2.2.权限操作

建议从2个层级来管理，集群层级建两个组cluster-admins、cluster-guests组，分别赋予cluster-admin和view角色，本地层级建两个组admins和guests组。本地层级是基于项目（project、namespace）的，所以在给项目赋予组时可分别加上admin和view角色。该类型的账户授权更多的是和资源有关，这要与Service Account账户区别开来。Service Account账户是和容器应用相关的账户，比如镜像构建、容器部署等，详见Service Account。

2.2.1.创建组

命令格式：oc adm groups new <group-name>

[root@master ~]# oc adm groups new cluster-admins[root@master ~]# oc adm groups new cluster-guests[root@master ~]# oc adm groups new admins[root@master ~]# oc adm groups new guests

2.2.2.查看组

查看集群已创建的组。

[root@master ~]# oc get groups</pre>NAME             USERS
admins 
cluster-admins 
cluster-guests 
guests

2.2.3.删除组

命令格式：oc delete groups <group-name>

2.2.4.添加集群级角色

给组添加集群级别角色。注意，使用的是add-cluster-role-to-group。

[root@master ~]# oadm policy add-cluster-role-to-group cluster-admin cluster-adminscluster role "cluster-admin" added: "cluster-admins"[root@master ~]# oadm policy add-cluster-role-to-group view cluster-guestscluster role "view" added: "cluster-guests"

2.2.5.给项目添加本地级角色

给组添加本地级别角色。注意，使用的是add-role-to-group。本地级是基于项目的，因此，需要制定具体项目，若不指定，则为当前项目。

[root@master ~]# oc policy add-role-to-group admin adminsrole "admin" added: "admins"[root@master ~]# oc policy add-role-to-group view guestsrole "view" added: "guests"

2.2.6.查看角色绑定

可以查看某个项目下的角色绑定。

[root@master ~]# oc get rolebindings</pre>NAME                    ROLE                    USERS     GROUPS                                   SERVICE ACCOUNTS   SUBJECTS
admin                   /admin                  devops    admins                                           

system:deployers        /system:deployer                                                           deployer 
system:image-builders   /system:image-builder                                                      builder            

system:image-pullers    /system:image-puller              system:serviceaccounts:hello-world-php                      

view                    /view                             guests

2.2.7.给组添加用户

一个用户可以属于多个组，一个组也可以拥有多个用户。
命令格式：oadm groups add-users <role-name> <user-name>

[root@master ~]# oadm groups add-users cluster-admins devops

2.2.8.给组删除用户

<meta content="text/html; charset=utf-8" http-equiv="Content-Type">命令格式：oadm groups remove-users <role-name> <user-name>

[root@master ~]# oadm groups remove-users cluster-admins devops

2.3.自定义角色

OpenShift默认内置一些系统和项目使用的角色。灵活使用这些角色，可以有效管理系统和项目的权限。如果默认的角色不能满足实际的项目需求，也可以创建自定义的权限策略及角色，为不同的角色管理不同的权限规则，构建满足项目需求的权限模型。下面命令输出OpenShift集群的默认角色列表。

[root@master tmp]# oc get clusterrolesNAMEadminbasic-usercluster-admincluster-debuggercluster-readercluster-statuseditregistry-adminregistry-editorregistry-viewerself-access-reviewerself-provisionerstorage-adminsudoersystem:auth-delegatorsystem:basic-usersystem:build-controllersystem:build-strategy-customsystem:build-strategy-dockersystem:build-strategy-jenkinspipelinesystem:build-strategy-sourcesystem:certificate-signing-controllersystem:controller:attachdetach-controllersystem:controller:certificate-controllersystem:controller:cronjob-controllersystem:controller:daemon-set-controllersystem:controller:deployment-controllersystem:controller:disruption-controllersystem:controller:endpoint-controllersystem:controller:generic-garbage-collectorsystem:controller:horizontal-pod-autoscalersystem:controller:job-controllersystem:controller:namespace-controllersystem:controller:node-controllersystem:controller:persistent-volume-bindersystem:controller:pod-garbage-collectorsystem:controller:replicaset-controllersystem:controller:replication-controllersystem:controller:resourcequota-controllersystem:controller:route-controllersystem:controller:service-account-controllersystem:controller:service-controllersystem:controller:statefulset-controllersystem:controller:ttl-controllersystem:daemonset-controllersystem:deployersystem:deployment-controllersystem:deploymentconfig-controllersystem:discoverysystem:disruption-controllersystem:endpoint-controllersystem:garbage-collector-controllersystem:gc-controllersystem:heapstersystem:hpa-controllersystem:image-auditorsystem:image-buildersystem:image-prunersystem:image-pullersystem:image-pushersystem:image-signersystem:job-controllersystem:kube-aggregatorsystem:kube-controller-managersystem:kube-dnssystem:kube-schedulersystem:mastersystem:namespace-controllersystem:nodesystem:node-adminsystem:node-bootstrappersystem:node-problem-detectorsystem:node-proxiersystem:node-readersystem:oauth-token-deletersystem:openshift:controller:build-config-change-controllersystem:openshift:controller:build-controllersystem:openshift:controller:cluster-quota-reconciliation-controllersystem:openshift:controller:deployer-controllersystem:openshift:controller:deploymentconfig-controllersystem:openshift:controller:horizontal-pod-autoscalersystem:openshift:controller:image-import-controllersystem:openshift:controller:image-trigger-controllersystem:openshift:controller:origin-namespace-controllersystem:openshift:controller:pv-recycler-controllersystem:openshift:controller:resourcequota-controllersystem:openshift:controller:sdn-controllersystem:openshift:controller:service-ingress-ip-controllersystem:openshift:controller:service-serving-cert-controllersystem:openshift:controller:serviceaccount-controllersystem:openshift:controller:serviceaccount-pull-secrets-controllersystem:openshift:controller:template-instance-controllersystem:openshift:controller:template-service-brokersystem:openshift:controller:unidling-controllersystem:openshift:templateservicebroker-clientsystem:persistent-volume-provisionersystem:registrysystem:replicaset-controllersystem:replication-controllersystem:routersystem:scope-impersonationsystem:sdn-managersystem:sdn-readersystem:statefulset-controllersystem:webhookview

自定义的角色并不复杂，建议以现有的角色为基础修改。

作者：四冶
链接：https://www.jianshu.com/p/0843cb4fb7d2