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