首页 运维干货Kubernetes-一文详解ServiceAccount与RBAC权限控制

Kubernetes-一文详解ServiceAccount与RBAC权限控制

运维派隶属马哥教育旗下专业运维社区,是国内成立最早的IT运维技术社区,欢迎关注公众号:yunweipai
领取学习更多免费Linux云计算、Python、Docker、K8s教程关注公众号:马哥linux运维

一、ServiceAccount

1.ServiceAccount 介绍

首先Kubernetes中账户区分为:User Accounts(用户账户) 和 Service Accounts(服务账户) 两种,它们的设计及用途如下:

  • UserAccount是给kubernetes集群外部用户使用的,例如运维或者集群管理人员,使用kubectl命令时用的就是UserAccount账户;UserAccount是全局性。在集群所有namespaces中,名称具有唯一性,默认情况下用户为admin;

    用户名称可以在kubeconfig中查看

  • ServiceAccount是给运行在Pod的程序使用的身份认证,Pod容器的进程需要访问API Server时用的就是ServiceAccount账户;ServiceAccount仅局限它所在的namespace,每个namespace创建时都会自动创建一个default service account;创建Pod时,如果没有指定Service Account,Pod则会使用default Service Account。

2.Secret 与 SA(ServiceAccount) 的关系

Kubernetes设计了一种Secret资源,分为两类,一种是用于 ServiceAccount 的 kubernetes.io/ service-account-token,就是上边说的 SA,每创建一个SA,就会随之创建一个Secret;另一种就是用户自定义的保密信息Opaque。

3.默认的Service Account

ServiceAccount仅局限它所在的namespace,所以在创建namespace时会自动创建一个默认的 SA,而 SA 创建时,也会创建对应的 Secret,下面操作验证下:

创建名称空间

查看SA

查看 SA 的 Secret

可以看到,创建ns时默认创建了SA,SA默认创建了一个 kubernetes.io/service-account-token类型的secret

创建一个Pod

vim pods.yaml

在不指定SA的情况下,当前 ns下面的 Pod 会默认使用 “default” 这个 SA,对应的 Secret 会自动挂载到 Pod 的 /var/run/secrets/kubernetes.io/serviceaccount/ 目录中,我们可以在 Pod 里面获取到用于身份认证的信息。

进入Pod Container内,查看 SA

4.使用自定义SA

创建一个 SA

同样,手动创建 SA 后,自动创建了对应的 Secret

更新Pod,使用新创建的SA

vim pods.yaml

5.ServiceAccount中添加Image pull secrets

在笔者之前的博客中:Secret介绍及演示( https://www.cnblogs.com/v-fan/p/13269433.html )中提及到,可以使用Secret来保存私人镜像仓库的登录信息,来达到免登录获取image的效果,同样,可以将创建好的Secret直接与SA进行绑定,绑定完成后,只要使用此 SA 的 Pod,都可达到免登录获取image的效果

创建 docker-registry 的 Secret

将 docker-registry 的 Secret 添加到SA

kubectl edit sa vfansa -n vfan

查看 SA 的 Image pull secrets

这个时候,只要是使用此 SA 的Pod,都可以在docker-registry拉取镜像了,同样,可以把此 Secret 添加到default 的 SA 中,达到相同的效果

二、RBAC

1.RBAC介绍

在Kubernetes中,所有资源对象都是通过API对象进行操作,他们保存在etcd里。而对etcd的操作我们需要通过访问 kube-apiserver 来实现,上面的Service Account其实就是APIServer的认证过程,而授权的机制是通过RBAC:基于角色的访问控制实现。

2.Role and ClusterRole

在RBAC API中,Role表示一组规则权限,权限只会增加(累加权限),不存在一个资源开始就有很多权限而通过RBAC对其进行减少的操作:Role 是定义在一个 namespace 中,而 ClusterRole 是集群级别的。

下面我们定义一个Role:

vim roles.yaml

以上Role策略表示在名字为 vfan namespace 中,对Pods有get,watch,list的权限

ClusterRole 具有与 Role 相同权限角色控制能力,不同的就是 Cluster Role是集群级别,它可以用于:

  • 集群级别的资源控制(例如 node 访问权限)
  • 非资源型 endpoints(例如对某个目录或文件的访问:/healthz)
  • 所有命名空间资源控制(Pod、Deployment等)

vim clusterroles.yaml

以上Cluster role策略表示,有get,create,list整个集群service的权限

下面开始创建

可以看到,role和cluster role都已经创建成功,但是clusterrole除了这次创建的还有许多,其中以system开头的全部是系统所用的,其他的都是在装一些插件时自动添加的,也要注意,我们自己创建cluster role时不要以system开通,以免分不清楚

3.RoleBinding and ClusterRoleBinding

RoleBinding可以将角色中定义的权限授予用户或用户组,RoleBinding包含一组权限列表(Subjects),权限列表中包含有不同形式的待授予权限资源类型(users,groups, or Service Account):Rolebinding 同样包含对被 Bind 的 Role 引用;RoleBinding 适用于某个命名空间内授权,ClusterRoleBinding适用于集群范围内的授权。

创建RoleBinding

vim rolebindings.yaml

此策略表示,将名称为test-role的Role的权限资源赋予名为vfan的用户,仅作用于vfan namespace。

RoleBinding也可以引用ClusterRole来对当前 namespace 内用户、用户组或SA来进行授权,这种操作允许管理员在整个集群中定义一些通用的ClusterRole,然后在不同的namespace中使用RoleBinding绑定。

vim rolebindings2.yaml

以上策略表示,将名称为test-clusterrole的ClusterRole的资源权限赋予给了名称为vfan的用户,虽然赋予的是ClusterRole,但是由于Role仅作用于单个namespace,所以此资源策略仅仅对vfan namespace有效

创建ClusterRoleBinding

vim clusterrolebindings.yaml

以上策略表示,将name为test-clusterrole的ClusterRole的资源权限赋予给groupname为vfan的用户组,此用户组下所有用户拥有对整个集群的 test-clusterrole内的资源权限

实践:创建一个用户只能管理名为 vfan 的NameSpace

1.创建系统用户

默认肯定是访问不到的,如果想要访问,必须要创建vfan用户的访问证书

2.为 vfan 用户创建访问证书

创建CA证书签名请求JSON文件

vim vfan-csr.json

开始创建访问证书

3.为 vfan 用户生成集群配置文件

4.进行RoleBinding 验证权限生效

vim vfanrolebind.yaml

把kubeconfig文件复制到 vfan 用户的家目录的.kube下

切换上下文,使kubectl读取到config的信息

开始测试权限

可以get pod,但是不可以get service,因为之前的Role中明确的表示了自己只有get,watch,list Pod的权限

在vfan名称空间下创建测试Deployment

可以看到,vfan用户也可以查看到相对应的Pod,因为vfan用户在get pod时并没有指定名称空间,所以可以证明vfan用户的默认名称空间即是vfan

本文链接:http://www.yunweipai.com/38955.html

网友评论comments

发表评论

电子邮件地址不会被公开。

暂无评论

Copyright © 2012-2020 YUNWEIPAI.COM - 运维派
扫二维码
扫二维码
返回顶部