深入理解K8S【安全认证机制&kubectlconfig】

深入理解K8S【安全认证机制】

1 核心概念

1.1 安全体系

对于大型系统来说，对业务的权限、网络的安全认证是必不可少的。

对于linux系统来说，用户和组、文件权限、SELinux、防火墙、pam、sudo等，究其核心的目的都是为了保证系统是安全的。

那么kubernetes的这种大型的任务编排系统来说，同样也陆续产生了一系列对平台的权限认证、对业务的权限认证、对网络的安全认证等认证体系

K8s官网：https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/

K8S权限及认证（3A）：

Authentication认证：校验用户身份，若不成功返401。多个认证插件进行或逻辑。只要有一个插件校验通过就放行，进入下一关。【是不是我们的人】

Authorization授权：什么样的用户有什么权限。不同用户获取不同的资源操作权限，比如普通用户、超级用户等。权限不足返回403<鉴权过程遵循"或"逻辑，且任何一个插件对操作的许可授权后都将不再进行后续插件验证，如果都未许可则拒绝。【是什么角色，给你什么权限】

Admission准入控制：用户认证、授权之后，当进行一些写操作的时候，需要遵循的一些限制的要求,比如资源限制内容合规性检查，遵循"与"逻辑，且无论成败，每次操作都要经由所有插件检验,最后统一返回结果
只对写操作进行合规性检查，在授权范围内，对用户的某些命令或者操作进行进一步的限制【操作造成的结果是否在合规范围内，需要所有插件检验通过】
分为两类:

validaing 校验(合规性,资源默认和最大和最小限制)

mutating 变更(补全,默认值填充)

K8s安全校验流程解析：

UA（普通人类账户）、SA（集群内部账户，内嵌账户）发起请求

认证、授权插件遵循短路与，如：多个认证插件，有一个成功就放行，让请求到达授权插件链；准入控制插件不遵循短路与，需要准入控制插件链上的插件都检测通过才允许请求往下走。

校验通过，访问k8s对应资源。

①上图左侧的用户：

kubernetes主要有两种用户：
- User Account:普通人类用户(交互模式)
- Service Account:集群内部的pod用户(服务进程)

②中间：每个部分都是以插件的方式来整合到 kubernetes 集群环境中：

认证和授权是按照插件的顺序依次进行检测，并且遵循 "短路模型" 的认证方式所谓的"短路"即，失败的时候，到此结束,后续的规则不会进行。

准入控制由于仅用户写操作场景，所以它不遵循 "短路模型"，而是会全部检测通过才允许执行原因在于，它要记录为什么不执行，原因是什么，方便后续审计等动作。

③右侧部分：k8s资源

1.2 认证机制

1.2.1 k8s中的用户

UserAccount：非pod类的客户端来访问API Server，一般是我们现实中的"人"。常见的管理方式：openssl等。（K8s将这部分外包出去，由外部的第三方服务进行管理）【真实的人操作的账户、k8s外包出去、openssl】

ServiceAccount（SA）：k8s内部自带的、与pod关联的账号类型。主要用于集群pod内的进程访问API Server。该账号认证到API Server的信息称为Service Account Token，它们保存于同名的Secret对象中。【k8s内嵌、pod操作的账户】

匿名用户

1.2.2 用户组（类比windows用户组）

为了方便k8s对某一类用户账号UA进行管理，一般会通过用户组方式进行管理。

k8s本身并没有用户组的概念。用户组是在身份提供者（如：OpenID Connect、Active Directory、kubectlconfig文件中定义的）。

在k8s中，用户、用户组主要在Authentication认证、Authorization授权环节中发挥作用。

①查看集群中的用户和组（CN和OU）：openssl x509 -in xx-apiserver.crt -text -noout

例如：查看用户组system：master权限

所有的k8s集群资源操作，其实都是通过node节点上的kubelet和master节点上的apiserver之间的通信实现，而在kubernetes的认证目录中有其专用的通信认证证书 apiserver-kubelet-client.crt，可以通过该文件来检查一下这两者之间是一个怎样的关系。

bash 复制代码

# 以rancher搭建的k8s为例
# 查看集群中的用户关系
openssl x509 -in /var/lib/rancher/rke2/server/tls/client-kube-apiserver.crt -text -noout

结果：

bash 复制代码

Certificate:
...
Issuer: CN = kubernetes
Validity
Not Before: Oct 3 03:06:43 2021 GMT
Not After : Oct 3 03:06:43 2022 GMT
Subject: O=system:masters, CN=kube-apiserver-kubelet-client
...

结果显示：对于kubelet，用户名是kube-apiserver-kubelet-client，而且属于system:master的组，这两者的关系是在基于openssl或者csffl工具创建用户时候基于CN和O来设定的信息。

②查看集群角色权限:kubectl get clusterrole cluster-admin -o yaml

bash 复制代码

# 查看k8s cluster-admin的用户权限
kubectl get clusterrole cluster-admin -o yaml

③查看集群和用户角色绑定关系：kubectl get clusterrolebinding cluster-admin -o yaml

bash 复制代码

# 查看cluster-admin这个绑定配置，做了什么配置
kubectl get clusterrolebinding cluster-admin -o yaml

...
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole # 被绑定人拥有cluster-admin用户的权限
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  # 将system:masters里的所有人都应用该绑定关系
  name: system:masters

1.2.3 认证插件

API Server启用的身份认证机制：

基于认证插件支持多种认证方式，而相应认证插件的启用需要经由kube-apiserver上的专用选项完成
kubeadm 部署的集群默认启用的认证机制包括如下几种：
- X509客户端证书认证
- Bootstrap令牌认证
- 前端代理身份认证 front-proxy
- Service Account 令牌

注意：API Server并不保证各认证插件的生效次序与定义的次序相同（认证插件遵循或关系，有一个认证通过就放行，不再进行其他认证插件的校验。直接进入下一步授权）

bash 复制代码

# 在master节点查看认证机制
cat /etc/kubernetes/manifests/kube-apiserver.yaml

①X509客户端证书认证（TSL双向认证）：k8s ca.crt签发证书

TLS双向认证，客户端持有数字证书,API Server信任客户端证书的颁发者.即服务器客户端互相验证信任的CA需要在kube-apiserver启动时,通过--client-ca-file选项指定.证书中的Subject中的 CN(CommonName)即被识别为用户名，而O（Organization）被识别为组名对于这种客户的账号，k8s是无法管理的。为了使用这个方案，api-server需要用--client-ca-file、--tls-private-key-file、--tls-cert-file选项来开启。kubeadm部署的Kubernetes集群，默认使用 /etc/kubernetes/pki/ca.crt 进行客户端认证,此文件是kubeadm为Kubernetes各组件间颁发数字证书的CA

由k8s的ca.crt签发证书，校验证书合法性（是否是我签发的），校验权限（是否是某个cn用户，是否是某个o组）

②Token令牌认证：节点数量很多，直接通过token进行通信

在节点数量非常多的时候，大量手动配置TLS认证比较麻烦，可以通过在api-server开启 experimental-bootstrap-token-auth 特性，通过对客户端的和k8s平台预先定义的token信息进行匹配，认证通过后，自动为节点颁发证书，可以大大减轻工作量，而且应用场景非常广。

包括: Service Account 令牌,静态令牌文件,Bootstrap令牌,OIDC(OpenID Connect)令牌,Webhook 令牌等

节点数量多，手动配置tls证书麻烦。直接通过token方式通信。（token中存储了用户的信息）

③代理认证

一般借助于中间代理的方式来进行统用的认证方式，样式不固定

④匿名方式

无法认证的其它请求（无认证）

2 实战

2.1 User Account管理

2.1.1 X509客户端认证(k8s集群维护了三套CA证书系统)

官网地址：https://kubernetes.io/zh/docs/setup/best-practices/certificates/

Kubernetes集群中的X509客户端认证依赖于PKI证书体系,有如下三套CA证书系统

kubeadm部署Kubernetes集群时会自动生成所需要的证书，它们位于/etc/kubernetes/pki自录下

文件	Default CN	说明
ca.crt,ca.key	kubernetes-ca	Kubernetes general CA
etcd/ca.crt,etcd/ca.key	etcd-ca	For all etcd-related functions
front-proxy-ca.crt,front-proxyca.crt.key	kubernetes-frontproxy-ca	For the front-end proxy

2.1.2 X509创建用户证书（普通用户、管理员）

①创建普通用户

bash 复制代码

# 执行下面命令后展示的内容，表示默认kubernetes的CA签发的证书，都是k8s客户端的用户
grep '\-\-client-ca-file' /etc/kubernetes/manifests/kubeapiserver.yaml
- --client-ca-file=/etc/kubernetes/pki/ca.crt
# 创建存放证书的目录
mkdir pki
(umask 077; openssl genrsa -out pki/test.key 4096)

# 生成证书申请,加入ops组只具有普通权限
openssl req -new -key pki/test.key -out pki/test.csr -subj
"/CN=test/O=ops"

# 使用kubernetes-ca颁发证书
openssl x509 -req -days 3650 -CA /etc/kubernetes/pki/ca.crt -
CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -in pki/test.csr -out
pki/test.crt

#复制证书文件到到worker节点
#执行kubectl命令并指定apiserver地址和test用户的证书等信息
kubectl get pod --server=https://192.xx.xxx.xx:6443 --clientcertificate=pki/test.crt --client-key=pki/test.key --certificateauthority=/etc/kubernetes/pki/ca.crt

# Error from server (Forbidden): pods is forbidden: User "test" cannot list resource "pods" in API group "" in the namespace "default"
解决：
方法一：提升test用户的权限，加入管理员组或绑定其他权限
方法二：忽略证书校验
kubectl get pod -s https://192.xx.xxx.xx:6443 --clientcertificate=pki/test.crt --client-key=pki/test.key --insecure-skip-tlsverify=true

# 如果没有kubectl命令，也可以通过curl命令验证
curl --cert pki/test.crt --key pki/test.key --key-type PEM --
cacert /etc/kubernetes/pki/ca.crt https://192.xx.xxx.xx:6443

②创建管理员

将创建的用户加入管理员组。创建管理员时，指定O为system:masters

bash 复制代码

# 创建管理员用户testuser证书
(umask 077; openssl genrsa -out pki/testuser.key 4096)
#生成证书申请文件,注意：加入system:masters组或System组才具有管理权限
openssl req -new -key pki/testuser.key -out pki/testuser.csr -subj
"/CN=testuser/O=system:masters"
# 通过k8s ca签发证书
openssl x509 -req -days 3650 -CA /etc/kubernetes/pki/ca.crt -
CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -in pki/testuser.csr -out pki/testuser.crt
# 查看目录下的文件（应该有testuser.csr testuser.key testuser.crt文件）
ls pki

# 使用证书访问节点，观察是否有权限获取pod
kubectl get pods -s https://192.xx.xxx.xx:6443 --certificateauthority=/etc/kubernetes/pki/ca.crt --client-certificate=pki/testuser.crt --clientkey=pki/testuser.key

2.2 ServiceAccount管理

2.2.1 ServiceAccount概念

官方文档：https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/authentication/

用途：API Server对来自Pod中客户端程序进行身份验证

ServiceAccount也是API Server支持的标准资源类型

在Pod上使用ServiceAccount：

自动设定：Service Account通常由API Server自动创建并通过ServiceAccount准入控制器自动关联到集群中创建的每个Pod上

K8s自动为每个pod注入一个ServiceAccount及配套令牌

在每个namespace中，会自动生成(由ServiceAccount准入控制器负责)一个名称为default的ServiceAccount，并默认将其自动分配给该空间下的每个Pod共享使用

bash 复制代码

# 查看pod配置 -o yaml以yaml格式输出，-o json以json格式输出
kubectl get po nginx-statefulset-0 -o yaml  | grep -C 9 -i ServiceAccount

2.2.2 创建&使用ServiceAccount

查看SA

创建和使用SA账号

①查看和创建新SA

查看SA：

bash 复制代码

#每个命名空间都会有一个默认的default的SA账号名称
kubectl get sa -A

创建SA：

创建一个名为mysa的ServiceAccount。

定义了一个名为myrole的Role，允许get, watch, 和 list操作在pods, services, 和 secrets资源上。

创建一个RoleBinding，将myrole绑定到mysa，这样ServiceAccount就有了相应的权限。

如果我们希望ServiceAccount在整个集群范围内都有权限，我们需要创建一个ClusterRole和ClusterRoleBinding。（将yml中的Role和RoleBinding换成ClusterRole和ClusterRoleBinding）

bash 复制代码

# 创建namespace
kubectl create ns mynamespace

mysa.yml:

yml 复制代码

apiVersion: v1
kind: ServiceAccount
metadata:
  name: mysa
  namespace: mynamespace    # 指定命名空间，可忽略
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: myrole
  namespace: mynamespace    # 确保与ServiceAccount在同一命名空间
rules:
- apiGroups: [""]
  resources: ["pods", "services", "secrets"]
  verbs: ["get", "watch", "list"]

---

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: bind-mysa-to-myrole
  namespace: mynamespace    # 同样，确保与ServiceAccount和Role在同一命名空间
subjects:
- kind: ServiceAccount
  name: mysa
  namespace: mynamespace
roleRef:
  kind: Role
  name: myrole
  apiGroup: rbac.authorization.k8s.io

bash 复制代码

#创建账号
kubectl apply -f mysa.yml

bash 复制代码

# 查看sa账号(我们在mynamespace创建的，这里需要指定名称空间)
kubectl get sa -n mynamespace -o wide | grep mysa 

# 查看sa详情信息
kubectl describe sa -n mynamespace

SA账号配套的token是在secrets对象中,注意:k8s v1.24版后创建SA不会自动生成对应Secret

bash 复制代码

# 查看ServiceAccount的Secret信息
kubectl get secrets -n mynamespace
# 查看ServiceAccount详情
kubectl get sa mysa -n mynamespace -o yaml

②应用SA

在pod资源中一个属性专门来设置该资源属于哪个SA管理

bash 复制代码

# 查看pod.spec.serviceAccountName作用
kubectl explain pod.spec.serviceAccountName

# 创建rolebonding（给mynamespace的mysa赋予admin权限）
kubectl create clusterrolebinding mysa-clusterrolebinding --clusterrole=admin --serviceaccount=mynamespace:mysa

注意： SA可以跨名称空间进行授权，即A名称空间的SA帐号可以授权给B名称空间的权限，甚至对所有名称空间授权

2.3 kubectlconfig管理

前面介绍的使用X509或令牌方式创建用户的命令行方式需要指定很多选项,无疑是很麻烦的。

因此可以将用户的凭证信息保存在kubeconfig文件中方便使用，kubeconfig 是YAML格式的文件，用于存储身份认证信息，以便于客户端加载并认证接入到API Server。

kubeconfig 保存有认证到一或多个Kubernetes集群的相关配置信息，并允许管理员按需在各配置间灵活切换
通过kubeadm在创建集群的时候，其中有一步就是：生成kubernetes控制组件的kubeconfig文件及相关的启动配置文件,通过各种conf文件，让不同的组件具备操作相关资源的权限

总结：

kubectlconfig文件(yaml格式文件)清晰明了，方便下载
kubectlconfig支持配置多个环境。（类比Java SpringBoot多环境yml配置：dev、pre、pro）

2.3.1 kubectlconfig概念

kubectl管理多个context，每个context包含了访问k8s集群必要的两个配置：用户、地址。

clusters：每个Kubernetes集群的信息，包括集群对应访问端点（API Server）的地址
users：认证到API Server的用户的身份凭据列表
contexts：将每一个user同可认证到的cluster建立关联关系的上下文列表
current-context：当前默认使用的context

bash 复制代码

# 查看conf文件中的用户信息
awk '/client-certificate-data/{print $NF}' /config |
base64 -d | openssl x509 -noout -text

2.3.2 kubectlconfig创建和管理

kubectl config 命令可以创建和管理kubeconfig文件

bash 复制代码

# 查看帮助手册
kubectl config --help

bash 复制代码

Available Commands:
  current-context 显示 current_context
  delete-cluster  删除 kubeconfig 文件中指定的集群
  delete-context  删除 kubeconfig 文件中指定的 context
  delete-user     Delete the specified user from the kubeconfig
  get-clusters    显示 kubeconfig 文件中定义的集群
  get-contexts    描述一个或多个 contexts
  get-users       Display users defined in the kubeconfig
  rename-context  Renames a context from the kubeconfig file.
  set             设置 kubeconfig 文件中的一个单个值
  set-cluster     设置 kubeconfig 文件中的一个集群条目
  set-context     设置 kubeconfig 文件中的一个 context 条目
  set-credentials 设置 kubeconfig 文件中的一个用户条目
  unset           取消设置 kubeconfig 文件中的一个单个值
  use-context     设置 kubeconfig 文件中的当前上下文
  view            显示合并的 kubeconfig 配置或一个指定的 kubeconfig 文件

bash 复制代码

# 例如：查看当前使用的context
kubectl config current-context

bash 复制代码

# 使用testuser-context，后续执行kubectl命令
#会自动读取testuser-context存储的集群及用户凭证信息
kubectl config use-context testuser-context

3 安全认证综合案例

3.1 UserAccount创建&使用kubetlconfig

3.1.1 UserAccount创建

创建私钥文件（openssl genrsa -out user1.key 2048）

genrsa：用于生成rsa私钥（不会生成公钥，因为公钥提取自私钥）

out filename：指定私钥保存位置

numbits：指定私钥长度，默认1024

签名请求（openssl req -new -key user1.key -out user1.csr -subj
"/CN=user1/O=group"）

new 新建一个签名请求文件

key 指定已有私钥文件，签名请求，必须与-new搭配

out 输出证书文件名称

subj 指定生成证书的拥有者信息（CN及O的值：用户名及组名）

刚才的私钥和认证并没有被Kubernetes集群纳入到管理体系，需要基于kubeadm集群的CA相关证书来
进行认证

生成证书（openssl x509 -req -CA ./ca.crt -CAkey ./ca.key -
CAcreateserial -in user1.csr -out user1.crt -days 365）

-req 产生证书签发申请命令

-in 指定需要签名的请求文件

-CA 指定CA证书文件

-CAkey 指定CA证书的秘钥文件

-CAcreateserial 生成唯一的证书序列号

-x509 表示输出一个X509格式的证书

-days 指定证书过期时间为365天

-out 输出证书文件

openssl x509 -in user1.crt -text -noout：查看生成的证书信息

最终生成的文件：.key 是私钥，.csr是签名请求文件，.crt是证书

bash 复制代码

# 1 创建私钥文件
(umask 077; openssl genrsa -out user1.key 2048)
# 2 签名请求
openssl req -new -key user1.key -out user1.csr -subj "/CN=user1/O=group"
# 3 利用k8s ca机构签发证书
openssl x509 -req -in user1.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out user1.crt -days 365

#结果显示：*.key 是私钥，*.csr是签名请求文件

bash 复制代码

# 查看证书信息
openssl x509 -in user1.crt -text -noout

3.1.2 使用kubectlconfig

①创建kubectlconfig用户

bash 复制代码

# 1 指定用户证书、私钥，以及生成的conf文件位置
kubectl config set-credentials user1 --embed-certs=true --client-certificate=user1.crt --client-key=user1.key --kubeconfig=/tmp/user1.conf

#参数详解：

set-credentials #子命令的作用就是给kubeconfig认证文件创建一个用户条目

--client-certificate=path/to/certfile #指定用户的签证证书文件

--client-key=path/to/keyfile #指定用户的私钥文件

--embed-certs=true #在kubeconfig中为用户条目嵌入客户端证书/密钥，默认值是false

--kubeconfig=/path/other_config.file #表示将属性信息单独输出到一个文件，如不指定，默认存放在 ~/.kube/config文件中

②创建kubectlconfig集群

bash 复制代码

# --certificateauthority配置k8s ca证书路径
kubectl config set-cluster mycluster --server="https://localhost:6443" --embed-certs=true --kubeconfig=/tmp/user1.conf --certificate-authority=ca.crt

#参数详解：

--server=cluster_api_server

--certificate-authority=path/to/certificate/authority

--embed-certs=true #默认为false,会将证书文件路径存入kubeconfig文件中,true时会将证书内容存入kubdconfig文件中

true：则会将证书内容base64编码后存放到我们kubeconfig指定的.conf文件中。

false：.conf文件会直接将client-key等字段设置为具体路径

#注意：这里使用到的证书必须是kubernetes的ca证书。

③创建context（关联集群）

bash 复制代码

kubectl config set-context user1@mycluster --cluster=mycluster --user=user1 --kubeconfig=/tmp/user1.conf

#属性详解

--cluster=cluster_nickname 关联的集群名称

--user=user_nickname 关联的用户名称

--namespace=namespace 可以设置该生效的命名空间

查看配置文件最后效果：

bash 复制代码

kubectl config view --kubeconfig=/tmp/user1.conf

# 解析client-certificate-data、client-key-data（base64方式解析证书信息）
# kubectl config view --kubeconfig=/tmp/user1.conf --raw

总结

以rancher搭建的k8s为例

创建user1用户，不设置任何权限，预期用户创建成功，并能正常使用

bash 复制代码

openssl genrsa -out user1.key 2048

# 生成证书签名请求
openssl req -new -key user1.key -out user1.csr -subj "/CN=user1/O=group"

# 使用集群的CA证书和私钥对证书签名请求进行签名
openssl x509 -req -in user1.csr -CA /var/lib/rancher/rke2/server/tls/client-ca.crt -CAkey /var/lib/rancher/rke2/server/tls/client-ca.key -CAcreateserial -out user1.crt -days 365

# 创建一个kubectl配置文件（--embed-certs=true将认证内嵌其中）
kubectl config set-credentials user1 --embed-certs=true --client-certificate=user1.crt --client-key=user1.key

# 查看配置信息(并且显示认证信息（经过base64编码）)
kubectl config view --raw

# 设置上下文
kubectl config set-context user1-context --cluster=default --namespace=default --user=user1

# 切换到user1用户
kubectl config use-context user1-context

# 设置context证书文件
# kubectl config --kubeconfig=/root/user1/user1.yml set-credentials user1-context --client-certificate=/root/user1/user1.crt --client-key=/root/user1/user1.key

给user1分配所有权限：

user1-clusterrole.yml：

yaml 复制代码

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: user1-clusterrole
rules:
  - apiGroups: [ "*" ]
    resources: [ "*" ]
    verbs: [ "*" ]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: user1-clusterrole-binding
subjects:
  - kind: User
    name: user1 # 将user1应用ClusterRoleBinding
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: user1-clusterrole # ClusterRoleBinding绑定user1-clusterrole这个ClusterRole
  apiGroup: rbac.authorization.k8s.io

3.2 SA账号创建&使用kubectlconfig

创建sa账号

security-sa-admin.yaml：

bash 复制代码

apiVersion: v1
kind: ServiceAccount
metadata:
  name: admin
  namespace: default
---
#v1.24版之后添加下面内容手动创建secret
apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
  name: admin-secret
  annotations:
    kubernetes.io/service-account.name: "admin"

bash 复制代码

# 应用配置文件
kubectl apply -f security-sa-admin.yaml

查看和配置kubectlconfig

bash 复制代码

# 查看SA账号的Token
kubectl get secret admin-secret -n default -o jsonpath='{.data.token}' |base64 -d

# 将获取到的token设置到KUBEADMIN_TOKEN字段
KUBEADMIN_TOKEN=$(kubectl get secret admin-secret -n default -o jsonpath='{.data.token}' |base64 -d)

# 设置用户信息
kubectl config set-credentials kubeadmin --token=$KUBEADMIN_TOKEN --kubeconfig=/root/kubeadmin.conf
# 设置集群信息--certificate-authority
kubectl config set-cluster kubernetes --certificate-authority=/etc/kubernetes/pki/ca.crt --server="https://localhost:6443" --embed-certs=true --kubeconfig=/root/kubeadmin.conf

# 设置上下文信息context（集群及用户信息）
kubectl config set-context kubeadmin@kubernetes --cluster=kubernetes --user=kubeadmin --kubeconfig=/root/kubeadmin.conf

# 指定默认context
kubectl config use-context kubeadmin@kubernetes --kubeconfig=/root/kubeadmin.conf

# 给admin角色设置admin权限
kubectl create clusterrolebinding admin-binding --serviceaccount default:admin --clusterrole cluster-admin