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

1 核心概念

1.1 安全体系

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

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

  • 那么kubernetes的这种大型的任务编排系统来说,同样也陆续产生了一系列对平台的权限认证、对业务的权限认证、对网络的安全认证等认证体系
  • K8s官网:https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/

K8S权限及认证(3A):

在这里插入图片描述

  1. Authentication认证:校验用户身份,若不成功返401。多个认证插件进行逻辑。只要有一个插件校验通过就放行,进入下一关。【是不是我们的人】
  2. Authorization授权:什么样的用户有什么权限。不同用户获取不同的资源操作权限,比如普通用户、超级用户等。权限不足返回403<鉴权过程遵循“”逻辑,且任何一个插件对操作的许可授权后都将不再进行后续插件验证,如果都未许可则拒绝。【是什么角色,给你什么权限】
  3. Admission准入控制:用户认证、授权之后,当进行一些写操作的时候,需要遵循的一些限制的要求,比如资源限制内容合规性检查,遵循“”逻辑,且无论成败,每次操作都要经由所有插件检验,最后统一返回结果
    只对写操作进行合规性检查,在授权范围内,对用户的某些命令或者操作进行进一步的限制【操作造成的结果是否在合规范围内,需要所有插件检验通过】
    分为两类:
  • validaing 校验(合规性,资源默认和最大和最小限制)
  • mutating 变更(补全,默认值填充)

K8s安全校验流程解析:

  1. UA(普通人类账户)、SA(集群内部账户,内嵌账户)发起请求
  2. 认证、授权插件遵循短路与,如:多个认证插件,有一个成功就放行,让请求到达授权插件链;准入控制插件不遵循短路与,需要准入控制插件链上的插件都检测通过才允许请求往下走。
  3. 校验通过,访问k8s对应资源。
    在这里插入图片描述

①上图左侧的用户:

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

②中间:每个部分都是以插件的方式来整合到 kubernetes 集群环境中:
认证和授权是按照插件的顺序依次进行检测,并且遵循 “短路模型” 的认证方式所谓的"短路"即,失败的时候,到此结束,后续的规则不会进行。
准入控制 由于仅用户写操作场景,所以它不遵循 “短路模型”,而是会全部检测通过才允许执行原因在于,它要记录为什么不执行,原因是什么,方便后续审计等动作。

③右侧部分:k8s资源

1.2 认证机制

1.2.1 k8s中的用户

  1. UserAccount:非pod类的客户端来访问API Server,一般是我们现实中的"人"。常见的管理方式:openssl等。(K8s将这部分外包出去,由外部的第三方服务进行管理)【真实的人操作的账户、k8s外包出去、openssl】
  2. ServiceAccount(SA):k8s内部自带的、与pod关联的账号类型。主要用于集群pod内的进程访问API Server。该账号认证到API Server的信息称为Service Account Token,它们保存于同名的Secret对象中。【k8s内嵌、pod操作的账户】
  3. 匿名用户

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,可以通过该文件来检查一下这两者之间是一个怎样的关系。

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

结果:

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
# 查看k8s cluster-admin的用户权限
kubectl get clusterrole cluster-admin -o yaml

在这里插入图片描述

③查看集群和用户角色绑定关系:kubectl get clusterrolebinding cluster-admin -o yaml
# 查看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并不保证各认证插件的生效次序与定义的次序相同(认证插件遵循关系,有一个认证通过就放行,不再进行其他认证插件的校验。直接进入下一步授权)

# 在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.keykubernetes-caKubernetes general CA
etcd/ca.crt,etcd/ca.keyetcd-caFor all etcd-related functions
front-proxy-ca.crt,front-proxyca.crt.keykubernetes-frontproxy-caFor the front-end proxy

2.1.2 X509创建用户证书(普通用户、管理员)

①创建普通用户
# 执行下面命令后展示的内容,表示默认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

# 创建管理员用户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共享使用
# 查看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:

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

在这里插入图片描述
创建SA:

  1. 创建一个名为mysa的ServiceAccount。
  2. 定义了一个名为myrole的Role,允许get, watch, 和 list操作在pods, services, 和 secrets资源上。
  3. 创建一个RoleBinding,将myrole绑定到mysa,这样ServiceAccount就有了相应的权限。
  • 如果我们希望ServiceAccount在整个集群范围内都有权限,我们需要创建一个ClusterRole和ClusterRoleBinding。(将yml中的Role和RoleBinding换成ClusterRole和ClusterRoleBinding)
# 创建namespace
kubectl create ns mynamespace

mysa.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
#创建账号
kubectl apply -f mysa.yml

在这里插入图片描述

# 查看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

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

在这里插入图片描述

②应用SA

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

# 查看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文件,让不同的组件具备操作相关资源的权限

总结:

  1. kubectlconfig文件(yaml格式文件)清晰明了,方便下载
  2. 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

在这里插入图片描述

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

2.3.2 kubectlconfig创建和管理

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

# 查看帮助手册
kubectl config --help
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 文件
# 例如:查看当前使用的context
kubectl config current-context

在这里插入图片描述

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

3 安全认证综合案例

3.1 UserAccount创建&使用kubetlconfig

3.1.1 UserAccount创建

  1. 创建私钥文件(openssl genrsa -out user1.key 2048)
    • genrsa:用于生成rsa私钥(不会生成公钥,因为公钥提取自私钥)
    • out filename:指定私钥保存位置
    • numbits:指定私钥长度,默认1024
  2. 签名请求(openssl req -new -key user1.key -out user1.csr -subj
    “/CN=user1/O=group”)
    • new 新建一个签名请求文件
    • key 指定已有私钥文件,签名请求,必须与-new搭配
    • out 输出证书文件名称
    • subj 指定生成证书的拥有者信息(CN及O的值:用户名及组名)
    • 刚才的私钥和认证并没有被Kubernetes集群纳入到管理体系,需要基于kubeadm集群的CA相关证书来
      进行认证
  3. 生成证书(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是证书

# 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是签名请求文件

在这里插入图片描述

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

在这里插入图片描述

3.1.2 使用kubectlconfig

①创建kubectlconfig用户
# 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集群
# --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(关联集群)
kubectl config set-context user1@mycluster --cluster=mycluster --user=user1 --kubeconfig=/tmp/user1.conf

#属性详解

  • –cluster=cluster_nickname 关联的集群名称
  • –user=user_nickname 关联的用户名称
  • –namespace=namespace 可以设置该生效的命名空间

查看配置文件最后效果:

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用户,不设置任何权限,预期用户创建成功,并能正常使用
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:

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

  1. 创建sa账号

security-sa-admin.yaml:

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"
# 应用配置文件
kubectl apply -f security-sa-admin.yaml

在这里插入图片描述
2. 查看和配置kubectlconfig

# 查看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
Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐