007-用户认证与授权

作者: 四冶读史 | 来源:发表于2018-04-23 23:15 被阅读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.给组删除用户

    <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

    相关文章

      网友评论

        本文标题:007-用户认证与授权

        本文链接:https://www.haomeiwen.com/subject/tbnrlftx.html