k8s中各组件和kube apiserver通信时的认证和鉴权问题怎么解决

这篇文章主要介绍“k8s中各组件和kubeapiserver通信时的认证和鉴权问题怎么解决”，在日常操作中，相信很多人在k8s中各组件和kubeapiserver通信时的认证和鉴权问题怎么解决问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”k8s中各组件和kubeapiserver通信时的认证和鉴权问题怎么解决”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！和master节点kube api-server通信的组件有很多，包括：kubeletcalicoschedulerkubectl某些pod可能会和kube api-server通信这些组件和api-server通信时用的是什么身份，可以操作哪些api资源呢？本文使用的k8s集群是用kubekey搭建，命令是./kk create cluster –with-kubernetes v1.21.5 –with-kubesphere v3.2.1kubectl默认会用到.kube/config配置，其中包含证书信息可以看到这个证书的CN是kubernetes-admin，O是system:masters。根据文档可以知道，这表示证书代表的用户是kubernetes-admin，用户组是system:masters。那这个证书代表的用户能操作哪些资源呢？这个需要看”用户kubernetes-admin”、”用户组system:masters”在集群中绑定了什么”角色”。可以看到它绑定了”ClusterRole/cluster-admin”，这个角色可以对所有资源做任意操作。可以通过kubectl get ClusterRole/cluster-admin -o yaml查看角色的权限。所以，.kube/config证书中代表的用户身份可以对所有资源做任意操作。在master节点上查看scheduler进程，可以”大胆猜测”用的是/etc/kubernetes/scheduler.conf中的证书信息。在我的k8s环境中，kube-scheduler是运行在pod中的，不过pod和宿主机的/etc/kubernetes/scheduler.conf文件是一样的查看证书的Subject信息，可以看到用户是system:kube-scheduler可以看到”用户system:kube-scheduler”绑定了两个角色。在worker节点上可以看到kubelet进程参数，api-server信息在/etc/kubernetes/kubelet.conf文件中可以看到是通过证书认证的查看证书的Subject信息，可以知道证书代表的”用户”是”system:node:ip-172-31-14-204″，”用户组”是”system:nodes”那这个kubelet的证书代表的用户能操作哪些资源呢？它可以用来像”集群管理员”那样创建pod吗？按照之前流程，我们来看一下”用户system:node:ip-172-31-14-204″、”用户组system:nodes”在集群中绑定了什么”角色”。会发现”用户和用户组”没有绑定任何一个角色，这和kubectl、kube-scheduler就很不一样了。在 使用Node鉴权 文档中提到，kube apiserver对kubelet的鉴权比较特殊。当发现请求的用户在system:nodes组中，用户名是system:node:时，就限制这个请求只能做有限的操作，比如读操作servicespod绑定到当前node的pod的secret、configMap写操作（如果开启了NodeRestriction准入插件，就只能修改kubelet所在node的资源）创建节点、修改节点状态创建pod、pod状态似乎如果没有开启NodeRestri免费云主机域名ction准入插件，就能让kubelet在任意node上创建pod。红蓝对抗中，如果能让kubelet在任意node上创建pod，就能用来横移文档中写到，这里的能力可能随着k8s版本变化而变化，以确保kubelet最小权限，默认安全。所以，kubelet到底能操作哪些资源，感觉还是来测试一下比较好，下面就来验证一下kubelet的权限。我们先用kubelet配置文件覆盖kubectl的默认配置，然后就可以用kubectl命令来验证。可以看到不能够创建pod查看pod信息是可以的查看secret和configMap是不允许的小结：kubelet证书可以用来查看pod信息，不能创建pod、不能查看所有命名空间的secret和configMap。看起来和文档中的说明一致。可以看到用的是token令牌。这个token令牌是一个jwt字符串，base64解码后的payload部分如下，可以看到”ServiceAccount”是calico-node，命名空间是kube-system可以看到，这个”ServiceAccount”被绑定到了”ClusterRole/calico-node”角色。大部分pod会挂载一个token在/var/run/secrets/kubernetes.io/serviceaccount/token位置，这个token也是一个jwt字符串。base64解码后，payload中也能看到一个服务账号ServiceAccount，这个ServiceAccount也有可能和一个”角色”绑定。你可以动手查看一下自己的pod。到此，关于“k8s中各组件和kubeapiserver通信时的认证和鉴权问题怎么解决”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注百云主机网站，小编会继续努力为大家带来更多实用的文章！

相关推荐: 怎么用vue写一个轮播图

本篇内容主要讲解“怎么用vue写一个轮播图”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“怎么用vue写一个轮播图”吧!1.先展示最终效果：2.解决免费云主机域名思路Vue的理念是以数据驱动视图，所以拒绝通过改变元素…