逃脱只会部署集群系列 —— k8s集群认证、授权、安全控制

本文主要是介绍逃脱只会部署集群系列 —— 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:身份认证

    1. 这个环节它面对的输入是整个http request,负责对来自client的请求进行身份校验,支持的方法包括:

      • basic auth(基本废弃)

      • client证书验证(https双向验证)

      • jwt token(用于serviceaccount)

    2. APIServer启动时,可以指定一种Authentication方法,也可以指定多种方法。如果指定了多种方法,那么APIServer将会逐个使用这些方法对客户端请求进行验证, 只要请求数据通过其中一种方法的验证,APIServer就会认为Authentication成功;

    3. 使用kubeadm引导启动的k8s集群,apiserver的初始配置中,默认支持client证书验证和serviceaccount两种身份验证方式。 证书认证通过设置--client-ca-file根证书以及--tls-cert-file--tls-private-key-file来开启。

    4. 在这个环节,apiserver会通过client证书或 http header中的字段(比如serviceaccount的jwt token)来识别出请求的用户身份,包括”user”、”group”等,这些信息将在后面的authorization环节用到。

  • 2、Authorization:鉴权,你可以访问哪些资源

    1. 这个环节面对的输入是http request context中的各种属性,包括:usergrouprequest path(比如:/api/v1/healthz/version等)、 request verb(比如:getlistcreate等)。

    2. APIServer会将这些属性值与事先配置好的访问策略(access policy)相比较。APIServer支持多种authorization mode,包括Node、RBAC、Webhook等。

    3. 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文件然后拷贝的。

       现在讲解下 Kuberneteskube-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 ClusterRoleDefault ClusterRoleBindingDescription
system:kube-schedulersystem:kube-scheduler userAllows access to the resources required by the schedulercomponent.
system:volume-schedulersystem:kube-scheduler userAllows access to the volume resources required by the kube-scheduler component.
system:kube-controller-managersystem:kube-controller-manager userAllows access to the resources required by the controller manager component. The permissions required by individual controllers are detailed in the controller roles.
system:nodeNoneAllows 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-proxiersystem:kube-proxy userAllows 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 created

2、查看创建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_5zbORBhNm7FUDBRbpXLGXCyHlA2o6batMc2cAwHog0hIWYZ0HPvZkSjl7E2uIKiG8QefApdgDgck2jWztSyvBB6QGA8buGcIevws4I78GfGA9hgq0tzPuDTHNdFSAkCY4J3lirdQwKT84yWsgqQg4Rw

3、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集群认证、授权、安全控制的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/477987

相关文章

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

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

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备份方案,通过工具容器执行mysqldump,结合定时任务实... 目录前言一、获取需要备份的数据库的信息二、备份步骤1.准备工作(X86)1.准备工作(arm)2.手

MySQL 用户创建与授权最佳实践

《MySQL用户创建与授权最佳实践》在MySQL中,用户管理和权限控制是数据库安全的重要组成部分,下面详细介绍如何在MySQL中创建用户并授予适当的权限,感兴趣的朋友跟随小编一起看看吧... 目录mysql 用户创建与授权详解一、MySQL用户管理基础1. 用户账户组成2. 查看现有用户二、创建用户1. 基

Web技术与Nginx网站环境部署教程

《Web技术与Nginx网站环境部署教程》:本文主要介绍Web技术与Nginx网站环境部署教程,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录一、Web基础1.域名系统DNS2.Hosts文件3.DNS4.域名注册二.网页与html1.网页概述2.HTML概述3.

Nginx使用Keepalived部署web集群(高可用高性能负载均衡)实战案例

《Nginx使用Keepalived部署web集群(高可用高性能负载均衡)实战案例》本文介绍Nginx+Keepalived实现Web集群高可用负载均衡的部署与测试,涵盖架构设计、环境配置、健康检查、... 目录前言一、架构设计二、环境准备三、案例部署配置 前端 Keepalived配置 前端 Nginx

ubuntu如何部署Dify以及安装Docker? Dify安装部署指南

《ubuntu如何部署Dify以及安装Docker?Dify安装部署指南》Dify是一个开源的大模型应用开发平台,允许用户快速构建和部署基于大语言模型的应用,ubuntu如何部署Dify呢?详细请... Dify是个不错的开源LLM应用开发平台,提供从 Agent 构建到 AI workflow 编排、RA

ubuntu16.04如何部署dify? 在Linux上安装部署Dify的技巧

《ubuntu16.04如何部署dify?在Linux上安装部署Dify的技巧》随着云计算和容器技术的快速发展,Docker已经成为现代软件开发和部署的重要工具之一,Dify作为一款优秀的云原生应用... Dify 是一个基于 docker 的工作流管理工具,旨在简化机器学习和数据科学领域的多步骤工作流。它

Nginx部署React项目时重定向循环问题的解决方案

《Nginx部署React项目时重定向循环问题的解决方案》Nginx在处理React项目请求时出现重定向循环,通常是由于`try_files`配置错误或`root`路径配置不当导致的,本文给大家详细介... 目录问题原因1. try_files 配置错误2. root 路径错误解决方法1. 检查 try_f

Redis高可用-主从复制、哨兵模式与集群模式详解

《Redis高可用-主从复制、哨兵模式与集群模式详解》:本文主要介绍Redis高可用-主从复制、哨兵模式与集群模式的使用,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝... 目录Redis高可用-主从复制、哨兵模式与集群模式概要一、主从复制(Master-Slave Repli