kubernetes各组件通信路径与安全

63 阅读 0 评论 42 点赞

我是靠谱客的博主时尚汽车，最近开发中收集的这篇文章主要介绍kubernetes各组件通信路径与安全，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

本文将kubernetes master node与整个集群的通信路径分类，目的是使用户能够通过自定义安装强化网络配置，从而使集群运行在不受信任的网络之上，比如云供应商的全开放IP环境。通信路径分成两条：由master到集群、由集群到master。

cluster->master

所有从集群到master的通信路径终点都是apiserver，由kubernetes的安装部署可知道，其它控制面（master）全部都没有开放供其它组件访问的接口。一个典型的部署，apiserver被配置在安全的HTTPS端口（443）监听远程连接，同时可以使用多种被允许的认证方案对客户端进行身份认证。应该支持多种认证方案，特别是允许匿名请与service account token。

重要的一点，node要想通过安全连接访问apiserver，那么应该被提供根证书与可用的客户端证书。例如，在一个采用默认部署的GCE中，默认的客户端证书会提供给node上的kubelete。参考kubelet TLS bootstrapping实现kubelet客户端证书自动设置。

在pod内部想要安全的访问apiserver，需要给它提供一个service account，那么kubernetes在实例化pod时会自动的将根证书与可用的bearer token注入到实例化的pod中，kubernetes会为每个服务分配虚拟IP，最终通过kube-proxy的重定向指向apiserver的HTTPS endpoint。

同样所有的master上的组件都采用相同的方式与apiserver通信。

结果，apiserver是集群内部消息总线，所有其它组件与它的通信都是经过安全加密的，保证了在公网或者是不受信网络上的安全。

master->cluster

从master(apiserver)到集群的通信路径主要有两种：一条是从apiserver到集群每个node都运行的kubelet程序，这一条起的主要是控制流量。另一条是则是apiserver充当代理服务器时访问集群中任意node、pod、service的路径，这一条走的就是代理流量。

apiserver->kubelet

这一条路径主要用来：

从pod获取日志
启动pod
提供kubelet的端口转发功能

这种路径的终点是kubelet的HTTPS endpoint。默认情况下，apiserver不确认kubelet的身份，这使得apiserver在不安全的网络环境下容易受到中间人攻击。

如果想要认证kubelet身份的话，则需要为apiserver指定--kubelet-certificate-authority标志并提供根证书，这样的话apiserver就可以对kubelet的证书进行验证。

如果以上方案因某种原因不可行的话，也可以在kubelet与apiserver之间搭建SSH tunneling，实现在不安全的网络环境下建立安全通信的功能。

最后， Kubelet authentication and/or authorization 也应该被打开，以增强kubelet api的安全性。

apiserver -> nodes, pods, and services

首先，此时的apiserver充当的是外部访问集群内node、pod、service的代理。默认情况下apiserver访问这些资源时，使用的是HTTP，不认证身份也不加密通信通道。如果在通过apiserver代理访问内部资源时，如果在构造URL时，在node、pod、service等资源的名称前加上"https:"，那么apiserver访问这些资源时就会使用https协议。但是此时要注意，通信链路会加密，但是双方都不会验证证书的有效性，所以在不安全的网络环境中，这个路径是不安全的。