kubernetes/kops：默认用户和权限

Question

使用kubectl 和kops 1.8

当使用kops 在aws 中旋转集群时，创建的客户端证书（在~/.kube/config 的client-certificate-data 字段中显示为字符串）具有以下值：

    Subject: O=system:masters, CN=kubecfg

除非我错了，从kubernetes 1.4开始，Organitazion的值被解释为group信息（与CN值关联的字符串就是所谓的用户，因为k8s本身并没有有这样的概念）

1：如何查看与system:masters 组和/或kubecfg 用户关联的权限？

• （与上述有关）：我现在使用的开箱即用的授权方式是什么？ RBAC?我该如何检查？

2：为什么我的~/.kube/config 中的条目不包含kubecfg 用户？ （而是一个拥有我的集群名称的用户和另一个名为 admin 的用户？）

$ kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: REDACTED
    server: <server_url>
  name:  <my_cluster_name>
contexts:
- context:
    cluster:  <my_cluster_name>
    user:  <my_cluster_name>
  name:  <my_cluster_name>
current-context:  <my_cluster_name>
kind: Config
preferences: {}
users:
- name: <my_cluster_name>
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
    password: <some_pass>
    username: admin
- name: <my_cluster_name>.local-basic-auth
  user:
    password: <some_pass>
    username: admin

归根结底，在执行kubectl 命令时，我正在与哪个用户执行 api 调用？

更新：我试图在我的~/.kube/config 中弄乱client-certificate-data 的值，结果我得到了

错误：tls：私钥与公钥不匹配

我假设这意味着我正在使用基于 x509 的身份验证 (?)

所以我以 kubecfg 的身份进行 api 调用？

Answer 1

请注意，身份验证和授权之间有一个difference。

• 身份验证确保用户是他们所说的那样。调用 Kubernetes API 始终需要成功的身份验证。
• 授权确定用户是否有权访问特定的 Kubernetes API 资源（通过 RBAC）。 RBAC 必须作为kube-apiserver 服务器的配置选项显式启用。

Kubernetes 身份验证

• 在 Kubernetes 中，有许多 mechanisms 可用于对用户进行身份验证，例如令牌、密码、OIDC 连接令牌和 SSL x509 客户端证书。

• 正如您在上面所发现的，kops 将自动生成一个带有嵌入式 SSL x509 客户端证书的 ~/.kube/config 文件。 将客户端证书与对 kube-apiserver 的任何 REST 调用一起提供，允许 kube-apiserver 通过验证客户端证书已由集群证书颁发机构 (CA) 签署来验证调用者。如果客户端证书已正确签名，则调用者就是他们所说的。

• 客户端证书持有者的身份由 SSL x509 客户端证书的 Subject 字段确定。

  • 主题公用名确定用户身份。 （例如 CN=Bob）
  • 主题组织确定用户的组。 （例如 O=admins，O=system:masters）。请注意，可以指定多个组织（即组）。
• 请注意，kubeconfig 文件中的user 名称只是一个不透明的值用户，以方便使用 kubectl 工具。 user 的真实身份是嵌入在 SSL x509 客户端证书或任何其他令牌中的身份。
• 请注意，典型 Kubernetes 部署中每个组件（例如 kubelet、调度程序、etcd）的每个实例都有自己的 SSL x509 客户端证书，用于在与其他组件通信时进行身份验证。看到这个link

Kubernetes 授权

• 在 Kubernetes 中，RBAC roles and rolebindings 准确确定特定用户可以访问哪些 kube-apiserver REST 端点，以及允许哪些 verb 操作（例如“get”、“list”、“watch”、“create”、 “更新”、“补丁”、“删除”）。
• 可以创建一个role，这是一组定义对 kube-apiserver REST 端点的访问权限的权限。
• 然后可以创建一个rolebinding，它将用户 ID 或组 ID 绑定到特定的 role。
• 请注意，集群范围和命名空间范围的角色绑定都可用。
• 这是一个示例：

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: role-grantor
    rules:
    - apiGroups: ["rbac.authorization.k8s.io"]
      resources: ["rolebindings"]
      verbs: ["create"]
    - apiGroups: ["rbac.authorization.k8s.io"]
      resources: ["clusterroles"]
      verbs: ["bind"]
      resourceNames: ["admin","edit","view"]
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: role-grantor-binding
      namespace: user-1-namespace
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: role-grantor
    subjects:
    - apiGroup: rbac.authorization.k8s.io
      kind: User
      name: user-1

• RBAC 只是一种可能的授权机制。 Kubernetes ABAC 不太受欢迎。

检查您是否启用了 RBAC

只需验证 kube-apiserver 启动选项。如果 kube-apiserver 作为 pod 运行，您可以这样检查：

$ kubectl get po kube-apiserver-ubuntu-18 -n kube-system -o name |grep api
pod/kube-apiserver-ubuntu-18

$ kubectl get po kube-apiserver-ubuntu-18 -n kube-system  -o yaml
# THEN SEARCH FOR RBAC
spec:
  containers:
  - command:
    - kube-apiserver
    - --authorization-mode=Node,RBAC