KUBERNETES之Kubernetes Workloads（Kubernetes 作业管理）五
文章目录
- 3.RBAC
- 3.1 基本概念
- 3.1.1 Role
- 3.1.2 Subject：
- 3.1.3 RoleBinding：
- 3.1.4 ClusterRole
- 3.1.5 ClusterRoleBinding
- 3.2 所有权限
- 3.3 细分授权
- 3.4 User&内置用户
- 3.4.1 User
- 3.4.2 内置用户
- 3.5 RBAC介绍
- 3.6 RBAC0、RBAC1、RBAC2、RBAC3简单介绍。
- 3.6.1 RBAC0，RBAC的核心
- 3.6.2 RBAC1，基于角色的分层模型
- 3.6.3 RBAC2、是RBAC的约束模型
- 3.6.4 RBAC3、就是RBAC1+RBAC2
3.RBAC
在 Kubernetes 项目中，负责完成授权（Authorization）工作的机制，就是 RBAC（Role-Based Access Control）
RBAC 是基于角色的访问控制（Role-Based Access Control ）在 RBAC 中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。这样管理都是层级相互依赖的，权限赋予给角色，而把角色又赋予用户，这样的权限设计很清楚，管理起来很方便。
ABAC（Attribute Based Access Control）基于属性的访问控制
3.1 基本概念
3.1.1 Role
角色，它其实是一组规则，定义了一组对 Kubernetes API 对象的操作权限。
Role是一系列的权限的集合，例如一个Role可以包含读取 Pod 的权限和列出 Pod 的权限， ClusterRole 跟 Role 类似，但是可以在集群中全局使用。
Role只能授予单个namespace 中资源的访问权限。以下是Role“default”namespace 中的示例，用于授予对pod的访问权限：
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: mynamespace
name: example-role
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
允许“被作用者”，对 mynamespace 下面的 Pod 对象，进行 GET、WATCH 和 LIST 操作。
3.1.2 Subject：
被作用者，既可以是“人”，也可以是“机器”，也可以是你在 Kubernetes 里定义的“用户”。
3.1.3 RoleBinding：
定义了“被作用者”和“角色”的绑定关系。
RoleBinding是将Role中定义的权限授予给用户或用户组。它包含一个subjects列表(users，groups ，service accounts)，并引用该Role。RoleBinding在某个namespace 内授权，ClusterRoleBinding适用在集群范围内使用。
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
3.1.4&3.1.5
对于非 Namespaced（Non-namespaced）对象（比如：Node），或者，某一个 Role 想要作用于所有的 Namespace 的时候，API 对象的用法跟 Role 和 RoleBinding 完全一样，少了Namespace
3.1.4 ClusterRole
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: example-clusterrole
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
ClusterRole授权 >= Role授予（与Role类似），但ClusterRole属于集群级别对象：
- 集群范围（cluster-scoped）的资源访问控制（如：节点访问权限）
- 非资源类型（如“/ healthz”）
- 所有namespaces 中的namespaced 资源（如 pod）
3.1.5 ClusterRoleBinding
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
3.2 所有权限
verbs: [“get”, “list”, “watch”, “create”, “update”, “patch”, “delete”]
3.3 细分授权
rules:
- apiGroups: [""]
resources: ["configmaps"]
resourceNames: ["my-config"]
verbs: ["get"]
3.4 User&内置用户
3.4.1 User
Kubernetes 里的“User”，也就是“用户”，只是一个授权系统里的逻辑概念。它需要通过外部认证服务，比如 Keystone，来提供
3.4.2 内置用户
ServiceAccount 特殊的secret
- 权限分配过程
1.定义一个 ServiceAccount
apiVersion: v1
kind: ServiceAccount
metadata:
namespace: mynamespace
name: example-sa
2.定义RoleBinding分配权限
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: example-rolebinding
namespace: mynamespace
subjects:
- kind: ServiceAccount
name: example-sa
namespace: mynamespace
roleRef:
kind: Role
name: example-role
apiGroup: rbac.authorization.k8s.io
3.定义Role
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: mynamespace
name: example-role
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
4.部署api对象
kubectl create namespace mynamespace
kubectl create -f svc-account.yaml
kubectl create -f role-binding.yaml
kubectl create -f role.yaml
5.用户pod申明使用SA
apiVersion: v1
kind: Pod
metadata:
namespace: mynamespace
name: sa-token-test
spec:
containers:
- name: nginx
image: nginx:1.7.9
serviceAccountName: example-sa
- 查询相关
kubectl describe pod sa-token-test -n mynamespace
kubectl describe sa default
- 用户组
ServiceAccount对应的用户名：
system:serviceaccount::
对应的内置“用户组”的名字：system:serviceaccounts:
例子
subjects:
- kind: Group
name: system:serviceaccounts:mynamespace
apiGroup: rbac.authorization.k8s.io
- 内置的ClusterRole
- view
只读权限 - cluster-admin
整个k8s项目拥有最高权限 - 查看命令
kubectl get clusterroles
kubectl describe clusterrole system:kube-scheduler
3.5 RBAC介绍
RBAC 认为授权实际上是Who 、What 、How 三元组之间的关系，也就是Who 对What 进行How 的操作，也就是“主体”对“客体”的操作。
Who：是权限的拥有者或主体（如：User，Role）。
What：是操作或对象（operation，object）。
How：具体的权限（Privilege,正向授权与负向授权）。
然后 RBAC 又分为RBAC0、RBAC1、RBAC2、RBAC3 ，
3.6 RBAC0、RBAC1、RBAC2、RBAC3简单介绍。
- RBAC0：是RBAC的核心思想。
- RBAC1：是把RBAC的角色分层模型。
- RBAC2：增加了RBAC的约束模型。
- RBAC3：其实是RBAC2 + RBAC1。
3.6.1 RBAC0，RBAC的核心
3.6.2 RBAC1，基于角色的分层模型
3.6.3 RBAC2、是RBAC的约束模型
3.6.4 RBAC3、就是RBAC1+RBAC2
