007-用户认证与授权

2018-04-23 本文已影响29人四冶读史

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 -t
BPWrtdTAjvas6fSGq2pbW_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 developers
NAME         USERS
developers

将dev用户添加到developers组内。

[root@master ~]# oadm groups add-users developers dev
[root@master ~]# oc get groups
NAME         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-admins
cluster role "cluster-admin" added: "cluster-admins"
[root@master ~]# oadm policy add-cluster-role-to-group view cluster-guests
cluster role "view" added: "cluster-guests"

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

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

[root@master ~]# oc policy add-role-to-group admin admins
role "admin" added: "admins"
[root@master ~]# oc policy add-role-to-group view guests
role "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.给组删除用户

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

2.3.自定义角色

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

[root@master tmp]# oc get clusterroles
NAME
admin
basic-user
cluster-admin
cluster-debugger
cluster-reader
cluster-status
edit
registry-admin
registry-editor
registry-viewer
self-access-reviewer
self-provisioner
storage-admin
sudoer
system:auth-delegator
system:basic-user
system:build-controller
system:build-strategy-custom
system:build-strategy-docker
system:build-strategy-jenkinspipeline
system:build-strategy-source
system:certificate-signing-controller
system:controller:attachdetach-controller
system:controller:certificate-controller
system:controller:cronjob-controller
system:controller:daemon-set-controller
system:controller:deployment-controller
system:controller:disruption-controller
system:controller:endpoint-controller
system:controller:generic-garbage-collector
system:controller:horizontal-pod-autoscaler
system:controller:job-controller
system:controller:namespace-controller
system:controller:node-controller
system:controller:persistent-volume-binder
system:controller:pod-garbage-collector
system:controller:replicaset-controller
system:controller:replication-controller
system:controller:resourcequota-controller
system:controller:route-controller
system:controller:service-account-controller
system:controller:service-controller
system:controller:statefulset-controller
system:controller:ttl-controller
system:daemonset-controller
system:deployer
system:deployment-controller
system:deploymentconfig-controller
system:discovery
system:disruption-controller
system:endpoint-controller
system:garbage-collector-controller
system:gc-controller
system:heapster
system:hpa-controller
system:image-auditor
system:image-builder
system:image-pruner
system:image-puller
system:image-pusher
system:image-signer
system:job-controller
system:kube-aggregator
system:kube-controller-manager
system:kube-dns
system:kube-scheduler
system:master
system:namespace-controller
system:node
system:node-admin
system:node-bootstrapper
system:node-problem-detector
system:node-proxier
system:node-reader
system:oauth-token-deleter
system:openshift:controller:build-config-change-controller
system:openshift:controller:build-controller
system:openshift:controller:cluster-quota-reconciliation-controller
system:openshift:controller:deployer-controller
system:openshift:controller:deploymentconfig-controller
system:openshift:controller:horizontal-pod-autoscaler
system:openshift:controller:image-import-controller
system:openshift:controller:image-trigger-controller
system:openshift:controller:origin-namespace-controller
system:openshift:controller:pv-recycler-controller
system:openshift:controller:resourcequota-controller
system:openshift:controller:sdn-controller
system:openshift:controller:service-ingress-ip-controller
system:openshift:controller:service-serving-cert-controller
system:openshift:controller:serviceaccount-controller
system:openshift:controller:serviceaccount-pull-secrets-controller
system:openshift:controller:template-instance-controller
system:openshift:controller:template-service-broker
system:openshift:controller:unidling-controller
system:openshift:templateservicebroker-client
system:persistent-volume-provisioner
system:registry
system:replicaset-controller
system:replication-controller
system:router
system:scope-impersonation
system:sdn-manager
system:sdn-reader
system:statefulset-controller
system:webhook
view

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

参考地址：
https://docs.openshift.org/latest/architecture/additional_concepts/authentication.html#oauth
https://docs.openshift.org/latest/install_config/syncing_groups_with_ldap.html