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.给组删除用户
<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 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
网友评论