kubernetes之RBAC

kubernetes集群提供了3种级别的客户端身份认证方式

1. https证书认证： 基于CA根证书签名的双向数字证书认证方式
2. http token认证 ： 通过一个token来识别合法用户
3. http base认证 ： 通过用户名+ 密码的方式认证

api server授权管理

授权： 授予用户不同的访问权限,决定一个api调用是否合法, api server目前支持以下几种授权策略（通过api server启动参数--authorization-mode）: ABAC,RBAC, Webhook

RBAC授权模式详解

1)1.5 版本开始引入, 1.6升级为beta版本, 1.8为GA版本
2)4种资源对象： Role, ClusterRole, RoleBinding , ClusterRoleBinding

RBAC资源对象

1）Role角色： 一个角色就是一组权限的集合, 这里的权限都是许可形式, 不存在拒绝规则, 一个Role角色属于一个命名空间，作用范围是一个命名空间, 角色只能对命名空间内的资源进行授权

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]    

#apiGroups: 支持的API组列表
#resources: 支持的资源对象列表, 例如pods, deployments,job 
#verbs: 对资源列表的操作方法列表, 例如get, watch, list, delete等

2）ClusterRole集群角色: 权限等同于Role, 与Role区别在于作用范围是所有的命名空间, 同时还可以对特殊元素的授权, 例如Node,

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

3）角色绑定（RoleBinding）和集群角色绑定（ClusterRoleBinding）

功能： 角色绑定（RoleBinding）和集群角色绑定（ClusterRoleBinding）用来把一个Role或ClusterRole绑定到一个目标上, 目标可以是User用户丶Group组丶ServiceAccount, 
RoleBinding作用于一个命名空间, ClusterRoleBinding作用于所有命名空间

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io


kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-secrets
  namespace: development
subjects:
- kind: User
  name: dave
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

#注意： secret-reader是一个集群角色, 但是因为使用了RoleBinding，所以dave只能读取deployment命名空间中的secret

使用kubectl为ServiceAccount授权管理

1.为my-namespace的指定serviceaccount授予clusterole中的view权限
kubectl create rolebinding my-sa-view --clusterrole=view --serviceaccount=my-namespace:my-sa --namespace=my-namespace 

2. 为my-namespace命名空间的中的默认serviceaccount授权clusterrole的view权限
kubectl create rolebinding default-view --clusterrole=view --serviceaccount=my-namespace:default --namespace=my-namespace

3. 为my-namespace命名空间中的所有serviceaccount授权clusterrole的view权限
kubectl create rolebinding serviceaccounts-view --clusterrole=view --group=system:serviceaccounts:my-namespace --namespace=my-namespace      

${namespace}:${serviceaccount}  #指定namespace下的serviceaccount
${namespace}:default            #指定namespace下的默认default serviceaccount
system:serviceaccounts:${namespace} #指定namespace下的所有serviceaccount
system:serviceaccounts   #所有命名空间下的serviceaccount

转载于:https://www.cnblogs.com/lovelinux199075/p/11265086.html