5

使用kubectl和kops 1.8

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

    Subject: O=system:masters, CN=kubecfg

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

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

  • （与上述有关）：我现在使用的开箱即用的授权方式是什么？RBAC? 我怎样才能检查这个？

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

$ 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？

4

1 回答 1

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=admins，O=system:masters）。请注意，可以指定多个组织（即组）。
  • 请注意，user为了方便 kubectl 工具，kubeconfig 文件中的 name 只是一个不透明的值用户。的真实身份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
于 2019-01-10T05:13:56.963 回答