kubectl auth can-i对应何种K8s API？调用SelfSubjectAccessReview为何需额外权限？

你完全说对了！kubectl auth can-i 底层依赖的就是 authorization.k8s.io/v1 组的 SelfSubjectAccessReview API。我来给你详细拆解它的工作逻辑，还有你碰到的权限问题到底是怎么回事。

1. 核心API：SelfSubjectAccessReview的作用 #

这个API专门用来让发起请求的主体（也就是你当前kubectl使用的认证账号/凭据）查询自己对某个K8s资源或操作是否具备权限。和通用的SubjectAccessReview不同，它不需要你指定要检查的用户/ServiceAccount——默认就是发起请求的"自己"，这也是它名字里"Self"的含义。

2. kubectl auth can-i的具体执行流程 #

当你敲下类似kubectl auth can-i delete deployments -n prod的命令时，kubectl会一步步完成这些操作：

• 首先，根据你输入的参数（操作类型、资源、命名空间等），自动构造一个SelfSubjectAccessReview的请求体。举个实际的请求体示例：

  apiVersion: authorization.k8s.io/v1
  kind: SelfSubjectAccessReview
  spec:
    resourceAttributes:
      group: apps
      resource: deployments
      verb: delete
      namespace: prod
  

• 然后，把这个请求发送到K8s API服务器的/apis/authorization.k8s.io/v1/selfsubjectaccessreviews端点。
• API服务器收到请求后，会调用集群配置的授权插件（比如最常用的RBAC，或者ABAC、Webhook授权）来执行权限检查逻辑。
• 最后，API服务器返回检查结果，kubectl把结果转换成简单的"yes"或"no"输出给你，有的时候还会附带额外的提示信息。

3. 为什么执行时需要额外权限？ #

你遇到的权限问题，本质是发起SelfSubjectAccessReview请求本身就需要对应的权限。具体来说，你的认证凭据需要拥有对authorization.k8s.io/selfsubjectaccessreviews这个资源的create权限。

通常集群默认会给普通用户和ServiceAccount开放这个权限，但如果你的集群做了非常严格的RBAC权限管控，可能就需要手动配置。比如你可以创建这样一个ClusterRole：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: self-access-review-allow
rules:
- apiGroups: ["authorization.k8s.io"]
  resources: ["selfsubjectaccessreviews"]
  verbs: ["create"]

再把这个ClusterRole绑定到你需要使用的用户或ServiceAccount上，就能解决权限不足的问题了。

内容的提问来源于stack exchange，提问作者Sergey Tsaplin