kubernetes/kops:默认用户和权限

Question

使用kubectl和kops1.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

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

• 身份验证可确保用户是他们所说的用户。 对 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=Bob)
  • 主题组织确定用户的组。(例如 O=admins，O=system：masters)。 请注意，可以指定多个组织(即组)。
• 请注意，为了方便 kubectl 工具，kubeconfig 文件中user名称只是一个不透明的值用户。user的真实标识是嵌入在 SSL x509 客户端证书或任何其他令牌中的标识。
• 请注意，典型 Kubernetes 部署中每个组件(例如 kubelet、调度程序等)的每个实例都有自己的 SSL x509 客户端证书，它在与其他组件通信时使用该证书进行身份验证。 查看此链接

Kubernetes授权

• 在 Kubernetes 中，RBAC 角色和角色绑定准确地决定了特定用户可以访问哪些 kube-apiserver REST 端点，以及允许哪些verb操作(例如"get"、"list"、"watch"、"create"、"update"、"patch"、"delete")。
• 可以创建一个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