Kubernetes中所有的API对象都是保存在etcd里,对于这些API对象的凡操作一定都是通过访问kube-apiserver来实现的,其中一个非常重要的原因是,需要API Server来做授权工作,而在Kubernetes项目中,负责完成授权工作的机制是RBAC
RBAC有3个基本概念:
- Role:角色,它其实是一组规则,定义了一组对Kubernetes API对象的操作权限
- Subject:被作用者,既可以是”人“,也可以是”奇迹“,也可以是在Kubernetes中定义的”用户“
- RoleBinding:定义了Role和Subject之间的关系
Role实际上是一个API对象,其一个典型的声明如下:
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: mynamespace
name: example-role
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
这个Role定义了一组权限规则,允许“被作用者”对mynamespace下的Pod对象进行GET、WATCH和LIST操作
具体的“被作用者”需要通过RoleBinding来实现,RoleBinding本身也是一个API对象,一个典型的声明如下:
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: example-rolebinding
namespace: mynamespace
subjects:
- kind: User
name: example-user
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: example-role
apiGroup: rbac.authorization.k8s.io
这里定义了一个subject字段,它指定了name为example-user的User作为权限对象
对于非Namespaced对象(比如Node),或者某个Role想作用于所有Namespace时,就需要使用ClusterRole和ClusterRoleBinding这两个组合。
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: example-clusterrole
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io.v1
metadata:
name: example-clusterrolebinding
subjects:
- kind: User
name: example-user
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: example-clusterrole
apiGroup: rbac.authorization.k8s.io
大多数时候,我们其实并不太使用“用户”这个功能,而是直接使用Kubernetes里的”内置用户“,这个由Kubernetes负责管理的”内置用户“,正是ServiceAccount
apiVersion: v1
kind: ServiceAccount
metadata:
namespace: mynamespace
name: example-sa
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: aexample-rolebinding
namespace: mynamespace
subject:
- kind: ServiceAccount
name: example-sa
namespace: mynamespace
roleRef:
kind: Role
name: example-role
apiGroup: rbac.authorization.k8s.io
Kubernetes会为一个ServiceAccount自动创建并分配一个Secret对象,用来跟API Server进行交互授权,它保存在etcd中