kubernetes rbac 权限管理

Posted 2023-01-09 看，未来

文章目录

• • 访问控制概述
  • kubernetes 下的 rbac
  • ServiceAccount
  • K8s角色&角色绑定
  • • 角色（Role和ClusterRole）
    • 角色绑定（RoleBinding和ClusterRoleBinding）

访问控制概述

访问控制是云原生中的一个重要组成部分，也是一个 Kubernetes 集群在多租户环境下必须要采取的一个基本的安全架构手段。

那么在概念上可以抽象的定义为谁在何种条件下可以对什么资源做什么操作。这里的资源就是在 Kubernetes 中我们熟知的：Pod、ConfigMaps、Deployment、Secrets 等等这样的资源模型。

kubernetes 支持的认证鉴权方式有几个，这里只讲 RBAC。

---

kubernetes 下的 rbac

RBAC 鉴权机制使用 rbac.authorization.k8s.io API 组来驱动鉴权决定， 允许你通过 Kubernetes API 动态配置策略。

要启用 RBAC，在启动 API 服务器时将 --authorization-mode 参数设置为一个逗号分隔的列表并确保其中包含 RBAC。

第一要素是 Subjects，也就是主体。可以是开发人员、集群管理员这样的自然人，也可以是系统组件进程，或者是 Pod 中的逻辑进程；
第二个要素是 API Resource，也就是请求对应的访问目标。在 Kubernetes 集群中也就是各类资源；
第三要素是 Verbs，对应为请求对象资源可以进行哪些操作，包括增删改查、list、get、watch 等。
这里举个例子，假设有个通过合法认证的用户 Bob，他请求 list 某个 namespace下的 Pods，改请求的鉴权语义记为：Can Bob list pods？其中 Bob 即为请求中的 Subject，list 为对应的请求动作 Action，而 pods 为对应的请求资源 Resource。

---

ServiceAccount

K8s的用户分两种，一种是普通用户，一种是ServiceAccount（服务账户）。

普通用户是假定被外部或独立服务管理的。管理员分配私钥。平时常用的kubectl命令都是普通用户执行的。如果是用户需求权限，则将Role与User(或Group)绑定(这需要创建User/Group)，是给用户使用的。这里不多讲。

ServiceAccount（服务帐户）是由Kubernetes API管理的用户。它们绑定到特定的命名空间，并由API服务器自动创建或通过API调用手动创建。服务帐户与存储为Secrets的一组证书相关联，这些凭据被挂载到pod中，以便集群进程与Kubernetes API通信。
如果是程序需求权限，将Role与ServiceAccount指定(这需要创建ServiceAccount并且在deployment中指定ServiceAccount)，是给程序使用的。

相当于Role是一个类，用作权限申明，User/Group/ServiceAccount将成为类的实例。

---

K8s角色&角色绑定

在RABC API中，通过如下的步骤进行授权：

定义角色：在定义角色时会指定此角色对于资源的访问控制的规则。
绑定角色：将主体与角色进行绑定，对用户进行访问授权。

• 角色
  Role：授权特定命名空间的访问权限
  ClusterRole：授权所有命名空间的访问权限

• 角色绑定
  RoleBinding：将角色绑定到主体（即subject）
  ClusterRoleBinding：将集群角色绑定到主体

• 主体（subject）
  User：用户
  Group：用户组
  ServiceAccount：服务账号

角色（Role和ClusterRole）

Role针对特定的命名空间，ClusterRole在整个集群范围内都生效。

Role示例如下：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-role
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

ClusterRole示例如下：

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

相关参数
1、Role、ClsuterRole Verbs可配置参数

“get”, “list”, “watch”, “create”, “update”, “patch”, “delete”, “exec”

2、Role、ClsuterRole Resource可配置参数

“services”, “endpoints”, “pods”,“secrets”,“configmaps”,“crontabs”,“deployments”,“jobs”,“nodes”,“rolebindings”,“clusterroles”,“daemonsets”,“replicasets”,“statefulsets”,“horizontalpodautoscalers”,“replicationcontrollers”,“cronjobs”

3、Role、ClsuterRole APIGroup可配置参数

“”,“apps”, “autoscaling”, “batch”

要确定资源对象API端点请求的动词，请查看HTTP动词以及请求是否对单个资源或资源集合进行操作，参考下表：

HTTP Verb	Request Verb
POST	create
GET，HEAD	get (for individual resources), list (for collections)
PUT	update
PATCH	patch
DELETE	delete (for individual resources), deletecollection (for collections)

---

角色绑定（RoleBinding和ClusterRoleBinding）

定义好了角色也就是一个权限的集合，然后创建了一个ServiceAccount也就是一个服务账号，然后将这两个东西绑定起来，就是授权的过程了。

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: rb
  namespace: default
subjects:
- kind: ServiceAccount
  name: zhangsan
  namespace: default
roleRef:
  kind: Role
  name: pod-role
  apiGroup: rbac.authorization.k8s.io

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: crb
subjects:
- kind: ServiceAccount
  name: mark
  namespace: default
roleRef:
  kind: ClusterRole
  name: pod-clusterrole
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: mark
  namespace: default

---