kubernetes/kops：默认用户和权限

Question

使用kubectl和kops 1.8

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

    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 调用？

更新：我试图搞乱的价值client-certificate-data在我~/.kube/config和我

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

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

所以我将 api 调用作为kubecfg?

Answer 1

请注意，身份验证和授权之间存在差异。

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

Kubernetes身份验证

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

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

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

  • 主题公用名决定了用户身份。（例如 CN=鲍勃）
  • 主题组织决定用户的组。（例如，O=管理员，O=系统：管理员）。请注意，可以指定多个组织（即组）。
• 请注意，userkubeconfig 文件中的 name 只是一个不透明的值 user，以方便 kubectl 工具使用。该人的真实身份user是嵌入在 SSL x509 客户端证书或任何其他令牌中的身份。
• 请注意，典型 Kubernetes 部署中每个组件（例如 kubelet、调度程序、etcd）的每个实例都有自己的 SSL x509 客户端证书，用于在与其他组件通信时进行身份验证。请参阅此链接

Kubernetes授权

• 在 Kubernetes 中，RBAC角色和角色绑定准确确定特定用户可以访问哪些 kube-apiserver REST 端点，以及verb允许哪些操作（例如“get”、“list”、“watch”、“create”、“update”、“patch”） “， “删除”）。
• 人们可以创建一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