Kubernetes安全:远不止眼前所见
这个博客是在Rimas的Mocevicius博客
Kubernetes安全性的演变
在Kubernetes的早期基于角色的访问控制(RBAC)引入了在Kubernetes集群中运行的pod，在分配服务帐户时具有完全的管理权限。基本上，这给了用户对集群的完全管理权限。想象一下那有多可怕?不要误解我的意思，这段时间很有趣，可以看看Kubernetes安全性是如何随着时间的推移而演变出基于角色的身份验证等。
那么，为什么我们喜欢憎恨Helm 's Tiller呢?
然后舵的舵柄出现时,Kubernetes包管理器，使我们的生活更容易打包，发布和升级应用程序。一切都很好，直到RBAC发布，迫使我们在Helm服务器端将管理角色分配给Tiller。每个人都开始抱怨蒂勒对集群拥有太多的权力。人们的反应各不相同。有些人完全停止使用Helm with Tiller，而另一些人则使用RBAC规则在每个名称空间中锁定多个Tiller，这使得设置非常难以维护。另一个开始使用头盔模板管道输出kubectl．这导致发布了许多舵面包装器，以简化跨多个名称空间的舵面/舵面版本的管理。
这是我发表Tillerless舵博客文章，并建议使用一个安全的方法运行舵与舵。基本上，您可以在集群外部运行Tiller和Helm CLI，同时在kubecconfig中为用户集分配升级释放权限(与Helm CLI和kubectl使用它的方式相同)。基本上，这应该排序Helm/Tiller问题，直到Helm v3发布，你可能已经听说将没有Tiller!
Kubernetes操作员和控制器安全吗?
操作符和控制器是Kubernetes API的扩展。Operator是特定于应用程序的控制器，允许您创建、配置和管理复杂的应用程序实例。领先运算符的例子包括普罗米修斯和PostgreSQL。通过使用控制器，您可以通过观察Kubernetes API对象(如名称空间、部署或pod或您自己的自定义资源定义(CRD))生成的事件来基于内部逻辑开发工作流。
操作员和控制器共享与Helm 's Tiller相同的部署原则，并需要向集群授予完全的管理权限，例如在以下情况下:
- 设置PostgreSQL操作符以跨所有名称空间管理数据库集群。
- 锁定特定的命名空间。
- 为每个命名空间运行一个PostgreSQL操作符。
- 运行简单的自定义控制器。
因此，我想到的问题是，为什么社区没有对运营商和控制员的安全威胁提出严重破坏?
Kubernetes的自定义控制器怎么样?
每个人都喜欢使用控制器和操作符，但讨厌使用Tiller，实际上，Tiller是一个自定义控制器。Kubernetes自定义控制器允许您通过观察Kubernetes API对象中的事件来开发自己的自定义业务逻辑。GitOps是weeworks引入的一种使用Pull请求运行Git操作的持续交付方法。普遍的共识是Git被定义为真理的中心来源。我200%同意这一点，因为它允许你拥有提交历史，并始终跟踪你的发布。
在Kubernetes集群中有很多工具使用自定义控制器来监视git repo中的变化，并使用helm或kubectl推出新版本。他们在实现GitOps方面确实做得很好。例如，git存储库观察变化很酷，但需要完全管理权限为了将更改部署到所有名称空间或运行多个控制器，每个名称空间一个控制器以使其更加安全和包含。听起来是不是很熟悉?
保护控制器和操作符的最佳实践
- 当使用操作符时，你没有太多选择，因为它们必须运行在部署PostgreSQL集群的同一个集群中。我们建议在多租户环境中对每个名称空间运行操作符。
- 您不必为了更新或扩展应用程序而在集群中运行Tiller或自定义控制器。不要担心给集群API太多的访问，或者锁定每个名称空间，然后有维护许多分蘖/控制器的负担和浪费的计算资源。2022世界杯阿根廷预选赛赛程
使用专用CI/CD集群的老式方法可以很好地完成这项工作。如果没有适当的安全措施，不要将它暴露在外部。在安装或升级时，管道应该根据应用程序需求使用不同的kubecconfig文件，不要忘记将kubectl、Helm和Tiller作为管道的一部分。 - 不存储或硬编码默认密码在你的舵图中因为你可能会忘记，并在以后的阶段有安全漏洞的风险。我创建了一个简单的Helm插件helm-linter这可以帮助您在图表的值中找到硬编码的密码。yaml文件。请随意使用，并欢迎反馈和pr。
