我试图了解 kubectl 如何获得运行命令的权限。
我了解与 kubernetes 集群的所有交互都通过 kube-apiserver。因此，当我们从主节点运行 kubectl 命令时，例如 kubectl get pods，请求将通过 kube-apiserver 进行。
apiserver 进行身份验证和授权并返回结果。 像任何其他用户或资源一样，kubectl 也应该与角色和角色绑定相关联，以获取访问集群上资源的权限。如何检查 kubectl 关联到哪个角色和角色绑定？
抱歉，如果这是一个荒谬的问题。
【问题讨论】：
标签： kubernetes kubectl
此答案是对其他答案的扩展，可帮助您在使用客户端证书时使用脚本：
如果您使用客户端证书，您的~/.kube/config 文件包含当前上下文用户的client-certificate-data。该数据是一个base64 编码的证书，可以用openssel 以文本形式显示。您的问题的有趣信息在Subject 部分。
此脚本将打印客户端证书的Subject 行：
$ kubectl config view --raw -o json \
| jq ".users[] | select(.name==\"$(kubectl config current-context)\")" \
| jq -r '.user["client-certificate-data"]' \
| base64 -d | openssl x509 -text | grep "Subject:"
通过 Docker for Mac 运行 kubernetes 时在我的 Mac 上的输出：
Subject: O=system:masters, CN=docker-for-desktop
O 是组织，代表 kubernetes 中的一个组。
CN 是通用名，被 kubernetes 解释为 user。
现在您知道您正在使用 kubectl 的用户和组。 要找出您正在使用哪个（集群）角色绑定，您必须查找已识别的组/用户：
$ group="system:masters"
$ kubectl get clusterrolebindings -o json \
| jq ".items[] | select(.subjects[].name==\"$group\")"
{
"apiVersion": "rbac.authorization.k8s.io/v1",
"kind": "ClusterRoleBinding",
"metadata": {
"annotations": {
"rbac.authorization.kubernetes.io/autoupdate": "true"
},
"creationTimestamp": "2020-03-31T14:12:13Z",
"labels": {
"kubernetes.io/bootstrapping": "rbac-defaults"
},
"name": "cluster-admin",
"resourceVersion": "95",
"selfLink": "/apis/rbac.authorization.k8s.io/v1/clusterrolebindings/cluster-admin",
"uid": "878fa48b-cf30-42e0-8e3c-0f27834dfeed"
},
"roleRef": {
"apiGroup": "rbac.authorization.k8s.io",
"kind": "ClusterRole",
"name": "cluster-admin"
},
"subjects": [
{
"apiGroup": "rbac.authorization.k8s.io",
"kind": "Group",
"name": "system:masters"
}
]
}
您可以在输出中看到该组与ClusterRole cluster-admin 相关联。您可以仔细查看此集群角色以详细了解权限：
$ kubectl get clusterrole cluster-admin -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
annotations:
rbac.authorization.kubernetes.io/autoupdate: "true"
creationTimestamp: "2020-03-31T14:12:12Z"
labels:
kubernetes.io/bootstrapping: rbac-defaults
name: cluster-admin
resourceVersion: "42"
selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/cluster-admin
uid: 9201f311-4d07-46c3-af36-2bca9ede098f
rules:
- apiGroups:
- '*'
resources:
- '*'
verbs:
- '*'
- nonResourceURLs:
- '*'
verbs:
- '*'
【讨论】：
Kubectl 与角色或角色绑定无关。Kubectl 使用名为 kubeconfig 的文件。该文件具有客户端证书或 JWT 不记名令牌。
如果客户端证书由 API 服务器提供并验证，则主题的通用名称将用作请求的用户名。
如果使用 JWT 不记名令牌，则识别用户所需的所有数据都在令牌本身中。
这就是在 Kubernetes 中对用户进行身份验证的方式。
用户的授权由基于角色的访问控制（RBAC）规则以角色和角色绑定的形式定义。
【讨论】：
您可以使用kubectl config view 查看当前处于活动状态的上下文。你会看到这样的：
contexts:
- context:
cluster: my-cluster
namespace: stage
user: alice
name: stage-ctx
current-context: stage-ctx
这意味着每个命令都转到my-cluster 的stage 命名空间（如果命令中没有指定命名空间），并在那里被验证为用户alice。
接下来的事情发生在服务器端。可能有一个角色允许某人获取和列出 pod。我们就叫它edit-stage-role：
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: stage
name: edit-stage-role
rules:
- apiGroups: ["", "extensions", "apps"]
resources: ["pods"]
verbs: ["get", "list"]
还有一个绑定，基本上将此角色分配给特定主题，如组或用户：
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: edit-stage-rb
namespace: stage
roleRef:
kind: Role
name: edit-stage-role
apiGroup: rbac.authorization.k8s.io
subjects:
- kind: User
name: alice
apiGroup: rbac.authorization.k8s.io
- kind: User
name: bob
apiGroup: rbac.authorization.k8s.io
在本例中，它将角色绑定到bob 和alice。在请求通过身份验证并且 k8s 知道您是用户 alice 后，它会尝试通过评估您的权限来授权请求，这些权限存储在绑定到 alice 的角色之一中。
从高层看是这样的。可能有多个角色，或ClusterRoles、ClusterRB 和其他选项，但总体概念看起来相同。
作为管理员，您可以模拟特定命名空间中的特定用户，以查看一组角色和绑定是否按预期工作。使用这个命令：
$ kubectl auth can-i get pods --namespace=stage --as alice
yes
但从最终用户的角度来看，集群中可能只有一个冒充您的用户。所有其他内容仅对管理员可见（或者如果您有权限）
这只是一个简短的解释。你可以在https://kubernetes.io/docs/reference/access-authn-authz/rbac/阅读更多内容
【讨论】：