【问题标题】:Kubernetes - Do I need to some additional hardening steps?Kubernetes - 我需要一些额外的强化步骤吗?
【发布时间】:2019-03-26 20:40:20
【问题描述】:

基本上我是 kubernetes 的新手,我正在尝试创建一个简单的 nginx + php-fpm 应用程序。我已经设置了部署配置,创建了 Pod,设置了一些负载均衡器等。一切正常,我正在从 Google Cloud Shell 控制集群(因为集群是在 Google Cloud Platform 上创建的)。我想问一下我是否需要做一些额外的步骤,或者我的集群是否安全可靠,例如:有人可以通过某种方式从外部连接到它等等。我在创建集群时保留了默认设置和我启用了客户端证书(这是一种身份验证方式,对吗?)。我只是想确定一下。 (默认情况下应该是安全的吗?)

【问题讨论】:

  • 你能把你的问题说得更具体一点吗?现在,它可能会帮助您在线进行一些研究并找出您想知道的内容。
  • 是的,我会对此进行一些研究,但它现在也应该是安全的,不是吗? (它不像是不安全的,对吧?)
  • 如果担心节点外部IP,可以考虑使用私有集群。但是,我目前正在默认 GKE 集群上部署多个 nginx、php-fpm 应用程序,不得不抱怨。我建议您查看您的集群设计,您可能希望与外部工具保持密封连接。如果您分享您的基础设施,这将有助于我更好地为您提供帮助。
  • 嗯,“基础设施”是什么意思?

标签: kubernetes google-kubernetes-engine


【解决方案1】:

考虑一下你到底在“强化”什么;您可以从两个上下文考虑安全性:应用程序和集群。它们通常是分离的,但如果其中任何一个受到损害,都可能导致一些严重的问题。

对于集群安全,GKE 上有许多选项可以限制对涵盖大多数用例的集群的访问。您可以使用RBAC(基于角色的访问控制)来限制用户和服务帐户的权限,并防止对您的集群资源进行未经授权的访问/修改。此外,如果您使用外部工具(例如 Helm),则需要单独保护这些工具。默认情况下,只有拥有客户端证书的人才能访问您的主服务器。如果您共享证书,或者您的 Google Organizations 帐户中的其他用户拥有访问您的集群的 IAM 权限,他们也可以从 Google Cloud CLI 获取权限。良好的集群安全实施可以大大减轻受损容器/pod 的影响。

为了应用程序安全,请遵循部署容器化应用程序和机密管理的最佳做法。基本上像在传统服务器上一样保护您的 nginx 和 php。

希望这会有所帮助!

【讨论】:

  • 我正在强化“集群安全”,所以如果我保持这样的集群并确保我对任何人隐藏证书并且有人获得了集群的 IP 地址(在外部互联网中)它应该是安全的,除非我共享客户端证书或有人进入我的 Google Cloud Platform 帐户,否则没有人可以连接到它,我理解正确吗?通过连接到集群,我的意思是有人连接到它,例如使用 kubectl 并控制某些东西..
  • 对于 GKE 集群,它应该足够健壮,可以满足您希望完成的任务;在使用 Helm/Tiller 等外部工具时要小心。你的理解是正确的。
  • 是的,我不使用任何外部工具。
猜你喜欢
  • 2021-08-25
  • 2014-11-05
  • 1970-01-01
  • 2021-03-07
  • 1970-01-01
  • 1970-01-01
  • 2021-04-15
  • 2013-03-08
  • 2010-09-08
相关资源
最近更新 更多