Kubernetes安全--基于sa和user的rbac认证机制
K8S中有两种用户(User)——服务账号(ServiceAccount)和普通意义上的用户(User)ServiceAccount是由K8S管理的,而User通常是在外部管理,K8S不存储用户列表——也就是说,添加/编辑/删除用户都是在外部进行,无需与K8S API交互,虽然K8S并不管理用户,但是在K8S接收API请求时,是可以认知到发出请求的用户的,实际上,所有对K8S的API请求都需要绑定
作者:雅泽
前言
Kubernetes中的用户
K8S中有两种用户(User)——服务账号(ServiceAccount)和普通意义上的用户(User)
ServiceAccount是由K8S管理的,而User通常是在外部管理,K8S不存储用户列表——也就是说,添加/编辑/删除用户都是在外部进行,无需与K8S API交互,虽然K8S并不管理用户,但是在K8S接收API请求时,是可以认知到发出请求的用户的,实际上,所有对K8S的API请求都需要绑定身份信息(User或者ServiceAccount),这意味着,可以为User配置K8S集群中的请求权限。
有什么区别?
最主要的区别上面已经说过了,即ServiceAccount是K8S内部资源,而User是独立于K8S之外的。从它们的本质可以看出:
- User通常是人来使用,而ServiceAccount是某个服务/资源/程序使用的
- User独立在K8S之外,也就是说User是可以作用于全局的,在任何命名空间都可被认知,并且需要在全局唯一,而ServiceAccount作为K8S内部的某种资源,是存在于某个命名空间之中的,在不同命名空间中的同名ServiceAccount被认为是不同的资源
- K8S不会管理User,所以User的创建/编辑/注销等,需要依赖外部的管理机制,K8S所能认知的只有一个用户名 ServiceAccount是由K8S管理的,创建等操作,都通过K8S完
这里说的添加用户指的是普通意义上的用户,即存在于集群外的用户,为k8s的使用者。
实际上叫做添加用户也不准确,用户早已存在,这里所做的只是使K8S能够认知此用户,并且控制此用户在集群内的权限。
1、基于Sa的rbac权限认证
1.1、基于kubeconfig的权限认证
下面是一个通过admin用户,创建的sa去生成普通用户的kubeconfig文件,我们可以把admin用户部分删除就是一个属于sa用户的kubeconfig文件了(只拥有sa用户权限)
apiVersion: v1
clusters: //clusters 用于集群认证
- cluster:
certificate-authority-data: //用于集群认证的密钥数据
server: https://172.16.83.156:6443 //Server 字段: 存储集群的地址
name: kubernetes
contexts: //context 上下文,用户和集群的组合 采用某个 context :表示采用某个用户去管控某个集群
默认情况是,采用 admin 用户管控集群,具有所有资源的创建权限
- context:
cluster: kubernetes
namespace: emr-k8s
user: emr-admin
name: emr-admin-context
- context:
cluster: kubernetes
user: kubernetes-admin
name: kubernetes-admin@kubernetes
current-context: emr-admin-context //当前使用的用户
kind: Config
preferences: {}
users:
- name: emr-admin
user:
token: //这边用户是通过sa创建的他这边认识密钥使用的token数据
- name: kubernetes-admin
user:
client-certificate-data:
client-key-data:
1.2、如何使用 ServiceAccount 创建 kubeconfig 中的 User
1、SA 通过 RoleBinding 绑定 Role ,具有 Role 权限,只能操作 Role 所在 namespace
可以实现 SA 具有操作别的 namespace 中资源的权限(例如 SA 在 ns1, Role 在 ns2,SA 可操作 ns2 资源);
2、SA 通过 RoleBinding 绑定 ClusterRole, 具有 ClusterRole 权限,只能操作 SA 所在的 namespace
可以实现 SA 在所在 namespace 具有高权限,但不能跨出当前 namespace;
3、SA 通过 ClusterRoleBinding 绑定 ClusterRole,具有 ClusterRole 权限,可操作所有 namespace 和集群资源
没有 ClusterRoleBinding 与 Role de 组合。
apiVersion: v1
kind: ServiceAccount
metadata:
labels:
app: emr-admin
name: emr-admin
namespace: emr-k8s
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
labels:
app: emr-admin
name: emr-admin-role
namespace: emr-k8s
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
labels:
app: emr-admin
name: emr-admin-role-binding
namespace: emr-k8s
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: emr-admin-role
subjects:
- kind: ServiceAccount
name: emr-admin
namespace: emr-k8s
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
app: emr-admin
name: emr-admin-clusterrole
namespace: emr-k8s
rules:
- apiGroups: ["core.oam.dev"]
resources: ["*"]
verbs: ["*"]
- apiGroups: [""]
resources: ["configmaps", "events"]
verbs: ["*"]
- apiGroups: ["apiextensions.k8s.io"]
resources: ["customresourcedefinitions"]
verbs: ["create", "get", "list", "delete", "update"]
- apiGroups: ["apps"]
resources: ["controllerrevisions"]
verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
labels:
app: emr-admin
name: emr-admin-clusterrole-binding
namespace: emr-k8s
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: emr-admin-clusterrole
subjects:
- kind: ServiceAccount
name: emr-admin
namespace: emr-k8s
通过上述yaml文件我们创建了一个有相关使用权限的sa,现在我们可以给这个sa加入到kubeconfig中,将这个kubeconfig提供给外部人员使用即可。
首先,使用以下命令获取 emr-admin(这里是你创建的sa用户的token) 的 token:
kubectl get sa emr-admin -n emr-k8s -o jsonpath='{.secrets[0].name}'
这将返回 emr-admin 的凭据(Secret)的名称。
1、接下来,使用以下命令获取 emr-admin 的 token 的值:
kubectl get secret <emr-admin-token-name> -n emr-k8s -o jsonpath='{.data.token}' | base64 --decode
将 替换为前一步中获取到的 emr-admin 的凭据名称。
2、得到 emr-admin 的 token 后,可以使用以下命令创建 emr-admin 的 kubeconfig 文件:
若配置访问已有的集群信息,忽略此步
若添加新集群,则需要添加下面信息
$ kubectl config set-cluster new-cluster-name(自定义) --server https://172.16.83.156:6443 --certificate-authority /home/xxx/ca.crt(ca文件绝对路径) --embed-certs=true
Cluster “new-cluster-name” set.
kubectl config set-credentials emr-admin --token=<emr-admin-token-value>
kubectl config set-context emr-admin-context --cluster=<cluster-name>(默认kubernetes,除非有自建) --namespace=emr-k8s --user=emr-admin
kubectl config use-context emr-admin-context //这条命了是在命令行切换当前使用的context
我们可以使用
[root@172-16-83-156 ~]# kubectl config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
emr-admin-context kubernetes emr-admin emr-k8s
* kubernetes-admin@kubernetes kubernetes kubernetes-admin
---
查看能够使用的用户上下文,此时可以查看~/.kube/config文件可以发现文件中多了一个emr-admin用户,如何需要向外部提供文件记得删除k8s用户相关的即可
验证用户是否有某些权限
# 测试权限 因为 k8s User 绑定的 serveraccount, 所以 k8s User 本身并没有权限
$ kubectl auth can-i get deoloyment --namespace emr-k8s --as emr-admin
no
# ServiceAccount 才有权限
kubectl auth can-i get deoloyment --namespace emr-k8s --as system:serviceaccount:emr-k8s:emr-admin
yes
2、删除kubeconfig的普通用户配置
删除kubeconfig的user
kubectl config unset users.<user-name>
- kubectlconfigdelete-user
删除kubeconfig的context
kubectl config delete-context <context-name>
查看当前用户上下文
kubectl config get-contexts
更多技术信息请查看云掣官网https://yunche.pro/?t=yrgw
更多推荐
所有评论(0)