本文主要是介绍逃脱只会部署集群系列 —— k8s集群认证、授权、安全控制，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
目录
一、APIServer安全控制机制
1、Authentication：身份认证
2、Authorization：鉴权，你可以访问哪些资源
3、Admission Control：准入控制，用于拦截请求的一种方式
二、kubectl的认证授权
1、kubectl的日志调试级别
2、kubeadm怎么默认授权kubectl
3、kubectl的认证阶段
4、kubectl的授权阶段
三、kubelet的认证授权
1、kubelet的认证阶段
2、kubelet的授权阶段
3、kubelet授权记住特殊性
四、Service Account及K8S Api调用
1、创建serviceaccount并绑定角色
2、查看创建sa的token
3、K8s API调用
文章主要介绍了k8s集群的认证、授权、安全控制模式，说明一个组件或者一个用户是如何划分应有的权限，具体追溯kubectl、kubelet、Service Account等整个控制过程。
一、APIServer安全控制机制
-
1、Authentication：身份认证
-
这个环节它面对的输入是整个
http request，负责对来自client的请求进行身份校验，支持的方法包括:-
basic auth（基本废弃） -
client证书验证（https双向验证）
-
jwt token(用于serviceaccount)
-
-
APIServer启动时，可以指定一种Authentication方法，也可以指定多种方法。如果指定了多种方法，那么APIServer将会逐个使用这些方法对客户端请求进行验证， 只要请求数据通过其中一种方法的验证，APIServer就会认为Authentication成功；
-
使用kubeadm引导启动的k8s集群，apiserver的初始配置中，默认支持
client证书验证和serviceaccount两种身份验证方式。 证书认证通过设置--client-ca-file根证书以及--tls-cert-file和--tls-private-key-file来开启。 -
在这个环节，apiserver会通过client证书或
http header中的字段(比如serviceaccount的jwt token)来识别出请求的用户身份，包括”user”、”group”等，这些信息将在后面的authorization环节用到。
-
-
2、Authorization：鉴权，你可以访问哪些资源
-
这个环节面对的输入是
http request context中的各种属性，包括：user、group、request path（比如：/api/v1、/healthz、/version等）、request verb(比如：get、list、create等)。 -
APIServer会将这些属性值与事先配置好的访问策略(
access policy）相比较。APIServer支持多种authorization mode，包括Node、RBAC、Webhook等。 -
APIServer启动时，可以指定一种
authorization mode，也可以指定多种authorization mode，如果是后者，只要Request通过了其中一种mode的授权， 那么该环节的最终结果就是授权成功。在较新版本kubeadm引导启动的k8s集群的apiserver初始配置中，authorization-mode的默认配置是”Node,RBAC”。
-
-
3、Admission Control：准入控制，用于拦截请求的一种方式
-
偏集群安全控制、管理方面。
-
为什么需要？
认证与授权获取 http 请求 header 以及证书，无法通过body内容做校验。
Admission 运行在 API Server 的增删改查 handler 中，可以自然地操作 API resource
-
举个栗子
-
以NamespaceLifecycle为例， 该插件确保处于Termination状态的Namespace不再接收新的对象创建请求，并拒绝请求不存在的Namespace。该插件还可以防止删除系统保留的Namespace:default，kube-system，kube-public。
-
LimitRanger，若集群的命名空间设置了LimitRange对象，若Pod声明时未设置资源值，则按照LimitRange的定义来未Pod添加默认值
-
apiVersion: v1 kind: LimitRange metadata:name: mem-limit-rangenamespace: luffy spec:limits:- default:memory: 512MidefaultRequest:memory: 256Mitype: Container --- apiVersion: v1 kind: Pod metadata:name: default-mem-demo-2 spec:containers:- name: default-mem-demo-2-ctrimage: nginx:alpine -
NodeRestriction， 此插件限制kubelet修改Node和Pod对象，这样的kubelets只允许修改绑定到Node的Pod API对象，以后版本可能会增加额外的限制 。开启Node授权策略后，默认会打开该项
-
-
怎么用？
APIServer启动时通过
--enable-admission-plugins --disable-admission-plugins指定需要打开或者关闭的 Admission Controller -
场景
-
自动注入sidecar容器或者initContainer容器
-
webhook admission，实现业务自定义的控制需求
-
-
二、kubectl的认证授权
1、kubectl的日志调试级别
| 信息 | 描述 |
|---|---|
| v=0 | 通常，这对操作者来说总是可见的。 |
| v=1 | 当您不想要很详细的输出时，这个是一个合理的默认日志级别。 |
| v=2 | 有关服务和重要日志消息的有用稳定状态信息，这些信息可能与系统中的重大更改相关。这是大多数系统推荐的默认日志级别。 |
| v=3 | 关于更改的扩展信息。 |
| v=4 | 调试级别信息。 |
| v=6 | 显示请求资源。 |
| v=7 | 显示 HTTP 请求头。 |
| v=8 | 显示 HTTP 请求内容。 |
| v=9 | 显示 HTTP 请求内容，并且不截断内容。 |
我们可以利用调试，获取kubectl请求时读取的文件（/root/.kube/config）以及请求地址（https://192.168.0.121:6443即apiserver的地址）
[root@k8s-master ~]# kubectl get nodes -v=7
I1120 12:31:58.065224 43018 loader.go:375] Config loaded from file: /root/.kube/config
I1120 12:31:58.068895 43018 round_trippers.go:420] GET https://192.168.0.121:6443/api?timeout=32s
I1120 12:31:58.068964 43018 round_trippers.go:427] Request Headers:
I1120 12:31:58.068974 43018 round_trippers.go:431] Accept: application/json, */*2、kubeadm怎么默认授权kubectl
kubeadm init启动完master节点后，会默认输出类似下面的提示内容：
... ...Your Kubernetes master has initialized successfully!To start using your cluster, you need to run the following as a regular user:mkdir -p $HOME/.kubesudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/configsudo chown $(id -u):$(id -g) $HOME/.kube/config... ... 这些信息是在告知我们如何配置kubeconfig文件。按照上述命令配置后，master节点上的kubectl就可以直接使用$HOME/.kube/config的信息访问k8s cluster了。 并且，通过这种配置方式，kubectl也拥有了整个集群的管理员(root)权限。当然，如果是二进制部署该步骤也是手动创建好admin.conf文件然后拷贝的。
现在讲解下 Kubernetes的kube-apiserver是如何对来自kubectl的访问进行认证(authentication)和授权(authorization)，以及kubectl具备哪些授权。
3、kubectl的认证阶段
通过上述得知，kubectl利用config文件向apiserver发起请求，前面提到过apiserver的authentication支持通过tls client certificate、basic auth、token等方式对客户端发起的请求进行身份校验， 从kubeconfig信息来看，kubectl显然在请求中使用了tls client certificate的方式，即客户端的证书。
我们获取 client-certificate-data的内容进行证书base64解码：
echo 'LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM4akNDQWRxZ0F3SUJBZ0lJYi8xa3dCNzZ4TVF3RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExVUUKQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TVRFeE1Ea3hNelV6TUROYUZ3MHlNakV4TURreE16VXpNRGhhTURReApGekFWQmdOVkJBb1REbk41YzNSbGJUcHRZWE4wWlhKek1Sa3dGd1lEVlFRREV4QnJkV0psY201bGRHVnpMV0ZrCmJXbHVNSUlCSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQVE4QU1JSUJDZ0tDQVFFQXcvY0IyK0crRURaWDhveDYKTjMvUk8rQmxFNExUUlMrSzZJZzJrTVJ5WVcxbkZEMHVobDloaTd1OXhzVEt3eVlrdE1OQWFMeFUzbFpLcDAzMApDTnRPdVg4aXFRYVlZOGg0NEc5V3Q1YTNjM00rYitRNnFQZWhwYmhTanVCZnNFU3JOUG5ZTnlnTnZLMFM5T0RPCjdHLzBrVHdJajA3OW9sWS96eEkxQXJBaWVnb2dBbnJ0OUZ0NWZ2eUpuZjYzTW5FdXgyVG5oc2h1YitTc2VSYkgKNU5HWFMzVHNPRXlmQUZqUW95SkRsbkdIU0xLVzJTdVVkODhlVDhCL0x5b0NHN0pNZllmKzVEMjBHN3ROZktKRQpYT2xiZFp0Sldub3pjSTlCMEFjdHlLNWo0NndTOVcyU2V4em9hQVV3VEhDM0Y4Qy9IQlROQ3JrZXpRSU1FQ0hlCnNCYy9Vd0lEQVFBQm95Y3dKVEFPQmdOVkhROEJBZjhFQkFNQ0JhQXdFd1lEVlIwbEJBd3dDZ1lJS3dZQkJRVUgKQXdJd0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFLT2ZCdFlmWTltcFg3TU9FaEdtditCQk1IeTRleVd3eUFzUwpHSUgxSUNmNnd6aXZhVTJjRnRzektON2xkMy9nNXZwVHJSMUV5akJYK1B6SjFPVmdubFU4c0p0L0ZDdHBPWnVkCmhRbU9tejRqeTBRLzErMnZ4TGhqTXlXbmxLYmtBOFhMRDlqVkpIM21iRS9FOXNIVU03WHNCT2Ixbk14TU5MUTMKSXRQSWRQVWd3UXVOS2ErY0diaXdqMmVJMlgwSTE2aDRvLzJhQ2Z6R0VtMHV0bFRIdmczdkQydlZNTlpYV3lTQQowVUxaZVkyeThyQVViN3FpbHp4YmdIMStCUndiOStvSEovdW80UlNURjlXaVFmcFFiN3RCQU40TGlxOFJRTjY5CmU3MEoxVit4cThkSk9PZFBGVUFUWWsxeUdkbi81bDY1dlAzYnNneitaMjNLTGw3ZmxNcz0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=' | base64 -d > 123.crt 在认证阶段，apiserver会首先使用--client-ca-file配置的CA证书去验证kubectl提供的证书的有效性,我们可以手动认证下证书是否有效 ，到这里为止，认证通过，代表这个请求可以进来了，大门开放
[root@k8s-master ~]# openssl verify -CAfile /etc/kubernetes/pki/ca.crt 123.crt
kubectl.crt: OK除了认证身份，还会取出必要的信息供授权阶段使用，文本形式查看证书内容，我们取出请求对应的用户组或者用户发给授权机制：
[root@k8s-master ~]# openssl x509 -in 123.crt -text
Certificate:Data:Version: 3 (0x2)Serial Number: 8069716883634046148 (0x6ffd64c01efac4c4)Signature Algorithm: sha256WithRSAEncryptionIssuer: CN=kubernetesValidityNot Before: Nov 9 13:53:03 2021 GMTNot After : Nov 9 13:53:08 2022 GMT# 重点是这里，我们可以获取到该请求对应的用户组：system:masters，用户：kubernetes-adminSubject: O=system:masters, CN=kubernetes-adminSubject Public Key Info:Public Key Algorithm: rsaEncryptionPublic-Key: (2048 bit)Modulus:00:c3:f7:01:db:e1:be:10:36:57:f2:8c:7a:37:7f:d1:3b:e0:65:13:82:d3:45:2f:8a:e8:88:36:90:c4:4、kubectl的授权阶段
kubeadm在init初始引导集群启动过程中，创建了许多默认的RBAC规则， 在k8s有关RBAC的官方文档中(使用 RBAC 鉴权 | Kubernetes)，我们看到下面一些default clusterrole列表:
其中第一个cluster-admin这个cluster role binding绑定了system:masters group，这和authentication环节传递过来的身份信息不谋而合。 此处涉及到RBAC的用户组和角色绑定，不做具体阐述了Using RBAC Authorization | Kubernetes。
我们可以看出：kubectl请求授权传递的用户组是system:masters，该用户组绑定了cluster-admin的cluster role角色，并且具有超级用户在平台上的任何资源上执行所有操作。
[root@k8s-master ~]# kubectl describe clusterrolebinding cluster-admin
Name: cluster-admin
Labels: kubernetes.io/bootstrapping=rbac-defaults
Annotations: rbac.authorization.kubernetes.io/autoupdate: true
Role:Kind: ClusterRoleName: cluster-admin
Subjects:Kind Name Namespace---- ---- ---------Group system:masters [root@k8s-master ~]# 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--------- ----------------- -------------- -----*.* [] [] [*][*] [] [*]
整个请求过程如图：
三、kubelet的认证授权
1、kubelet的认证阶段
老规矩，kubectl通过v=7查看请求用到的配置文件，从而获取对应的证书等内容，kubelet进程通过status查看启动参数即可。
继续，查看启动参数的配置文件，获取证书内容，base64解密证书把请求的用户或者用户组先拎出来，然后看看集群有没有利用binding赋予相应的权限。
# 1、读取启动参数配置文件
[root@k8s-master ~]# # vim /etc/kubernetes/kubelet.conf # 2、解密配置文件中的证书内容
[root@k8s-master ~]# echo 'LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM5akNDQWQ2Z0F3SUJBZ0lJWlNLMS8vdCtvM1V3RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExVUUKQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TVRFeE1Ea3hNelV6TUROYUZ3MHlNakV4TURreE16VXpNRGhhTURneApGVEFUQmdOVkJBb1RESE41YzNSbGJUcHViMlJsY3pFZk1CMEdBMVVFQXhNV2MzbHpkR1Z0T201dlpHVTZhemh6CkxXMWhjM1JsY2pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTUJsblJzMWkxS0UKTWw3ejgvMWN5VTlwczlIZVVsMllOenh0bEl3ZzFDOUtGUXVuMHV0aEMrNk0xNG9lcFNRVkF4cUZjK2dnQXlsMgpXTEFoZ0U5YVdyU0FWZWNjaHdKd0dianFIYmZBd2UvR3JZMGZrUEtMQlZ0UVJ1Znl2TEovQUluNUdqVkZ0Z2UxClVWa1JtZXBkWGxlUTc4bG5rZExvbGRQMThFYU5OcEdqcjY5Q1VSbjI1Zm8xTmpXSjhOZ3JDOHJxY2YxSHZUaUgKWVFWenRwaHh1MEo5b1Z1K2Ftc3h3RU5pRTBOOHdsS29lNG1NRTUvaTJhRHZ4VU9GNjlRMmE1c0QwQzBXVVJMYwppWWd6bWxsZjRuMldHMkxCRnRpRlpYWmdYTkNyMm91MkcvMjlZN0pIR0V4VjdOOFN0S0tvSEFjcm9FWGFhVTQwCmFHS04vRmVsSUxjQ0F3RUFBYU1uTUNVd0RnWURWUjBQQVFIL0JBUURBZ1dnTUJNR0ExVWRKUVFNTUFvR0NDc0cKQVFVRkJ3TUNNQTBHQ1NxR1NJYjNEUUVCQ3dVQUE0SUJBUUJmZnR4RlB6ODl6TURJVGNOVUpTTURxL2c4NzhsVQpKMmphdjZMRzVZNTlWeWQwMzMzd2ZidG5hY0VtZnY1L0paVDFPZXREdHJVMmJnOTA2VllFR3RDR3laM2d6dDY5Ckc2VFZBY3pBS3VZMGlIcVl6UTRIdFVKSEZyZXY1aDduaXRaNmhiTEVJU3l5VUpvMFlIc1FxRmUzYkduOGg2UVYKMzRoalQ5NXEzRUp3SWV2VGM3UWh2dlBoaEpEMjU2elFTYkR5QzN6VWdMamxDcmNONERkWmw1VjRVU1FUWVpKUApuT01WbGhoTkRBOVMrWEJZN09MMDkxQzJaR0dDRHVrSnpMOVgwaUQ1VHlNazBZbnZhb01yQy9Cblg0U2FKSDFUCm5XV0Vud0lwQTlXNzVvZlJ6ZTRCSndkNmk1eExnQ0MrVkpOK0pIaVRkK2VnQ3ZiN3l2cTI5eTR1Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K' | base64 -d > kubelet.crt# 3、验证证书有效性，OK说明认证阶段通过
[root@k8s-master ~]# openssl verify -CAfile /etc/kubernetes/pki/ca.crt kubelet.crt
kubelet.crt: OK# 4、或者kubelet请求的用户组和用户
[root@k8s-master ~]# openssl x509 -in kubelet.crt -text
Certificate:Data:Version: 3 (0x2)Serial Number: 7287587258079552373 (0x6522b5fffb7ea375)Signature Algorithm: sha256WithRSAEncryptionIssuer: CN=kubernetesValidityNot Before: Nov 9 13:53:03 2021 GMTNot After : Nov 9 13:53:08 2022 GMTSubject: O=system:nodes, CN=system:node:k8s-master
2、kubelet的授权阶段
K8s会把O作为Group来进行请求，因此如果有权限绑定给这个组，肯定在clusterrolebinding的定义中可以找得到。因此尝试去找一下绑定了system:nodes组的clusterrolebinding
[root@k8s-master ~]# kubectl get clusterrolebinding|awk 'NR>1{print $1}'|xargs kubectl get clusterrolebinding -oyaml|grep -n10 system:nodes
76- resourceVersion: "172"
77- selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/kubeadm%3Anode-autoapprove-certificate-rotation
78- uid: 5d227fdf-57e9-4003-b410-55acf820b765
79- roleRef:
80- apiGroup: rbac.authorization.k8s.io
81- kind: ClusterRole
82- name: system:certificates.k8s.io:certificatesigningrequests:selfnodeclient
83- subjects:
84- - apiGroup: rbac.authorization.k8s.io
85- kind: Group
86: name: system:nodes
87-- apiVersion: rbac.authorization.k8s.io/v1
88- kind: ClusterRoleBinding
89- metadata:
90- creationTimestamp: "2021-11-09T13:53:47Z"
91- name: kubeadm:node-proxier
92- resourceVersion: "200"
93- selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/kubeadm%3Anode-proxier
94- uid: 97c4ec4b-f745-4060-977f-77ed94321100
95- roleRef:
96- apiGroup: rbac.authorization.k8s.io[root@k8s-master ~]# kubectl describe clusterrole system:certificates.k8s.io:certificatesigningrequests:selfnodeclient
Name: system:certificates.k8s.io:certificatesigningrequests:selfnodeclient
Labels: kubernetes.io/bootstrapping=rbac-defaults
Annotations: rbac.authorization.kubernetes.io/autoupdate: true
PolicyRule:Resources Non-Resource URLs Resource Names Verbs--------- ----------------- -------------- -----certificatesigningrequests.certificates.k8s.io/selfnodeclient [] [] [create] 结局有点意外，除了system:certificates.k8s.io:certificatesigningrequests:selfnodeclient外，没有找到system相关的rolebindings，显然和我们的理解不一样。 尝试去找Using RBAC Authorization | Kubernetes发现了这么一段 :
| Default ClusterRole | Default ClusterRoleBinding | Description |
|---|---|---|
| system:kube-scheduler | system:kube-scheduler user | Allows access to the resources required by the schedulercomponent. |
| system:volume-scheduler | system:kube-scheduler user | Allows access to the volume resources required by the kube-scheduler component. |
| system:kube-controller-manager | system:kube-controller-manager user | Allows access to the resources required by the controller manager component. The permissions required by individual controllers are detailed in the controller roles. |
| system:node | None | Allows access to resources required by the kubelet, including read access to all secrets, and write access to all pod status objects. You should use the Node authorizer and NodeRestriction admission plugin instead of the system:node role, and allow granting API access to kubelets based on the Pods scheduled to run on them. The system:node role only exists for compatibility with Kubernetes clusters upgraded from versions prior to v1.8. |
| system:node-proxier | system:kube-proxy user | Allows access to the resources required by the kube-proxycomponent. |
大致意思是说：之前会定义system:node这个角色，目的是为了kubelet可以访问到必要的资源，包括所有secret的读权限及更新pod状态的写权限。如果1.8版本后，是建议使用 Node authorizer and NodeRestriction admission plugin 来代替这个角色的。
我们目前使用1.16，查看一下授权策略：
$ ps axu|grep apiserver kube-apiserver --authorization-mode=Node,RBAC --enable-admission-plugins=NodeRestriction
查看一下官网对Node authorizer的介绍（Using Node Authorization | Kubernetes）：
Node authorization is a special-purpose authorization mode that specifically authorizes API requests made by kubelets.
In future releases, the node authorizer may add or remove permissions to ensure kubelets have the minimal set of permissions required to operate correctly.
In order to be authorized by the Node authorizer, kubelets must use a credential that identifies them as being in the system:nodes group, with a username of system:node:<nodeName>
3、kubelet授权记住特殊性
如果你看的有点懵，那么记住结论就好了：kubelet（1.8版本后）利用证书模式仅作认证，利用NODE模式进行授权，Node 授权器允许 kubelet 执行 API 操作。而且目前看来，只有kubelet利用node授权，其他还是都用RBAC授权。
四、Service Account及K8S Api调用
前面说，认证可以通过证书，也可以通过使用ServiceAccount（服务账户）的方式来做认证。大多数时候，我们在基于k8s做二次开发时都是选择通过ServiceAccount + RBAC 的方式。我们之前访问dashboard的时候，是如何做的？
目的：创建一个ServiceAccount，创建或者使用一个现有的ClusterRole角色与sa绑定，当sa请求时不通过携带证书，而是通过token的方式成功获取集群内容
1、创建serviceaccount并绑定角色
新建一个名为admin的serviceaccount，并且把名为cluster-admin的这个集群角色的权限授予新建的 serviceaccount
[root@k8s-master ~]# cat ca-api.yaml
apiVersion: v1
kind: ServiceAccount
metadata:name: adminnamespace: default
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:name: adminannotations:rbac.authorization.kubernetes.io/autoupdate: "true"
roleRef:kind: ClusterRolename: cluster-adminapiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccountname: adminnamespace: default
[root@k8s-master ~]# kubectl create -f ca-api.yaml
serviceaccount/admin created
clusterrolebinding.rbac.authorization.k8s.io/admin created2、查看创建sa的token
默认创建sa都会同时创建一个对应的secret，我们可以直接查看secret内容获取token
# 查看创建的sa
[root@k8s-master ~]# kubectl get sa admin -o yaml
apiVersion: v1
kind: ServiceAccount
metadata:creationTimestamp: "2021-11-20T09:24:15Z"name: adminnamespace: defaultresourceVersion: "60267"selfLink: /api/v1/namespaces/default/serviceaccounts/adminuid: 7a2db3d5-84eb-4339-a8cd-4b95115f4688
secrets:
- name: admin-token-bs4sg# 查看创建ca对应的secret，获取token
[root@k8s-master ~]# kubectl get secret
NAME TYPE DATA AGE
admin-token-bs4sg kubernetes.io/service-account-token 3 116s
default-token-pshvd kubernetes.io/service-account-token 3 10d
[root@k8s-master ~]# kubectl describe secret admin-token-bs4sg
Name: admin-token-bs4sg
Namespace: default
Labels: <none>
Annotations: kubernetes.io/service-account.name: adminkubernetes.io/service-account.uid: 7a2db3d5-84eb-4339-a8cd-4b95115f4688Type: kubernetes.io/service-account-tokenData
====
ca.crt: 1025 bytes
namespace: 7 bytes
token: eyJhbGciOiJSUzI1NiIsImtpZCI6IlJYY0FNa3lvdjVtNERqbzJzVzlJM2RTa2dZQ3pxSnI5NDFxUFZHRk9zbGsifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImFkbWluLXRva2VuLWJzNHNnIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6ImFkbWluIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQudWlkIjoiN2EyZGIzZDUtODRlYi00MzM5LWE4Y2QtNGI5NTExNWY0Njg4Iiwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50OmRlZmF1bHQ6YWRtaW4ifQ.xTyQ9ZJFgQkbQx0TLpuueku2DkQc49S3DP8E_3fDqHES615cBaGof-HU77daywO7YW4vRxTk0MGIvPDarnh04gYH37ZSqUGWAF4uJNjrXsKVjly7sq7o-iS_nJef-1zWxr7FBKYjYMbRobMYHPwMdguz4GBK2S9C9IYCzpifo1ERm36WbA7gA6b6ylET8x_5zbORBhNm7FUDBRbpXLGXCyHlA2o6batMc2cAwHog0hIWYZ0HPvZkSjl7E2uIKiG8QefApdgDgck2jWztSyvBB6QGA8buGcIevws4I78GfGA9hgq0tzPuDTHNdFSAkCY4J3lirdQwKT84yWsgqQg4Rw3、K8s API调用
认证即进入大门，授权即确认可以对资源进行哪些操作，所以API调用需要两点：1、调用资源时需要携带证书或者token等鉴权信息；2、注明请求的API接口地址
token我们已经拿到了，API接口以获取busybox的pod信息为例，利用v=7查看
[root@k8s-master ~]# kubectl get po -v=7
I1120 17:34:32.083451 89976 loader.go:375] Config loaded from file: /root/.kube/config
I1120 17:34:32.088355 89976 round_trippers.go:420] GET https://192.168.0.121:6443/api/v1/namespaces/default/pods?limit=500
I1120 17:34:32.088372 89976 round_trippers.go:427] Request Headers:
I1120 17:34:32.088377 89976 round_trippers.go:431] Accept: application/json;as=Table;v=v1beta1;g=meta.k8s.io, application/json
I1120 17:34:32.088386 89976 round_trippers.go:431] User-Agent: kubectl/v1.16.1 (linux/amd64) kubernetes/d647ddb
I1120 17:34:32.099754 89976 round_trippers.go:446] Response Status: 200 OK in 11 milliseconds
NAME READY STATUS RESTARTS AGE
busybox-5d7b4b65d6-mk6c6 1/1 Running 1 42hhttps://192.168.0.121:6443/api/v1/namespaces/default/pods?limit=500
就是需要请求的API接口
curl: (35) Peer reports incompatible or unsupported protocol version.curl 不兼容或不支持的协议版本centos系统解决方法：yum update -y nss curl libcurl
利用：curl -k -H "Authorization: Bearer+空格+token+空格+API请求地址"调用成功
[root@k8s-master ~]# curl -k -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IlJYY0FNa3lvdjVtNERqbzJzVzlJM2RTa2dZQ3pxSnI5NDFxUFZHRk9zbGsifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImFkbWluLXRva2VuLWJzNHNnIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6ImFkbWluIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQudWlkIjoiN2EyZGIzZDUtODRlYi00MzM5LWE4Y2QtNGI5NTExNWY0Njg4Iiwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50OmRlZmF1bHQ6YWRtaW4ifQ.xTyQ9ZJFgQkbQx0TLpuueku2DkQc49S3DP8E_3fDqHES615cBaGof-HU77daywO7YW4vRxTk0MGIvPDarnh04gYH37ZSqUGWAF4uJNjrXsKVjly7sq7o-iS_nJef-1zWxr7FBKYjYMbRobMYHPwMdguz4GBK2S9C9IYCzpifo1ERm36WbA7gA6b6ylET8x_5zbORBhNm7FUDBRbpXLGXCyHlA2o6batMc2cAwHog0hIWYZ0HPvZkSjl7E2uIKiG8QefApdgDgck2jWztSyvBB6QGA8buGcIevws4I78GfGA9hgq0tzPuDTHNdFSAkCY4J3lirdQwKT84yWsgqQg4Rw" https://192.168.0.121:6443/api/v1/namespaces/default/pods?limit=500
{"kind": "PodList","apiVersion": "v1","metadata": {"selfLink": "/api/v1/namespaces/default/pods","resourceVersion": "61327"},"items": [{"metadata": {"name": "busybox-5d7b4b65d6-mk6c6","generateName": "busybox-5d7b4b65d6-","namespace": "default","selfLink": "/api/v1/namespaces/default/pods/busybox-5d7b4b65d6-mk6c6","uid": "7a06c495-bd70-4816-9845-3bd2db69ec7f","resourceVersion": "43135","creationTimestamp": "2021-11-18T14:38:38Z","labels": {"app": "busybox","pod-template-hash": "5d7b4b65d6"},"ownerReferences": [{"apiVersion": "apps/v1","kind": "ReplicaSet","name": "busybox-5d7b4b65d6","uid": "8f36b9d4-9fb2-4642-97da-1dbad70809c3","controller": true,"blockOwnerDeletion": true}]},。。。。。这篇关于逃脱只会部署集群系列 —— k8s集群认证、授权、安全控制的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
