【Kubernetes学习之连接集群】利用 kubeconfig 或 secret Token 连接 k8s 集群

2023-12-07 23:04
文章标签 云原生 集群 学习 kubernetes 连接 k8s token secret kubeconfig

本文主要是介绍【Kubernetes学习之连接集群】利用 kubeconfig 或 secret Token 连接 k8s 集群，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

参考

  • 通过kubeconfig文件生成证书，用curl访问Kubernetes API server_网络飞鸥的博客-CSDN博客
  • k8s用ServiceAccount Token的方式访问apiserver_kubenetes api 访问token-CSDN博客
  • k8s serviceaccount创建后没有生成对应的secret - SoulChild随笔记
  • 参考 | Kubernetes
  • Kubernetes API Reference Docs

1 | 用ServiceAccount Token的方式访问apiserver

在kubernetes集群，可以登陆到master集群，可以使用私钥证书的方式访问。证书路径：master的/etc/kubernetes/pki/(ca.crt / apiserver.crt / apiserver.key) 下面。

# server是apiserver公网访问地址
$ curl --cacert ca.crt --cert apiserver.crt --key apiserver.key https://$server/api

这里再介绍一下使用ServiceAccount Token的方式访问集群。
serviceaccount的权限由集群中对应的rolebinding决定，官方文档:
https://kubernetes.io/docs/reference/access-authn-authz/rbac

# 请选择对应权限的ServiceAccount来获取token，这边选择的是admin ServiceAccount
$ kubectl get sa admin -n kube-system -o yaml# 查看对应的clusterrolebinding：
$ kubectl get clusterrolebinding admin -o yaml# 查看admin sa绑定的clusterrole和对应的权限。命令：
$ kubectl get clusterrole admin -o yaml# 获取对应sa的secret从中获取token。并进行base64解码。
$ kubectl get secret admin-token-5tctj -n kube-system -o jsonpath={".data.token"} | base64 -d

最后使用该token访问apiserver：

最后使用公网slb地址访问。

# 如 curl -k -H 'Authorization: Bearer token' https://10.182.101.255:6443/api/v1/namespaces
curl -k -H 'Authorization: Bearer token' https://111.111.111.111:6443/path(api接口)

例如：

$ curl -k -H 'Authorization: Bearer hbGciOiJSUzI1NiIsImtpZCI6Ilg3RHRVOEZZdW0zVmZLV0JZeGlfVjJSTG1TQ1A3LWRPX0w1SUVvdldEWkkifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJkZWZhdWx0LXRva2VuLXBycjJsIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6ImRlZmF1bHQiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiIxN2U3NjAxMi1lYTE5LTRkNDktODM1NS0zMmQ4OGIzY2Y2YWEiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6a3ViZS1zeXN0ZW06ZGVmYXVsdCJ9.dLNfDTlxoEAMw115yT4NPsOgRcN1rOp9rCZYj9mAzbfKX3L1LNzLlCAYgcBjWdro5u-8NncOyWp9--vAyADq7yaa0T-tBfVALg8dESuwSQpSN-I5YOh7G8ua81HFjWFWX6dvq1GW2fbHPeXCJDlkBnJAbTGLb-487lbK0VWkSdLl1tsT435eZS5e6rRNIWAJJizVBrxDliND_7IXE6zILOR5u-A3z3wk3ngCv4e2FLNOR6z4qr2l-xyQG3pLXH2YQt_TjCkaR9kg57CRQRpwSiN6DfMfeq_qwI7d_iCawNSbLEBWRPEjA3j4juE64CcrA1fr58LIFxEr_ga949XgWw' https://10.182.101.255:6443/api/v1/namespaces$ curl -k -H 'Authorization: Bearer hbGciOiJSUzI1NiIsImtpZCI6Ilg3RHRVOEZZdW0zVmZLV0JZeGlfVjJSTG1TQ1A3LWRPX0w1SUVvdldEWkkifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJkZWZhdWx0LXRva2VuLXBycjJsIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6ImRlZmF1bHQiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiIxN2U3NjAxMi1lYTE5LTRkNDktODM1NS0zMmQ4OGIzY2Y2YWEiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6a3ViZS1zeXN0ZW06ZGVmYXVsdCJ9.dLNfDTlxoEAMw115yT4NPsOgRcN1rOp9rCZYj9mAzbfKX3L1LNzLlCAYgcBjWdro5u-8NncOyWp9--vAyADq7yaa0T-tBfVALg8dESuwSQpSN-I5YOh7G8ua81HFjWFWX6dvq1GW2fbHPeXCJDlkBnJAbTGLb-487lbK0VWkSdLl1tsT435eZS5e6rRNIWAJJizVBrxDliND_7IXE6zILOR5u-A3z3wk3ngCv4e2FLNOR6z4qr2l-xyQG3pLXH2YQt_TjCkaR9kg57CRQRpwSiN6DfMfeq_qwI7d_iCawNSbLEBWRPEjA3j4juE64CcrA1fr58LIFxEr_ga949XgWw' https://10.182.101.255:6443/api
{"kind": "APIVersions","versions": ["v1"],"serverAddressByClientCIDRs": [{"clientCIDR": "0.0.0.0/0","serverAddress": "172.20.8.14:6443"}]
}

2 | 个人测试使用 创建 token

在 Kubernetes 中，admin 和 cluster-admin 是两个不同的角色，它们在权限层级上有所不同。

  1. admin 角色：
    • admin 角色通常是指拥有特定命名空间（namespace）的管理员权限的用户或服务账户。这个角色允许用户执行一些与特定命名空间相关的管理任务，如创建、删除资源对象，以及查看和修改特定命名空间内的资源。
    • admin 角色没有集群范围的管理权限，只能对某个命名空间内的资源进行操作。该角色通常用于限定用户的权限，使其只能管理特定的资源。
  2. cluster-admin 角色：
    • cluster-admin 角色是 Kubernetes 中的超级管理员角色，具有对整个集群的完全控制权限。拥有 cluster-admin 角色的用户或服务账户可以对所有命名空间中的任何资源进行任意操作，包括创建、删除、修改以及访问集群级别的信息。
    • cluster-admin 角色通常用于赋予用户对整个集群的高级管理权限，比如执行集群范围的配置更改、安装插件或进行集群级别的监控。

总的来说，admin 角色是针对某个命名空间的管理员权限，而 cluster-admin 角色是对整个集群的超级管理员权限。在实践中，为了最小化权限并遵循最小权责原则，应该尽可能使用 admin 角色，只在必要时才授予用户或服务账户 cluster-admin 角色。

$ kubectl get clusterrole | grep admin
admin                                                                  2023-11-16T07:21:29Z
cluster-admin                                                          2023-11-16T07:21:29Z
system:aggregate-to-admin                                              2023-11-16T07:21:29Z
system:kubelet-api-admin                                               2023-11-16T07:21:29Z# 可以看出 cluster-admin 具有所有资源的所有权限
$ kubectl describe clusterrole cluster-admin
Name:         cluster-admin
Labels:       kubernetes.io/bootstrapping=rbac-defaults
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
PolicyRule:Resources  Non-Resource URLs  Resource Names  Verbs---------  -----------------  --------------  -----*.*        []                 []              [*][*]                []              [*]# 可以看出 admin 具有所有资源的部分权限（下面没有粘贴上全部内容，请自行查看自己的集群）
$ kubectl describe clusterrole admin
Name:         admin
Labels:       kubernetes.io/bootstrapping=rbac-defaults
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
PolicyRule:Resources                                       Non-Resource URLs  Resource Names  Verbs---------                                       -----------------  --------------  -----pods/attach                                     []                 []              [get list watch create delete deletecollection patch update]pods/exec                                       []                 []              [get list watch create delete deletecollection patch update]pods/portforward                                []                 []              [get list watch create delete deletecollection patch update]pods/proxy                                      []                 []              [get list watch create delete deletecollection patch update]secrets                                         []                 []              [get list watch create delete deletecollection patch update]services/proxy                                  []                 []              [get list watch create delete deletecollection patch update]bindings                                        []                 []              [get list watch]endpoints                                       []                 []              [get list watch]limitranges                                     []                 []              [get list watch]namespaces/status                               []                 []              [get list watch]namespaces                                      []                 []              [get list watch]persistentvolumeclaims/status                   []                 []              [get list watch]pods/log                                        []                 []              [get list watch]

2.1 | 个人测试使用 cluster-admin 角色

# 1. 创建 ServiceAccount
$ kubectl create sa cluster-admin-test -n kube-system# 2. 创建 ClusterRoleBinding
$ kubectl create clusterrolebinding cluster-admin-test-crb --clusterrole=cluster-admin --serviceaccount=kube-system:cluster-admin-test# 3. 由于现在 创建 sa 不自动生成 secret，因此创建个 secret 保持永久有效的 token, 使用 kubectl 执行下面内容
apiVersion: v1
kind: Secret
metadata:name: cluster-admin-test-secretnamespace: kube-systemannotations:kubernetes.io/service-account.name: "cluster-admin-test"   # 这里填写serviceAccountName
type: kubernetes.io/service-account-token# 4. 获取对应sa的secret从中获取token。并进行base64解码。
$ kubectl get secret cluster-admin-test-secret -n kube-system -o jsonpath={".data.token"} | base64 -d
# 注意要去掉后面的 % 号
eyJ....7X6Vd5sdVViZEr3Cv2xiGa2gzWRDgVXxZc1yJ64OKBOYHkEtay5t9bTulof1x4D-HefAPNGd5hdw% # 错误
eyJ....7X6Vd5sdVViZEr3Cv2xiGa2gzWRDgVXxZc1yJ64OKBOYHkEtay5t9bTulof1x4D-HefAPNGd5hdw  # 正确

2.2 | k8s serviceaccount 创建后没有生成对应的 secret

果然两天不看就跟不上了，我的集群版本是 1.25.3，今天需要用 token 来做些事情，创建 serviceAccount 的时候发现没有生成 secret，查了一下发现从 1.24 开始就不会自动生成 secret 了，chanagelog 在这里.

内容如下 LegacyServiceAccountTokenNoAutoGeneration 功能门是测试版，默认启用。启用后，不再为每个 ServiceAccount 自动生成包含服务帐户令牌的 Secret API 对象。使用 TokenRequest API 获取服务帐户令牌，或者如果需要未过期的令牌，请按照本指南为令牌控制器创建一个 Secret API 对象以填充服务帐户令牌

pr: https://github.com/kubernetes/kubernetes/pull/108309

在上面提到的两种方式要怎么用呢

方式 1 使用 TokenRequest API 来生成 token，获取方式如下

  • 使用 client-go 或者其他 api 调用工具来获取某个 serviceaccount 的 token
  • 创建 yaml，使用 kubectl apply -f
  • 使用 kubectl create token -n xxx <serviceaccount-name> 来获取一个临时的 token, 默认 1 小时

方式 2 创建 secret token，创建后从 secret 的 token 字段拿就可以了

apiVersion: v1
kind: Secret
metadata:name: secret-sa-sampleannotations:kubernetes.io/service-account.name: "sa-name"   # 这里填写serviceAccountName
type: kubernetes.io/service-account-token

3 | 理解 ~/.kube/config 文件

在 Kubernetes 的 kubeconfig 文件中，以下三个字段用于配置客户端认证：

  1. client-certificate-data：
    • 该字段包含了 Base64 编码的客户端证书数据（PEM 格式）。客户端证书用于验证客户端身份。
  2. client-key-data：
    • 该字段包含了 Base64 编码的客户端私钥数据（PEM 格式）。客户端私钥用于与客户端证书进行配对，以进行身份验证。
  3. certificate-authority-data：
    • 该字段包含了 Base64 编码的证书颁发机构（CA）的根证书数据（PEM 格式）。CA 证书用于验证服务器端证书的有效性。

这些字段是客户端认证的一部分，通常与 users 部分的某个具体用户配置关联。以下是一个示例 kubeconfig 文件片段，演示了如何配置客户端认证：

apiVersion: v1
clusters:
- cluster:server: https://<kubernetes-api-server>certificate-authority-data: <base64-encoded-ca-cert>name: my-cluster
contexts:
- context:cluster: my-clusteruser: my-username: my-context
current-context: my-context
kind: Config
preferences: {}
users:
- name: my-useruser:client-certificate-data: <base64-encoded-client-cert>client-key-data: <base64-encoded-client-key>---- 
# 实际环境信息
apiVersion: v1
clusters:
- cluster:certificate-authority-data: LS0tLS1CRUdJTi......NG1DN1NqeUJDNUkKKzZFPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==server: https://127.0.0.1:63522name: kind-12403-k8s-cluster
contexts:
- context:cluster: kind-12403-k8s-clusteruser: kind-12403-k8s-clustername: kind-12403-k8s-cluster
current-context: kind-12403-k8s-cluster
kind: Config
preferences: {}
users:
- name: kind-12403-k8s-clusteruser:client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ......RVJUSUZJQ0FURS0tLS0tCg==client-key-data: LS0tLS1CRUdJTi......NzBIWUg1Ci0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==

请注意，<base64-encoded-ca-cert>、<base64-encoded-client-cert>、<base64-encoded-client-key> 分别是 Base64 编码的 CA 证书、客户端证书和客户端私钥数据。这些字段的值可以通过将相应的 PEM 格式文件内容进行 Base64 编码获得。

4 | 使用 kubeconfig 文件访问集群

Kubernetes是一个完全基于API的系统。使用curl或Postman等简单工具，在构建应用程序之前获取API信息更方便。

1、从查看 kubectl 的配置文件开始，需要：三个证书和 API server 的地址

# cat /root/.kube/config

2、我们将会把证书设为环境变量，在设置时候请检查每一个参数。我们从 client-certificate-data 开始。

export clientcert=$(grep client-cert ~/.kube/config |cut -d" " -f 6)  
echo $clientcert

3、使用类似的命令将 client-key-data 保存为环境变量

export clientkey=$(grep client-key-data ~/.kube/config |cut -d" " -f 6)  
echo $clientkey

4、然后是 certificate-authority-data

export certauth=$(grep certificate-authority-data ~/.kube/config |cut -d" " -f 6)  
echo $certauth

5、加密这些变量，供 curl 使用：

[root@master k8s-cert\]# echo $clientcert | base64 -d > ./client.pem  
[root@master k8s-cert\]# echo $clientkey | base64 -d > ./client-key.pem  
[root@master k8s-cert\]# echo $certauth | base64 -d > ./ca.pem

6、从配置文件中读取 server 地址：

$ kubectl config view |grep server  
server: https://10.182.101.255:6443

7、使用 curl 和刚刚加密的密钥文件来访问 API server：

curl --cert ./client.pem --key ./client-key.pem --cacert ./ca.pem https://10.182.101.255:6443/api/v1/pods
curl --cert ./client.pem --key ./client-key.pem --cacert ./ca.pem https://10.182.101.255:6443/api/v1/namespace

4.1 | 命令小结

export clientcert=$(grep client-cert ~/.kube/config |cut -d" " -f 6)
export clientkey=$(grep client-key-data ~/.kube/config |cut -d" " -f 6)
export certauth=$(grep certificate-authority-data ~/.kube/config |cut -d" " -f 6)
echo $clientcert | base64 -d > ./client.pem
echo $clientkey | base64 -d > ./client-key.pem
echo $certauth | base64 -d > ./ca.pemcurl --cert ./client.pem --key ./client-key.pem --cacert ./ca.pem https://10.182.101.255:6443/api/v1/pods

这篇关于【Kubernetes学习之连接集群】利用 kubeconfig 或 secret Token 连接 k8s 集群的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/467656。

相关文章

MySQL中的表连接原理分析

MySQL中的表连接原理分析

《MySQL中的表连接原理分析》：本文主要介绍MySQL中的表连接原理分析,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录1、背景2、环境3、表连接原理【1】驱动表和被驱动表【2】内连接【3】外连接【4编程】嵌套循环连接【5】join buffer4、总结1、背景
阅读更多...
Redis分片集群、数据读写规则问题小结

Redis分片集群、数据读写规则问题小结

《Redis分片集群、数据读写规则问题小结》本文介绍了Redis分片集群的原理,通过数据分片和哈希槽机制解决单机内存限制与写瓶颈问题,实现分布式存储和高并发处理,但存在通信开销大、维护复杂及对事务支持... 目录一、分片集群解android决的问题二、分片集群图解 分片集群特征如何解决的上述问题？（与哨兵模
阅读更多...
SpringBoot连接Redis集群教程

SpringBoot连接Redis集群教程

《SpringBoot连接Redis集群教程》：本文主要介绍SpringBoot连接Redis集群教程,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录1. 依赖2. 修改配置文件3. 创建RedisClusterConfig4. 测试总结1. 依赖 <de
阅读更多...
k8s上运行的mysql、mariadb数据库的备份记录(支持x86和arm两种架构)

k8s上运行的mysql、mariadb数据库的备份记录(支持x86和arm两种架构)

《k8s上运行的mysql、mariadb数据库的备份记录(支持x86和arm两种架构)》本文记录在K8s上运行的MySQL/MariaDB备份方案,通过工具容器执行mysqldump,结合定时任务实... 目录前言一、获取需要备份的数据库的信息二、备份步骤1.准备工作（X86）1.准备工作（arm）2.手
阅读更多...
Go学习记录之runtime包深入解析

Go学习记录之runtime包深入解析

《Go学习记录之runtime包深入解析》Go语言runtime包管理运行时环境,涵盖goroutine调度、内存分配、垃圾回收、类型信息等核心功能,：本文主要介绍Go学习记录之runtime包的... 目录前言：一、runtime包内容学习1、作用：① Goroutine和并发控制：② 垃圾回收：③ 栈和
阅读更多...
java连接opcua的常见问题及解决方法

java连接opcua的常见问题及解决方法

《java连接opcua的常见问题及解决方法》本文将使用EclipseMilo作为示例库,演示如何在Java中使用匿名、用户名密码以及证书加密三种方式连接到OPCUA服务器,若需要使用其他SDK,原理... 目录一、前言二、准备工作三、匿名方式连接3.1 匿名方式简介3.2 示例代码四、用户名密码方式连接4
阅读更多...
Android学习总结之Java和kotlin区别超详细分析

Android学习总结之Java和kotlin区别超详细分析

《Android学习总结之Java和kotlin区别超详细分析》Java和Kotlin都是用于Android开发的编程语言,它们各自具有独特的特点和优势,：本文主要介绍Android学习总结之Ja... 目录一、空安全机制真题 1：Kotlin 如何解决 Java 的 NullPointerExceptio
阅读更多...
MySQL 表的内外连接案例详解

MySQL 表的内外连接案例详解

《MySQL表的内外连接案例详解》本文给大家介绍MySQL表的内外连接,结合实例代码给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友参考下吧... 目录表的内外连接（重点）内连接外连接表的内外连接（重点）内连接内连接实际上就是利用where子句对两种表形成的笛卡儿积进行筛选，我
阅读更多...
Apache 高级配置实战之从连接保持到日志分析的完整指南

Apache 高级配置实战之从连接保持到日志分析的完整指南

《Apache高级配置实战之从连接保持到日志分析的完整指南》本文带你从连接保持优化开始,一路走到访问控制和日志管理,最后用AWStats来分析网站数据,对Apache配置日志分析相关知识感兴趣的朋友... 目录Apache 高级配置实战：从连接保持到日志分析的完整指南前言 一、Apache 连接保持 - 性
阅读更多...
SpringBoot整合Sa-Token实现RBAC权限模型的过程解析

SpringBoot整合Sa-Token实现RBAC权限模型的过程解析

《SpringBoot整合Sa-Token实现RBAC权限模型的过程解析》：本文主要介绍SpringBoot整合Sa-Token实现RBAC权限模型的过程解析,本文给大家介绍的非常详细,对大家的学... 目录前言一、基础概念1.1 RBAC模型核心概念1.2 Sa-Token核心功能1.3 环境准备二、表结
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2