Kubernetes RBAC 101: 如何使用辅助命令加强安全控制-51CTO.COM

今天，我们继续深入 Kubernetes 的世界，探索一些关键但不太显眼的辅助命令，这些命令对于加强集群的安全控制至关重要。我将详细介绍这些工具，它们能够帮助我们更加有效地理解和管理 RBAC 策略，确保我们的 Kubernetes 环境的安全。

初始准备

在开始之前，我们在集群中创建了一个供开发者使用的命名空间 developer，并配置了必要的资源，这些步骤包括创建命名空间、服务账号、服务账号秘钥（token），以及定义了具体的角色和角色绑定：

# 1. 创建 namespace
kubectl create ns developer

# 2. 创建 ServiceAccount
kubectl -n developer create serviceaccount owner

# 3. 创建服务账号 token 类型的 secret
cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: owner-secret
  namespace: developer
  annotations:
    kubernetes.io/service-account.name: owner
type: kubernetes.io/service-account-token
EOF

# 4. 创建角色
kubectl create role Owner \
  --resource pods,services,endpoints,secrets \
  --verb get,list,watch \
  -n developer

# 5. 将这个 Owner 角色的权限授予服务账号 developer:owner
kubectl create rolebinding owner-binding \
  --role=Owner \
  --serviceaccount=developer:owner \
  -n developer

kubectl auth can-i

kubectl auth can-i 是一款实用的权限检查工具，用于验证用户或服务账户是否有权限执行特定的 Kubernetes 操作。

好比说，我们可以验证在初始化阶段是否正确地限制了创建 Pod 的权限：

➜ kubectl --kubeconfig dev-config auth can-i create pod
no

同样，用户也可以通过以下命令，来检查自己是否在当前命名空间中拥有执行所有操作的权限：

➜ kubectl --kubeconfig dev-config auth can-i '*''*'
no

管理员还可以使用 --as 参数来模拟任何服务账户的权限，进一步检查权限设置：

➜ kubectl auth can-i \
    get pods --as=system:serviceaccount:developer:owner -n developer
yes

➜ kubectl auth can-i \
    create pod --as=system:serviceaccount:developer:owner -n developer
no

局限性

尽管 kubectl auth can-i 实用，但它不支持复杂查询，也不能提供完整的权限视图。

作为集群管理员，如果我想要知道某个资源的特定操作都有哪些人拥有，它就更加做不到了 🤦

kubectl-who-can

kubectl-who-can[1] 是一个进阶工具，扩展了 Kubernetes 的原生功能，提供了对 RBAC 策略的深入分析，帮助管理员和开发者能够快速了解谁有权限执行特定的操作。

它主要用于显示哪些主体（用户、组、服务账户等）有权限执行指定的动作（如创建、获取、删除）在特定的资源上。这是通过分析现有的 RBAC 配置来实现的。

安装

我们可以通过 Krew 非常方便的安装它：

kubectl krew install who-can

如何使用？

例如，要找出哪些用户或服务账户有权在特定命名空间中获取 Pod，可以运行以下命令：

➜ kubectl who-can get pods -n developer
ROLEBINDING    NAMESPACE  SUBJECT  TYPE            SA-NAMESPACE
owner-binding  developer  owner    ServiceAccount  developer

CLUSTERROLEBINDING                             SUBJECT                                 TYPE            SA-NAMESPACE
cluster-admin                                  system:masters                          Group
system:kube-scheduler                          system:kube-scheduler                   User
system:controller:deployment-controller        deployment-controller                   ServiceAccount  kube-system
system:controller:endpoint-controller          endpoint-controller                     ServiceAccount  kube-system
system:controller:endpointslice-controller     endpointslice-controller                ServiceAccount  kube-system
system:controller:ephemeral-volume-controller  ephemeral-volume-controller             ServiceAccount  kube-system
system:controller:generic-garbage-collector    generic-garbage-collector               ServiceAccount  kube-system
system:controller:namespace-controller         namespace-controller                    ServiceAccount  kube-system
system:controller:node-controller              node-controller                         ServiceAccount  kube-system
system:controller:persistent-volume-binder     persistent-volume-binder                ServiceAccount  kube-system
system:controller:statefulset-controller       statefulset-controller                  ServiceAccount  kube-system
system:controller:pvc-protection-controller    pvc-protection-controller               ServiceAccount  kube-system
k3s-cloud-controller-manager                   k3s-cloud-controller-manager            User            kube-system
local-path-provisioner-bind                    local-path-provisioner-service-account  ServiceAccount  kube-system
system:k3s-controller                          system:k3s-controller                   User
cert-manager-controller-challenges             cert-manager                            ServiceAccount  cert-manager
xfs2-csi-driver                                xfs2-csi-driver-controller-sa           ServiceAccount  xfs2-csi-driver

这个命令将列出所有有权限在 developer 命名空间获取 Pod 的主体（同时包括 namespace 级别和 cluster 级别）。这对于审核权限、准备安全报告或进行故障排除非常有用。

kubectl-who-can 的优势

深入的权限分析：与 K8s 自带的 kubectl auth can-i 相比，kubectl-who-can 提供了更全面的视角，不仅能告知你是否有权限，还能指出集群中谁有这些权限。
安全审计：这个工具对于安全团队来说尤其重要，因为它有助于快速识别可能的权限过度分配。
简化故障排除：在调试权限问题时，能够迅速找出有权限执行特定操作的所有主体，大大简化了问题解决的过程。

局限性

尽管 kubectl-who-can 在权限管理和安全审计方面极为有效，但它的输出仅基于当前的 RBAC 配置。

kubectl-rolesum

随后，我们将转向 kubectl-rolesum[2]，这是一个非常实用的第三方工具，提供了对角色和角色绑定的清晰视图。

它的主要功能是汇总和显示特定 K8s 实体（如用户、组或服务账户）的角色权限，这对于验证安全策略和进行故障排除非常重要。

安装

我们可以通过 Krew 非常方便的安装它：

kubectl krew install rolesum

如何使用？

重新回到我们上面的用例，只要通过以下命令，它就能能够提供比标准 kubectl 命令更加详细和直观的权限视图。

➜ kubectl rolesum owner -n developer
ServiceAccount: developer/owner
Secrets:

Policies:
• [RB] developer/owner-binding ⟶  [R] developer/Owner
  Resource   Name  Exclude  Verbs  G L W C U P D DC
  endpoints  [*]     [-]     [-]   ✔ ✔ ✔ ✖ ✖ ✖ ✖ ✖
  pods       [*]     [-]     [-]   ✔ ✔ ✔ ✖ ✖ ✖ ✖ ✖
  secrets    [*]     [-]     [-]   ✔ ✔ ✔ ✖ ✖ ✖ ✖ ✖
  services   [*]     [-]     [-]   ✔ ✔ ✔ ✖ ✖ ✖ ✖ ✖

以下是部分字段的描述：

RB: RoleBinding
R: Role
CRB: ClusterRoleBinding
CR: ClusterRole
G: get
L: list
W: watch
C: create
U: udpate
P: patch
D: delete
DC: deletecollection

实际应用案例

下面是一个实际应用案例截图，我们可以清晰的看到这个服务被赋予了哪些权限。

图片

在实际开发过程中，如果发现有些资源创建不出来或者其他权限异常，我们通过该工具能够快速定位到原因。

同时它对于审计和合规性检查也是一个宝贵的工具，因为它可以迅速展示权限的当前状态。

局限性

kubectl-rolesum 的主要优势在于其能够提供比标准 kubectl 命令更加详细和直观的权限视图。这对于管理复杂的 RBAC 策略特别有用。

但也有其局限性，就是它提供不了创建或修改这些角色的能力。

rbac-tool

最后，我们将探讨 rbac-tool[3]，这是一个强大的多功能工具，它不仅简化了 RBAC 策略的查询，还帮助我们更容易地创建和管理这些策略。

安装

我们可以通过 Krew 非常方便的安装它：

kubectl krew install rbac-tool

如何使用？

例如，要生成特定命名空间或整个集群的 RBAC 权限图，可以使用以下命令：

kubectl rbac-tool viz --outformat dot \
  && cat rbac.dot | dot -Tpng > rbac.png  && open rbac.png

这个命令会创建一个 DOT 文件，该文件可以用图形化工具（如 Graphviz）打开，展示角色和角色绑定之间的关系图。

对于前面的例子，我们也可以使用如下命令用 chrome 打开，查看 owner 的情况。

➜ kubectl rbac-tool viz --include-subjects=owner && open -a "Google Chrome" rbac.html
[RAPID7-INSIGHTCLOUDSEC] Namespaces included '*'
[RAPID7-INSIGHTCLOUDSEC] Namespaces excluded 'kube-system'
[RAPID7-INSIGHTCLOUDSEC] Connecting to cluster ''
[RAPID7-INSIGHTCLOUDSEC] Generating Graph and Saving as 'rbac.html'

效果如下所示：

图片

kubectl rbac-tool lookup

提供查询主体的权限：

➜ kubectl rbac-tool lookup -e '^owner.*'
  SUBJECT | SUBJECT TYPE   | SCOPE | NAMESPACE | ROLE
+---------+----------------+-------+-----------+-------+
  owner   | ServiceAccount | Role  | developer | Owner

rbac-tool who-can

查看谁有执行特定操作的权限，类比 kubectl-who-can 的能力：

➜ kubectl rbac-tool who-can get pod
  TYPE           | SUBJECT                                | NAMESPACE
+----------------+----------------------------------------+------------------------------------------------+
  Group          | system:masters                         |
  ServiceAccount | cert-manager                           | cert-manager
  ServiceAccount | deployment-controller                  | kube-system
  ServiceAccount | endpoint-controller                    | kube-system
  ServiceAccount | endpointslice-controller               | kube-system
  ServiceAccount | ephemeral-volume-controller            | kube-system
  ServiceAccount | generic-garbage-collector              | kube-system
  ServiceAccount | local-path-provisioner-service-account | kube-system
  ServiceAccount | namespace-controller                   | kube-system
  ServiceAccount | node-controller                        | kube-system
  ServiceAccount | owner                                  | developer
  ServiceAccount | persistent-volume-binder               | kube-system
  ServiceAccount | pvc-protection-controller              | kube-system
  ServiceAccount | statefulset-controller                 | kube-system
  ServiceAccount | user-sa                                | user-zone-4ef1aab6-3c45-4d37-bdb1-0b0c629b3b26
  ServiceAccount | user-sa                                | user-zone-729281f1-46e8-4d63-8ab8-cfd895923bab
  ServiceAccount | xfs2-csi-driver-controller-sa          | xfs2-csi-driver
  User           | k3s-cloud-controller-manager           | kube-system
  User           | system:k3s-controller                  |
  User           | system:kube-scheduler                  |

rbac-tool policy-rules

展示详细的权限规则，类比 kubectl-rolesum 的能力，但在输出可视化上，个人觉得 kubectl-rolesum 要更加清晰一些：

➜ kubectl rbac-tool policy-rules -e '^owner'
  TYPE           | SUBJECT | VERBS | NAMESPACE | API GROUP | KIND      | NAMES | NONRESOURCEURI | ORIGINATED FROM
+----------------+---------+-------+-----------+-----------+-----------+-------+----------------+-------------------------+
  ServiceAccount | owner   | get   | developer | core      | endpoints |       |                | Roles>>developer/Owner
  ServiceAccount | owner   | get   | developer | core      | pods      |       |                | Roles>>developer/Owner
  ServiceAccount | owner   | get   | developer | core      | secrets   |       |                | Roles>>developer/Owner
  ServiceAccount | owner   | get   | developer | core      | services  |       |                | Roles>>developer/Owner
  ServiceAccount | owner   | list  | developer | core      | endpoints |       |                | Roles>>developer/Owner
  ServiceAccount | owner   | list  | developer | core      | pods      |       |                | Roles>>developer/Owner
  ServiceAccount | owner   | list  | developer | core      | secrets   |       |                | Roles>>developer/Owner
  ServiceAccount | owner   | list  | developer | core      | services  |       |                | Roles>>developer/Owner
  ServiceAccount | owner   | watch | developer | core      | endpoints |       |                | Roles>>developer/Owner
  ServiceAccount | owner   | watch | developer | core      | pods      |       |                | Roles>>developer/Owner
  ServiceAccount | owner   | watch | developer | core      | secrets   |       |                | Roles>>developer/Owner
  ServiceAccount | owner   | watch | developer | core      | services  |       |                | Roles>>developer/Owner

以前用过 rakkess[4]，它在对资源的访问矩阵表现的也挺友好。

图片

rbac-tool gen

生成自定义 RBAC 规则。类比 kubectl create role 和 kubectl create clusterrole，但是在灵活性和资源的指定上，在部分场景下会更加高效：

➜ kubectl rbac-tool gen \
  --generated-type=Role \
  --allowed-verbs=get,list,watch \
  --allowed-groups=, \
  --deny-resources=bindings.,persistentvolumeclaims.,limitranges.,events.,replicationcontrollers.,configmaps.,resourcequotas.,podtemplates.,serviceaccounts.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  creationTimestamp: null
  name: custom-role
  namespace: mynamespace
rules:
- apiGroups:
  - ""
  resources:
  - pods
  - secrets
  - endpoints
  - services
  verbs:
  - get
  - list
  - watch

相比较而言，rbac-tool 在 RBAC 管理方面还是非常强大的。

将学习付诸实践

在前面的章节中，我们详细探讨了 Kubernetes 中的 RBAC 工具和命令，了解了如何使用它们来做安全审计或者简化故障排除。但是，光有工具并不足以保障安全，正确和高效地应用这些工具同样重要。因此，接下来的部分，我将分享一些 “RBAC 最佳实践” 关键的策略和建议：

1. 最小权限原则

在定义角色时，应遵循最小权限原则。只授予执行特定任务所需的最少权限，以最大限度地减少未授权操作的风险。这是确保安全的关键步骤。

2. 定期审计

定期回顾和审计集群里的 RBAC 配置，确保它们与组织的安全策略保持一致。删除不必要或过度的权限，并根据需要更新角色。这有助于维持一个清晰、安全的权限结构。

3. 有效使用命名空间

利用命名空间逻辑地隔离不同的团队或项目，并在命名空间级别执行 RBAC 策略。这样可以更有效地管理权限，确保不同团队或项目之间的操作隔离。

4. 测试 RBAC 策略

在非生产环境中彻底测试我们的 RBAC 策略，确保它们按预期工作，然后再应用到生产集群中。这是防止潜在问题影响生产环境的重要一步。

Conclusion

经过对这些强大工具的探索，我们不仅加深了对 Kubernetes RBAC 管理的理解，还获得了加强集群安全的新视角。从 kubectl auth can-i 的基本权限检查到 kubectl-who-can 的深入分析，再到 kubectl-rolesum 和 rbac-tool 的全面视图，这些工具共同为我们构筑了一个更加透明、健壮的 Kubernetes 环境。

记住，Kubernetes 安全是一项持续的努力。借助这些工具和不断的学习，我们能够确保我们的集群既强大又安全。