什么是rbac

在 Kubernetes 中，Role-Based Access Control (RBAC) 是一种基于角色(role)的访问控制机制，用于限制用户、Service Account 或组等实体对集群里资源（例如 Pod、Deployment 和 ConfigMap 等）的操作和访问权限。
Role：定义了一组具有相似权限的资源，权限定义确定了能够执行哪些操作（例如 create、delete、get、list 和 watch 等）
RoleBinding：将一个或多个角色分配给用户、Service Account 或组等实体，以决定其可以访问哪些资源并拥有哪些权限。
举个例子：
定义角色，在其中定义了允许的操作（get 和 list）：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: limited-access
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list"]

将角色绑定到特定的资源上，通过 Role Binding 将该角色限制绑定到一个名为 “test-user” 的 Kubernetes 用户身份上，以限制其仅能执行这两个操作：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: limit-access-for-test-user
subjects:
- kind: User
  name: test-user
roleRef:
  kind: Role
  name: limited-access
  apiGroup: rbac.authorization.k8s.io

binding user的前提是需要自己独立创建user,如何创建user,后续文章再分析

什么是sa(service account )

在 Kubernetes（简称 K8S）中，sa 是指 Service Account，即一个由 Kubernetes API 管理的对象，用于表示一个 pod 或一组 pod 以及它们之间与 Kubernetes API 的交互，在 Kubernetes 中扮演着认证和授权的角色。

Kubernetes 中的 sa 拥有自己独立的身份标识，同时也存在一个对应的 Secret 对象用于存储该 sa 的相关凭证信息。在使用 Kubernetes 中的一些资源时（如 Deployment、DaemonSet 等），可以通过为这些资源绑定特定的 sa，来实现这些资源与 Kubernetes API 的交互，并保证其访问权限。

除了默认提供的默认 sa 外，用户还可以根据具体需求创建自定义的 sa。例如，可以针对某一类操作或某一组资源，创建专属的 sa，以限制其访问和操作权限，从而提高安全性。

总之，sa 是 Kubernetes 中的一种重要的身份认证和授权机制，具有很强的灵活性和安全性，常被用于管理容器化应用和服务。
每一个资源都有属于自己的service accout，如何单独创建sa,后续文章再分析

rabc和sa的区别

在 Kubernetes（K8S）中，Service Account（sa）和 Role-Based Access Control（RBAC）都是用来管理访问控制的相关机制，但它们有着不同的作用和职责。

Service Account （sa）是用于认证一个 Pod 或一组 Pod 与 Kubernetes API Server 的通信身份，并为其提供令牌。通过 sa 的权威签名（token），可以授权 Pod 执行一些服务端操作（例如，获取Secrets 和ConfigMaps）.

Role-Based Access Control（RBAC）则是用于控制 Kubernetes 集群范围内的资源访问权限。RBAC 基于用户、角色、绑定和规则等四个概念来实现访问控制。其中，角色（Role）定义了一组具有相似权限的资源，而绑定（Binding）则将一个或多个角色分配给一个用户或 Service Account。在 RBAC 中，管理员可以定义不同的 RBAC 角色，并根据需要授予不同的 Pods、Service 匹配的角色 具体的 privileges。

因此，总结下来，sa 是用于为 Pod 提供身份认证的机制，而 RBAC 则是用于对 Kubernetes 集群范围内的资源访问权限进行控制的机制。两者的作用和职责是不同的，可协助 Kubernetes 运行应用程序及确保集群的安全性。