我使用以下命令创建了GKE私有集群(版本:1.13.6-gke.13 ):
gcloud container clusters create a-cluster-with-user-pass \
--network vpc-name \
--subnetwork subnet-name \
--enable-master-authorized-networks \
--username random \
--password averylongpassword \
--enable-ip-alias \
--enable-private-nodes \
--enable-private-endpoint \
--master-ipv4-cidr xxx.xx.xx.xx/28 \
--cluster-version 1.13.6-gke.13 \
--num-nodes 2 \
--zone asia-south1-a
我可以看到在上述集群中创建的两个节点(或者可以说GCP计算实例)中的端口(10255)都是开放的。
如果我创建一个简单的GCP计算实例(因此我总共有3个VM实例),并尝试从此VM访问10255端口上GKE节点的内部IP,则无需任何身份验证或授权即可访问它。 以下是用于创建GCP计算实例的命令:
gcloud compute instances create vm-name \
--network vpc-name \
--subnetwork subnet-name \
--zone asia-south1-a
如果我向( xxx.xx.xx.xx:10255 / pods )发送一个简单的CURL GET请求,我将获得大量有关Pod和应用程序的信息。 正如我在Kubernetes here的文档中看到的那样,提到了:
--read-only-port int32
The read-only port for the Kubelet to serve on with no authentication/authorization (set to 0 to disable) (default 10255)
我尝试通过执行kube-config.yaml
编辑节点中的ssh
文件并重新启动kubelet来禁用端口,我成功了。但这是一个好方法吗?我相信禁用 xxx.xx.xx.xx:10255 / metrics 时可能会出现多个问题。有没有办法保护端口?而不是禁用它?
我看到了这个github issue,并且我肯定有一种保护此端口的方法。我不确定该怎么做。
我看到Kubernetes文档总体上为我们提供了多种保护端口的方法。如何在Google Kubernetes Engine中做到这一点?
答案 0 :(得分:3)
Kubelet正在使用此端口公开收集的节点指标。未能公开这些指标可能会导致意外行为,因为系统本质上将是盲目的。
由于GKE是受管系统,因此您实际上不应该调整kubelet标志,因为在重新创建节点时将重置设置(节点基于GCE模板,其中不包括您自己的配置)。>
关于安全性,我认为将端口保留为原样是安全的,因为您使用的是私有群集,这意味着仅允许同一VPC中的资源访问这些节点。
答案 1 :(得分:1)
根据CIS Google Kubernetes Engine (GKE) Benchmark v1.0.0第196和197页的“建议”>“ Kubelet”:
readOnlyPort
设置为0
,然后重新启动kubelet
服务来实现此目的与此同时,Google mentions(第4.2.4点)指出,由于以下原因,默认情况下未禁用该端口:
某些GKE监视组件使用kubelet只读端口来获取指标。
?
CIS基准的建议是聋哑的,几乎毫无价值。
privileged
运行的守护进程,其唯一目的是覆盖GKE的kubelet配置?)我认为,最好的缓解方法是:
答案 2 :(得分:0)
正如YahirHernández在他的回答中建议的那样,该端口用于公开与确保平稳运行的系统有关的度量。禁用此端口可能不是一个好主意。
我们需要做的是防止从VPC外部访问此端口。
由于您在GCP上使用GKE。如果使用的是VPC,则可以将防火墙规则添加到端口(10255),以仅允许来自VPC上资源的传入流量。禁止从互联网访问此端口。