Kubernetes – Role、User、Authentication 篇

用户登录有两种方式：

• 使用 kubeconfig 文件登录方式

  • 注意：kubeconfig 指的是认证文件，这个名称可以修改

  • 例如：/etc/kubernetes/admin.conf 就是 kubeconfig 文件

• 使用用户名和密码 –token 登录方式(已废弃)

默认读取的 kuebeconfig 文件在 ~/.kube/config 文件

• 使用 kubeconfig 文件来组织有关集群、用户、命名空间和身份认证机制的信息。

• kubectl 命令行工具使用 kubeconfig 文件来查找选择集群所需的信息，并与集群的 API 服务器进行通信。

kubeconfig 文件格式：

kubeconfig 文件的使用

1. 将 生成好的 kubeconfig 文件拷贝到其他机器上，需要安装 kubectl 来使用

2. 默认情况下，kubectl 在 $HOME/.kube 目录下查找名为 config 的文件

3. 第一种方式可以命令选项指定 kubeconfig 文件： kubectl --kubeconfig=/path/to/kubeconfig get nodes

4. 第二种方式可以通过环境变量的方式指定 kubeconfig 文件： export KUBECONFIG=/path/to/kubeconfig, 之后可以直接使用 kubectl 。

要创建 kubeconfig 文件需要一个私钥，以及集群 CA 授权颁发的证书。

我们不能直接使用私钥生成公钥，而必须用私钥生成证书请求文件 csr，然后根据证书请求文件向 CA (权威机构)申请证书，CA 审核之后会颁发证书。

1. 创建私钥，假如名称为 john.key

   • openssl genrsa -out john.key 2048

2. 利用刚生成的 john.key 生成证书请求文件 john.csr

   • openssl req -new -key john.key -out john.csr -subj "/CN=john/O=cka2020"

   • 注意：CN 的值 john ，就是我们后面要授权的用户

3. 对证书请求文件 john.csr 进行 base64 编码

   • cat john.csr | base64 | tr -d "\n"

4. 编写申请证书请求文件的 yaml 文件，并且创建 csr

   • 创建证书签名请求对象发送到 Kubernetes API

   • 注意：name 为 john 用户，request 就是第三步中 base64 编码的结果，

   • 注意：因为 apiversion 是 v1beta1 版本，因此不需要加 signerName

   • 创建 csr 后，可以看到，csr 的状态是 pending，还没有经过 apiserver审批

5. 通过 kubernetes 的 master，apiserver 通过 john 的 csr 请求

   • kubectl certificate approve john

   • 注意：一旦 k8s 通过 csr 的审批，目前还有一种撤销审批的方式

6. 查看通过审批的john的证书, 并导出

   • 查看证书：kubectl get csr john -o jsonpath={.status.certificate}

   • 将 上述 输出 经过 base64 解码后，重定向到文件：kubectl get csr john -o jsonpath={.status.certificate} | base64 -d > john.crt

   • john.crt 就是最后想要的 用户证书

7. 给当前 john 用户 配置权限

   • 权限管理，下一节说明

   • 当前知识配置一个 admin 权限用作测试，命令：kubectl create clusterrolebinding test --clusterrole=cluster-admin --user=john

   • 注意：clusterrolebinding 就是将一个用户绑定至一个 role

   • 注意：当前用户就是 –user 所指出的用户

   • 注意：绑定到的 role 就是 –clusterrole 所指定的 role

1. kubeconfig 模板文件，可以通过 kubectl config view 来生成，进行修改

   • clusters 字段，表示集群的信息

   • users 字段，表示指定用户

   • contexts 字段，表示指定上下文，包括用户默认所在的命名空间等信息

2. 拷贝 CA 证书

   • 目录在 /etc/kubernetes/pki/ca.crt, 拷贝到当前 john 目录下

3. 设置集群字段

   • kubectl config --kubeconfig=./mykubeconfig set-cluster cluster1 --server=https://10.113.71.253:6443 --certificate-authority=ca.crt --embed-certs=true

   • --embed-certs=true 表示是否将证书内容写入到 kubeconfig 文件中

   • --server= 表示 apiserver 的地址

   • --certificate-authority 表示 ca 证书的位置

   • set-cluster 表示设置一个 cluster 集群的信息

4. 设置用户字段

   • kubectl config --kubeconfig=./mykubeconfig set-credentials john --client-certificate=./john.crt --client-key=./john.key --embed-certs=true

   • set-credentials 字段，表示设置用户

   • --client-certificate 字段，表示 john 用户的证书

   • --client-key 字段，表示 john 用户的私钥

5. 设置上下文信息

   • kubectl config --kubeconfig=./mykubeconfig set-context context1 --cluster=cluster1 --namespace=gsh --user=john

   • set-context 字段，表示设置 上下文 字段

   • --cluster 字段，表示该上下文对应的是哪个集群

   • --namespace 字段，表示该上下文 对应的是哪个 命名空间

   • --user 字段，表示该上下文 对应的是哪个用户

6. 设置当前上下文，也就是 current-context 字段，设置为 context1，最终的 kubeconfig文件为：

7. 至此，kubeconfig 文件就设置好了， 可以拷贝到其他机器上来通过 kubectl 来访问集群。

1. 将 设置好的 kubeconfig 文件拷贝到其他机器上

2. 安装 kubectl

3. 两种方式验证：

   • 通过kubectl命令选项方式指定 kubeconfig文件 kubectl get nodes --kubeconfig=/root/kubeconfig/mykubeconfig

   • 通过环境变量的形式：export KUBECONFIG=/root/kubeconfig/mykubeconfig

在 /etc/kubernetes/manifests/kube-apiserver.yaml 中有 --authorization-mode= 选项，用来设置授权模式，有以下几种授权模式:

• --authorization-mode=AlwaysAllow : 允许所有请求

• --authorization-mode=AlwaysDeny : 拒绝所有请求

• --authorization-mode=ABAC : Attribute-Based Access Control,

  • 基于属性的访问控制（ABAC）模式允许您使用本地文件配置策略。

  • 不够灵活放弃

• --authorization-mode=RBAC : Role Based Access Control

  • 基于角色的访问控制（RBAC）模式允许您使用 Kubernetes API 创建和存储策略。

• --authorization-mode=Node :专门授权由 kubelet 发出的 API 请求。

  • Node 授权器主要用于各个node上的 kubelet 访问 apiserver 时使用的，其他一般均由 RBAC 授权器来授权

在 RBAC API 中，一个角色包含一组相关权限的规则。权限是纯粹累加的（不存在拒绝某操作的规则）。 角色可以用 Role 来定义到某个命名空间上， 或者用 ClusterRole 来定义到整个集群作用域。

也就是说：

• kubernetes 的权限不是直接绑定在用户上的

• 某些权限先赋予 Role 和 ClusterRole

• 然后 Role 和 ClusterRole 在通过 RoleBinding 和 ClusterRoleBinding 绑定在用户上

一个 Role 只可以用来对某一命名空间中的资源赋予访问权限。

例如：john 用户实在 ns1 命名空间中创建的角色，并且有 get、create、delete 等权限，但是 john 用户只能在该 ns1 中进行这些操作，如果在 ns2 中则没有任何权限。

下面的 Role 示例定义到名称为 “gsh” 的命名空间，可以用来授予对该命名空间中的 Pods 的读取权限：

说明：

• metadata 中的 namespace 指定该 role 创建在哪个命名空间下，也就指明了只能对 该命名空间 中资源的限制

• resources : 表示对该命名空间下的哪些资源进行限制

• verbs : 表示权限的具体行为

• apiGroups : 不同的资源都有不同的 apiVersion

  • 例如：app/v1 ，其中 app 表示 apiGroup，v1表示 version

  • 如果 apiGroups 为空，那么只能匹配 v1 的资源

  • 注意：apiGroups 设置了以后，apiGroups 可能包括很多资源，这就需要在 resources 中定义具体的 资源了。

• role 也可以通过命令行创建：kubectl create role -h

RoleBinding 简介：

• 角色绑定（RoleBinding）是将 Role 中定义的权限赋予一个或者一组用户。

• RoleBinding 包含若干主体（用户，组和服务账户）的列表和对这些主体所获得的角色的引用。

• 可以使用 RoleBinding 在指定的命名空间中执行授权， 或者在集群范围的命名空间使用 ClusterRoleBinding 来执行授权。

一个 RoleBinding 可以引用同一的命名空间中的 Role 。

下面的例子 RoleBinding 将 “pod-reader” 角色授予在 “default” 命名空间中的用户 “john”； 这样，用户 “john” 就具有了读取 “default” 命名空间中 pods 的权限。

注意：

• RoleBinding目的就是将 subjects 中的类型 与 roleRef 中定义的 角色绑定在一起

• subjects : 表示 role 需要绑定在什么对象上，其中 kind 有三种类型：

  • User

  • Group

  • ServiceAccount

• roleRef : 表示实际创建绑定到哪个 role。

  • kind 可以是 Role 或 ClusterRole

  • name 将引用你要指定的 Role 或 ClusterRole 的名称。

  • 该例子中，就是将 pod-reader 的role绑定在 john 用户上。

• RoleBinding 也可以引用 ClusterRole。对 ClusterRole 所定义的、位于 RoleBinding 命名空间内的资源授权

• RoleBinding 也可以通过命令行创建：kubectl create rolebinding -h

示例：

• 因为已经在 10.113.71.132 机器上 添加了kubeconfig 文件，而之前手动创建 kubeconfig文件时，是将 john 用户于 cluster-admin 绑定的，因此具有所有权限，现在删掉之前的 clusterrolebinding，新建 role 和 john 绑定

ClusterRole 可以授予的权限和 Role 相同， 但是因为 ClusterRole 属于集群范围。

也就是说，ClusterRole 是在整个集群范围内的，而 Role 则是限制在某个 命名空间下。

可以赋予的权限有：

• 集群范围资源 （比如 nodes）

• 非资源端点（比如 “/healthz”）

• 跨命名空间访问的有名字空间作用域的资源

  • 如 Pods，比如运行命令kubectl get pods –all-namespaces 时需要此能力

下面的 ClusterRole 示例可用来对某特定命名空间下的 Secrets 的读取操作授权， 或者跨所有命名空间执行授权（取决于它是如何绑定的）:

ClusterRoleBinding 和 RoleBinding 的用法一致

ClusterRoleBinding 可用来在集群级别或对所有命名空间执行授权。

下面的例子允许 “manager” 组中的任何用户读取任意命名空间中 “secrets”。

注意：

• 不能修改绑定对象所引用的 Role 或 ClusterRole 。

• 试图改变绑定对象的 roleRef 将导致验证错误。

• 想要 改变现有绑定对象中 roleRef 字段的内容，必须删除并 重新创建绑定对象。

kubernetes 中有两种用户：

• user account : 是 kubectl 用来远程登录使用的

• service account : 表示 某个 pod 以哪个 ServiceAccount 运行，可以给 ServiceAccount 一定的权限，那么这个 pod 中的进程就对 kubernetes 集群有相关的权限。

注意：

• 用户账户是针对人而言的。 服务账户是针对运行在 pod 中的进程而言的。

• 每创建一个 ServiceAccount，都会自动创建一个 secret 与之对应

• 创建一个 ServiceAccount，是没有任何权限的，与 用户 user 对应，必须将 ServiceAccount 和 一个 有一些权限的 role 或 clusterrole 绑定。

创建 sa 的方法有两种：

• 命令行方式：kubectl create sa 名称

• yaml 文件形式，模板为：

将 sa 与 role 绑定

• 命令行方式：kubectl create clusterrolebinding 名称 --clusterrole=pod-reader --serviceaccount=命名空间:sa名称

• yaml 文件格式创建，模板为：

将某个 pod 设置 sa

• 命令行方式设置：kubectl set serviceaccount deployment 控制器名称 sa名称。注意：只能对控制器设置，不能对 pod 设置

• yaml 文件形式，模板为:

  • 在 1.6 以上版本中，你可以通过在服务账户上设置 automountServiceAccountToken: false 来实现不给服务账号自动挂载 API 凭据：

• 绑定了 sa 的 pod 就有了 对集群管理的一些权限