K8S 权限管理

标签：权限管理用户 kubeconfig 集群 Role k8s ClusterRole K8S

k8s 权限管理

1、k8s 用户

1.1、k8s 用户概念

(1) k8s内部服务之间访问的账号 ServiceAccount（管理程序之间的访问）

(2)k8s外部用户访问集群的账号 User（管理操作人的访问）

k8s 不存储用户信息，用户的创建管理都无需与 K8S API 交互，但 K8S 接收 API请求时是需要知道发出请求的用户信息的。

所有对K8S的API请求都需要绑定身份信息(User或者ServiceAccount)

1.2、User&ServiceAccount 的区别

1、user 是人来使用而 ServiceAccount 是为某个资源、程序、服务使用的
2、k8s 用户的创建管理都无需与 K8S API 交互，K8S 所能认知的只有一个用户名，ServiceAccount 是有 K8S 管理创建
3、user 独立在 k8s 之外并且徐涛在全局唯一，而 ServiceAccount作为 k8s 内部的某种资源，是存在于某个命名空间之中的，在不同命名空间中的同名 ServiceAccount 被认为是不同的资源

1.3、k8s 用户创建

例如我们创建一个名叫 jim 的用户

1.3.1、创建用户私钥

openssl genrsa -out jim.key 2048

1.3.2、创建证书签名请求

使用此私钥创建一个 csr 文件（证书签名请求），在 subject 里带上用户信息（CN为用户名，o 为用户组）

openssl req -new -key jim.key -out jim.csr -subj "/CN=jim/O=MGM"

可能会出现如下异常

140587201880512:error:2406F079:random number 
generator:RAND_load_file:Cannot open file:../crypto/rand/randfile.c:88:Filename=/root/.rnd

执行以下命令解决异常

cd /root
openssl rand -writerand .rnd

1.3.3、集群证书签署

使用 kubernetes 集群 CA 证书签署用户的证书

openssl x509 -req -in jim.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out jim.crt -days 365

-CA 和-CAkey 参数为集群 CA 证书所在的位置
-days 参数指定此证书的过期时间，这里为 365 天

k8s 安装完成后证书秘钥相关的资源都保存在/etc/kuberenetes/pki文件下

这样就完成了用户的创建，注意保存证书（jim.crt）和私钥（jim.key）后面要用

可见创建一个用户是完全独立于 k8s 集群的，没有使用任何的 k8s api。

2、k8s角色

k8s 是基于 RBAC（Role-Based Access Control）角色实现访问控制

官方资料：https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/rbac/

主要涉及 4 个 Kind：

Role
ClusterRole
RoleBinding
ClusterRoleBinding

2.1、Role&ClusterRole

Role 或ClusterRole 中包含一组代表相关权限的规则

Role 是用来在某个名字空间内设置访问权限，所以创建 Role 是必须指定该 Role 所属的名字空间。
ClusterRole 则是一个集群作用域的资源。

这两种资源的名字不同（Role 和 ClusterRole）是因为 kubernetes 对象要么是名字空间作用域的，要么是集群作用域的，不可两者兼具

说白了 Role 只能访问所属名字空间的资源，ClusterRole 可以访问所有名字空间的资源

比如，你可以使用 ClusterRole 来允许某特定用户执行 
kubectl get pods --all-namespaces
kubectl get pods -n 【指定命名空间】

2.1.1、Role

role的配置yaml 文件如下

apiVersion: rbac.authorization.k8s.io/v1
# 指定类型为Role
kind: Role
metadata:
  namespace: team2
  name: team2-role
rules:
- apiGroups: ["","apps"] # "" 标明 core API 组  如果要访问deployment 需要加入"apps"
  #resources指定此角色可以访问操作那些资源   *代表所有 这里配置只能操作pods
  resources: ["pods"] 
  #verbs指资源的具体操作的类型例如 create get delete list update edit watch exec  *代表所有
  verbs: ["get", "watch", "list"]

apiGroups 配置项说明

apiGroups:[“”] 可以操作Pod service configmap 等大部分资源
apiGroups:[“apps”] 可以操作deployment
apiGroups:[“batch”] 可以操作 Job 资源
apiGroups:[“autoscaling”] 可以操作 horizontalpodautoscalers

注意创建 Role 前，确保已存在对应的 namespace

kubectl create namespace team2

kubectl apply -f team2-role.yaml创建角色

这样就完成了角色创建

2.1.2、ClusterRole

ClusterRole的配置yaml文件如下

apiVersion: rbac.authorization.k8s.io/v1
# 指定类型为ClusterRole
kind: ClusterRole
metadata:
  # "namespace" 被忽略，因为 ClusterRoles 不受名字空间限制
  name: manger-cluster-role
rules:
- apiGroups: ["","apps"] "" 标明 core API 组
  #resources指定此角色可以访问操作那些资源   *代表所有 这里配置只能操作secrets
  resources: ["secrets"]
  #verbs指资源的具体操作的类型例如 create get delete list update edit watch exec  *代表所有
  verbs: ["get", "watch", "list"]

这样就完成了 ClusterRole 的创建

2.2、Rolebinding&ClusterRoleBinding

角色绑定（Rolebinding&ClusterRoleBinding）是将角色中定义的权限富裕一个或者一组用户。

RoleBinding 在指定的名字空间中执行授权，而 ClusterRoleBinding 在集群范围执行授权。

Rolebinding 可以引用同一个名字空间中的任何 Role 也可以引用某 ClusterRole 并将该 ClusterRole 绑定到 Rolebinding 所在的名字空间。（RoleBinding可以绑定 Role 和 ClusterRole）

如果希望将某 ClusterRole 绑定到集群中所以名字的空间，你要使用ClusterRoleBinding

2.2.1、Rolebinding

Rolebinding 的配置 yaml 文件如下

apiVersion: rbac.authorization.k8s.io/v1
# 此角色绑定允许 "jim" 操作 "team2" 名字空间中的所有资源
# 需要在该命名空间中有一个名为 “team2-role” 的 Role
kind: RoleBinding
metadata:
  name: team2-role-binding
  namespace: team2
subjects:
# 你可以指定不止一个“subject（主体）”
- kind: User
  name: jim # "name" 是区分大小写的
  apiGroup: ""
roleRef:
  # "roleRef" 指定与某 Role 或 ClusterRole 的绑定关系
  kind: Role        # 此字段必须是 Role 或 ClusterRole
  name: team2-role  # 此字段必须与你要绑定的 Role 或 ClusterRole 的名称匹配
  apiGroup: ""

这样就完成了用户与角色的绑定

到此 k8s 中已经存在了一个 jim 用户可以访问资源了，接下来就是去配置 kubeconfig

2.2.2、ClusterRolebinding

可以使用 ClusterRolebinding 在集群级别和所有命名空间中授予权限。下面示例中所定义的 ClusterRolebinding 允许在用户组“manager”中的任何用户都可以读取集群中任何命名空间中的 secret。

# 以下`ClusterRoleBinding`对象允许在用户组"manager"中的任何用户都可以读取集群中任何命名空间中的secret。
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

3、kubeconfig 概念

kubeconfig 是一个配置文件，用于配置 kubectl 命令能够访问的 k8s 集群，是谁在访问集群，以及当前访问的上下文

可以简单把kubectl命令看做是一个浏览器,要访问一个网站（k8s集群）必须知道网站的IP地址，登录此网站的用户信息，以及保存当前登录的一些session cookie

kubeconfig 中主要由如下部分组成：

clusters（集群）
users（用户）
context（上下文）

使用 kubectl config view 命令可以看到

kubectl config view

k8s master 初始化完成后，也会提醒把创建好的 admin.conf放置到$HOME/kube 下，才能正常使用 kubectl 命令

3.1、clusters（集群）

kubeconfig 配置文件中一个重要的配置项就是 clusters

如果把kubectl看做是浏览器，那么clusters配置更像是浏览器本地DNS缓存。
浏览器根据DNS获取网站的IP，clusters告诉kubectl可以访问的远端k8s集群的ip，以及访问时需要携带的证书

3.2、users（用户）

kubeconfig 配置文件另一个重要的配置项就是 users，users 提供的就是登录远程 k8s 集群时使用的账号密码

这里的账号必须是所登录的 k8s 集群中存在的用户，同时密码就是所登录的 k8s 集群中的根证书颁发的证书（后面的创建用户会详细说明）

3.3、context（上下文）

context 保存的是 users 和 cluster 的对应关系，选择了上下文即选择了以某个用户去访问某个集群

4、kubeconfig 配置和使用

kubectl config -h 查看 config 的帮助文档

可以使用-kubeconfig 来实现操作那个 kubeconfig 配置文件

例如在指定的配置文件/ops/k8s/config/myconfig 中创建一个集群 
kubectl config set-cluster development --server=https://192.168.0.110 --kubeconfig=/ops/k8s/config/myconfig

可以使用set 命令来修改或新建单独的一个配置属性

例如把刚才创建的集群中server的配置修改一下ip地址
kubectl config set clusters.development.server http://5.6.7.8 --kubeconfig=/ops/k8s/config/myconfig

其他说明：

set-context 指定当前上下文
current-context 查看当前的上下文
get-contexts 查看指定上下文信息
use-context 使用上下文
rename-context 重命名上下文
delete-context 删除指定上下文
delete-cluster 删除集群
set-cluster 创建集群
get-clusters 查询集群
set-credentials 配置用户信息
view 查看kubeconfig 配置文件内容

标签：权限,管理,用户,kubeconfig,集群,Role,k8s,ClusterRole,K8S
From： https://www.cnblogs.com/yhtweirdo/p/17792434.html

K8S 权限管理