首页 > 运维 > kubernetes(k8s) > k8s RABC角色权限整理-实操
2020
11-18

k8s RABC角色权限整理-实操

首先明确一下RABC的三个基本概念:

  • Role: 角色,它定义了一组规则,定义了一组对Kubernetes API对象的操作权限
  • Subject: 被作用者,既可以是”人”,也可以是机器,当然也可以是我们K8s中定义的用户(ServiceAccount主要负责kubernetes内置用户)
  • RoleBinding: 定义了”被作用者”和”角色”的绑定关系

角色分为两种 :

一种是Role,负责命名空间(namespace)内的权限

一种是ClusterRole,负责整个Kubernetes集群范围内的权限

使用方式:

1.用户使用:如果是用户需求权限,则将Role/ ClusterRole 与 User(或Group)绑定(这需要创建User/Group)。

2.程序使用:如果是程序需求权限, 将Role / ClusterRole 与 ServiceAccount指定(这需要创建ServiceAccount并且在deployment中指定ServiceAccount)。

RBAC API对象

用户使用

1.Role 和 Rolebinding

Role(可以理解为设定权限)它本身就是一个Kubernetes的API对象,定义文件如下:

解释:

用户的权限对应的API资源对象已经创建了,但是还没有绑定。也就是只有一个规则没有规定哪些用户使用这个权限

这里进行Rolebinding 介绍 :(绑定设定好的权限给某个用户)

解析:


2.ClusterRole 和 ClusterRoleBinding

在上面的例子中,ClusterRole和ClusterRoleBinding的组合,意味着名叫example-user的用户,拥有对所有namespace里的Pod进行Get、Watch、List操作的权限。

类似的,Role对象的rules字段也可以进一步细化,可以只针对某一个具体权限对象进行设置

上面的例子表示,这条规则的”被作用者”,只对my-config的configmap对象有权限进行get操作。


前面说过,在Kubernetes中已经内置了很多个位系统保留的ClusterRole,它们的名字都是以system:开头。一般来说,这些内置的ClusterRole,是绑定给Kubernetes系统组件对应的ServiceAccount使用.

通过命令获取: kubectl get clusterroles

此外,Kubernetes还提供了四个预先定义好的ClusterRole来提供用户直接使用

  • cluster-admin
  • admin
  • edit
  • view

其中cluster-admin角色,对应的是整个Kubernetes项目中最高权限(verbs=*)

我们可以通过下面的命令查看clusterrole的权限

程序使用

ServiceAccount

前面所介绍的大多数时候都不怎么使用,ServiceAccount主要负责kubernetes内置用户,下面简单定义一个ServiceAccount

我们定义的这个serverAccount对象,只需要name以及namespace最基础字段就可以。然后通过编写rolebinding的yaml文件,来为这个serviceAccount分配权限 。

在这个Rolebinding对象里,subject字段的类型(kind),不在是一个User,而是一个名叫example-sa的ServerAccount。而roleRef引用的Role对象,依然是前头定义的名叫example-role的角色权限

创建并演示:

K8s会为ServiceAccount自动创建一个Secret对象,即ServiceAccount定义最下面的secrets字段。其中,这里的secret就是ServiceAccount对应来跟APIServer进行交互的授权文档,一般为TOken,保存证书和密码等,它以一个Secret对象保存在ETCD中

这时候我们就可以直接在pod中引用这个serviceAccount了

接下来我们可以通过describe查看pod状态

我们可以到Pod目录进行查看

在Kubernetes集群访问主要是通过ca.crt来访问Apiserver,更重要的是此时它只可以做GET、WATCH和LIST操作。因为example-sa这个ServiceAccount的权限已经被我们绑定了role限制。

如果一个Pod没有声明ServiceAccount,Kubernetes会自动在它的namespace创建一个名称为default的默认ServiceAccount,然后分配给Pod。但是这种情况下默认ServiceAccount没有关联任何Role。也就是说它有APIServer的绝大多数权限 .

用户组概念

User 和 Group

Kubernetes除了有用户(User),还拥有用户组(Group)概念,如果我们Kubernetes配置了外部认证服务的话,这个用户组的概念就由外部认证服务提供

一个ServiceAccount在Kubernetes对应的用户的名字是

而对应的用户组则是

比如,我们可以在RoleBinding中定义如下subjects

这就意味着role的规则权限,作用于mynamespace(这个命名空间里 -n mynamespace)里的所有ServiceAccount,这就用到了用户组的概念

如果这样写,这个role的规则权限,则作用于整个系统里ServiceAccount


实践:

一:创建一个只能访问某个namespace的ServiceAccount

当我们创建一个sa之后,会自动帮我们创建一个secrets

接下来可以查看一下sa

也可以通过get secret查看

我们需要创建一个role (角色)对象与sa进行关联

yaml文件如下:

这里我们创建的role设置的权限是对pod有get和list权限,对deployment有下面其他权限

执行文件yaml

检查状态

我们刚刚在kube-sytem下创建一个名称为sa-role的role(角色权限)

角色创建完成之后我们就需要创建一个RoleBinding

yaml文件如下

查看

这时候我们创建的ServerAccount已经和我们role(角色权限)进行绑定了,通过rolebinding进行绑定。下面可以进行测试

测试:

首先我们复制我们创建sa中secret里面的token

现在token已经创建好了,我们使用dashboard进行演示 (不同权限看到的资源对象不同)

复制token登录dashboard

当我们登陆到dashboard界面上,默认访问的为default命名空间,因为我们授权的是kube-system空间,所以很多地方没有权限。会有下面的403报错

我们将default修改为kube-system即不会再报错


二、创建一个可以访问所有namespace的ServiceAccount

上面创建单个namespace访问权限主要是用了role和rolebinding,接下来我们使用clusterRole和ClusterRoleBinding进行演示。使用role和rolebinding只会绑定特定的namespace下,clusterRole会绑定到集群下

首先创建一个ServiceAccount对象

再创建一个ClusterRoleBinding

接下来开始创建

查看secret中root-sa的token

使用此token再次登录dashboard

访问进来就没有error报错,也就是现在serviceAccount已经绑定到最高权限的root-sa。可以访问所有资源对象,并且增删改查权限都有

(完)

最后编辑:
作者:shooter
这个作者貌似有点懒,什么都没有留下。

留下一个回复

你的email不会被公开。