k8s RBAC 角色访问控制详解与生产中的实际应用案例

🐇明明跟你说过：个人主页

🏅个人专栏：《Kubernetes航线图：从船长到K8s掌舵者》 🏅

🔖行路有良友，便是天堂🔖

一、前言

1、k8s简介

2、RBAC简介

二、RBAC关键资源

1、Role

2、Cluster Role

3、RoleBinding

4、ClusterRoleBinding

5、主体(Subject)

三、实际应用

案例1

案例2

一、前言

1、k8s简介

Kubernetes单词起源于希腊语, 是“舵手”或者“领航员、飞行员”的意思。

Kubernetes（简称K8s）的前世今生可以追溯到谷歌（Google）内部的一个项目，它起源于2003年，当时谷歌正面临着不断增长的应用程序和服务的管理挑战。这个项目最初被称为"Borg"，是一个早期的容器编排系统。Borg 的成功经验成为 Kubernetes 开发的契机。

有关k8s起源的介绍，请参考《初识K8s之前世今生、架构、组件、前景》这篇文章

Kubernetes的优点包括可移植性、可伸缩性和扩展性。它使用轻型的YAML清单文件实现声明性部署方法，对于应用程序更新，无需重新构建基础结构。管理员可以计划和部署容器，根据需要扩展容器并管理其生命周期。借助Kubernetes的开放源代码API，用户可以通过首选编程语言、操作系统、库和消息传递总线来构建应用程序，还可以将现有持续集成和持续交付（CI/CD）工具集成。

2、RBAC简介

K8s RBAC（Role-Based Access Control，基于角色的访问控制）是Kubernetes（通常简称为K8s）中用于控制用户对集群资源访问权限的一种机制。RBAC允许管理员通过定义角色（Role）和角色绑定（RoleBinding）来管理用户对集群资源的访问权限。

二、RBAC关键资源

1、Role

在Kubernetes（K8s）中，Role是一种命名空间级别的资源，它允许对命名空间内的资源进行细粒度的访问控制。Role是一组权限的集合，用于给某个Namespace中的资源进行鉴权。具体来说，Role资源类型的rules字段用于定义哪些操作（verbs）可以在哪些资源（resources）上执行。

resources字段指定了角色可以访问的资源类型。这些资源类型可以是Kubernetes API中定义的任何资源，例如Pods、Services、Deployments、ConfigMaps等。可以在resources字段中列出多个资源类型，以允许角色访问这些类型的资源。
verbs字段定义了角色可以对资源执行的操作。

2、Cluster Role

在Kubernetes（K8s）中，ClusterRole是一种特殊类型的角色，它允许对整个集群中的资源进行授权，而不仅仅是单个命名空间中的资源。与Role对象不同，ClusterRole对象是集群范围的。这意味着ClusterRole对象可以控制整个Kubernetes集群中的资源。

ClusterRole通常用于定义对集群级别资源的权限，例如节点（nodes）或持久卷（persistent volumes）。通过ClusterRole，管理员可以授予用户、组或服务帐户对集群级别资源的访问权限，以实现跨命名空间的统一权限管理。
与Role类似，ClusterRole也包含一组规则（rules），用于定义哪些操作（verbs）可以在哪些资源（resources）上执行。这些规则决定了ClusterRole的权限范围。

在实际使用中，管理员通常会创建ClusterRole的定义文件，描述所需的权限，并将其应用于整个集群。然后，通过ClusterRoleBinding，管理员可以将ClusterRole与用户、组或服务帐户绑定在一起，以授予其相应的权限。

ClusterRole是Kubernetes中用于实现集群级别资源访问控制的重要机制，它允许管理员对整个集群的资源进行统一的权限管理。

3、RoleBinding

在Kubernetes（K8s）中，RoleBinding是一种用于绑定角色（Role）和用户、服务账户或组的机制。通过RoleBinding，可以将Role中定义的权限赋予特定的用户、服务账户或组，从而实现对这些实体在K8s集群中的访问控制。

RoleBinding可以确保只有经过授权的用户、服务账户或组能够执行特定的操作或访问特定的资源。这提供了一种灵活且安全的方式来管理K8s集群中的权限。
RoleBinding通常是在创建Role之后进行的。管理员首先定义Role，指定角色所拥有的权限和操作范围，然后创建RoleBinding，将Role绑定到特定的用户、服务账户或组上。这样，被绑定的实体就会继承Role中定义的权限，并能够在集群中执行相应的操作。
RoleBinding可以在特定的命名空间内创建，用于控制该命名空间内的资源访问。同时，K8s也提供了ClusterRoleBinding的概念，用于在集群级别进行角色绑定，从而实现对整个集群资源的访问控制。

RoleBinding是K8s中权限管理的重要组成部分，它通过将角色与实体进行绑定，实现了对集群资源的精细控制，提高了系统的安全性和可靠性。

4、ClusterRoleBinding

ClusterRoleBinding在Kubernetes（K8s）中，是一种用于绑定ClusterRole（集群角色）到用户、服务账户或组的机制。它与RoleBinding类似，但作用范围更广，适用于整个Kubernetes集群，而不仅仅是特定的命名空间。

通过ClusterRoleBinding，管理员可以将ClusterRole中定义的权限赋予给集群级别的用户、服务账户或组。这意味着被绑定的实体将能够在整个集群范围内执行ClusterRole中定义的操作和访问资源。

ClusterRoleBinding提供了一种集中管理集群级别权限的方式，使得管理员能够更方便地控制哪些实体在集群中拥有哪些权限。它可以帮助确保只有经过授权的用户、服务账户或组能够执行特定的操作或访问特定的资源，从而提高集群的安全性和可靠性。

需要注意的是，与RoleBinding不同，ClusterRoleBinding不局限于特定的命名空间，而是在整个集群范围内生效。这使得它成为管理跨命名空间资源的权限的理想选择。

5、主体(Subject)

在Kubernetes（K8s）的RBAC（基于角色的访问控制）中，主体（Subject）是一个核心概念，它代表了当前与K8s集群交互的实体。这个实体可以是一个具体的用户、一个用户组或一个服务账户。简而言之，Subject就是一个能够发起请求并希望访问K8s资源的实体。

在RBAC模型中，Subject会尝试执行某些操作（如读取、写入或删除资源）。为了判断这些操作是否被允许，系统会首先进行身份验证（Authentication），验证Subject的身份是否合法。如果验证通过，接着系统会进行授权（Authorization），即根据定义好的Role和ClusterRole以及它们与Subject的绑定关系（通过RoleBinding和ClusterRoleBinding），来判断Subject是否拥有执行这些操作的权限。

因此，Subject在RBAC中起到了至关重要的作用，它是访问控制的基础，也是系统判断请求是否合法的依据。管理员通过合理配置Role、ClusterRole、RoleBinding和ClusterRoleBinding，可以实现对Subject的精细权限控制，确保只有经过授权的实体才能访问和操作K8s集群中的资源。

三、实际应用

案例1

要求：

创建一个名为deployment-clusterrole的clusterrole，该clusterrole只允许对Deployment、
Daemonset.
Statefulset具有create权限，在现有的 namespace app-team1中创建一个名为cicd-token的新 ServiceAccount。
限于 namespace app-team1中，将新的ClusterRole deployment-custerrole绑定到新的 ServiceAccount cicd-token。

实现：

创建名为deployment-clusterrole的ClusterRole，授予对Deployment、Daemonset和Statefulset资源对象的create权限。
在现有的namespace app-team1中创建一个名为cicd-token的新ServiceAccount。
将新创建的ClusterRole deployment-clusterrole绑定到新创建的ServiceAccount cicd-token，限制在namespace app-team1中。

示例YAML，用于实现上述步骤：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: deployment-clusterrole
rules:
- apiGroups: [""]
  resources: ["deployments", "daemonsets", "statefulsets"]
  verbs: ["create"]

---

apiVersion: v1
kind: ServiceAccount
metadata:
  name: cicd-token
  namespace: app-team1

---

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cicd-token-deployment-clusterrole
roleRef:
  kind: ClusterRole
  name: deployment-clusterrole
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  name: cicd-token
  namespace: app-team1

我们可以将以上内容保存为一个YAML文件，然后通过kubectl apply命令将其应用到你的Kubernetes集群中。

案例2

要求：

1. Namespace级别的Role和ServiceAccount绑定：

创建名为deployment-role的Role，授予对Deployment资源的get和list权限。
在现有的namespace app-team1中创建一个名为cicd-token的新ServiceAccount。
将新创建的Role deployment-role绑定到新创建的ServiceAccount cicd-token，限制在namespace app-team1中。

2. ClusterRole和ServiceAccount的全局绑定：

创建名为read-only-clusterrole的ClusterRole，授予对所有资源对象的get和list权限。
创建名为readonly的新ServiceAccount，无需指定namespace。
将新创建的ClusterRole read-only-clusterrole绑定到新创建的ServiceAccount readonly，使其在整个集群中拥有只读权限。

3. 自定义资源（Custom Resource Definitions）的权限管理：

创建名为crd-admin-clusterrole的ClusterRole，授予对自定义资源对象的管理权限（例如，get、list、create、update、delete）。
在现有的namespace app-team2中创建一个名为crd-admin的新ServiceAccount。
将新创建的ClusterRole crd-admin-clusterrole绑定到新创建的ServiceAccount crd-admin，限制在namespace app-team2中。

实现：

Namespace级别的Role和ServiceAccount绑定：

# 创建Role
kubectl create role deployment-role --verb=get,list --resource=deployments

# 创建ServiceAccount
kubectl create serviceaccount cicd-token -n app-team1

# 绑定Role到ServiceAccount
kubectl create rolebinding deployment-rolebinding --role=deployment-role --serviceaccount=app-team1:cicd-token -n app-team1

ClusterRole和ServiceAccount的全局绑定：

# 创建ClusterRole
kubectl create clusterrole read-only-clusterrole --verb=get,list --resource=*

# 创建ServiceAccount
kubectl create serviceaccount readonly

# 绑定ClusterRole到ServiceAccount
kubectl create clusterrolebinding readonly-clusterrolebinding --clusterrole=read-only-clusterrole --serviceaccount=default:readonly

自定义资源（Custom Resource Definitions）的权限管理：

# 创建ClusterRole
kubectl create clusterrole crd-admin-clusterrole --verb=get,list,create,update,delete --resource=customresourcedefinitions

# 创建ServiceAccount
kubectl create serviceaccount crd-admin -n app-team2

# 绑定ClusterRole到ServiceAccount
kubectl create clusterrolebinding crd-admin-binding --clusterrole=crd-admin-clusterrole --serviceaccount=app-team2:crd-admin -n app-team2

这些命令将创建相应的角色（Role或ClusterRole）和ServiceAccount，并将角色绑定到ServiceAccount上，以便在Kubernetes集群中控制资源访问权限。