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