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