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