Kubernetes安全--基于sa和user的rbac认证机制
前言
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-token-name> 替换为前一步中获取到的 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
3、删除kubeconfig的普通用户配置
删除kubeconfig的user
kubectl config unset users.<user-name>
kubectlconfigdelete-user <user-name>
删除kubeconfig的context
kubectl config delete-context <context-name>
查看当前用户上下文
kubectl config get-contexts
