kubectl相关的角色和角色绑定是什么？

Question

我试图了解kubectl是如何获得运行命令的权限的。我知道所有与库伯奈特星系团的相互作用都是通过库伯-阿皮瑟弗进行的。因此，当我们从主节点运行kubectl命令(例如kubectl get pods )时，请求将通过kube进行。

apiserver执行身份验证和授权，并提供结果。与任何其他用户或资源一样，kubectl也应该与一个角色和角色绑定相关联，以获得访问集群上资源的权限。如何检查与kubectl关联的角色和角色绑定？

抱歉，如果这是个荒谬的问题。

Answer 1

此答案是对其他问题的扩展，并帮助您在使用客户端证书时编写脚本。

从当前上下文中获取用户和组：

如果使用客户端证书，则~/.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运行kubernetes时，我的Mac上的输出：

Subject: O=system:masters, CN=docker-for-desktop

O是组织，以kubernetes表示组。

CN是常见的名称，被kubernetes解释为用户。

找到相应的集群角色和集群绑定：

现在，您知道了当前与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:
  - '*'

Answer 2

Kubectl不与角色或角色绑定相关联，Kubectl使用一个名为kubeconfig的文件。该文件具有客户端证书或JWT承载令牌。

如果API服务器提供并验证了客户端证书，则使用主题的公共名称作为请求的用户名。

如果使用JWT承载令牌，那么识别用户所需的所有数据都在令牌本身中。

这就是在kubernetes中对用户进行身份验证的方式。

用户的授权由基于角色的访问控制(RBAC)规则以角色和角色绑定的形式定义。

Answer 3

您可以使用kubectl config view查看哪个上下文现在是活动的。你会看到这样的情景：

contexts:
- context:
    cluster: my-cluster
    namespace: stage
    user: alice
  name: stage-ctx
current-context: stage-ctx

这意味着每个命令都进入my-cluster的my-cluster命名空间(如果没有在命令中指定名称空间)，并在那里作为用户alice进行身份验证。

下一件事发生在服务器端。可能有一个角色可以让某人获得并列出豆荚。我们叫它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/上阅读更多内容。