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 配置文件内容