🚵 ♓️ 🚟 头盔安全 👰🏽 👨🏿‍🎓 🏷️

可以通过表情符号来表达关于Kubernetes最受欢迎的软件包管理器的故事的本质：

盒子是头盔（这是最新发布的表情符号中最合适的）；
锁-安全性；
人是解决问题的方法。

实际上，一切都会有些复杂，而且故事中充满了有关如何使Helm安全的技术细节。

简而言之，如果您不知道或忘记了什么，Helm是什么。它可以解决什么问题以及它在生态系统中的位置。
考虑头盔的架构。在不了解组件的体系结构的情况下，没有一个关于安全性以及如何使工具或解决方案更安全的讨论。
让我们讨论头盔组件。
最紧迫的问题是未来-Helm 3的新版本。

本文中的所有内容都与Helm 2有关。此版本现已投入生产，很可能是您现在正在使用它，并且存在安全风险。

关于演讲者： Alexander Khayorov（ allexx ）已经发展了10年，致力于改善Moscow Python Conf ++的内容，并加入了Helm Summit委员会。目前在Chainstack担任开发主管一职-这是开发经理和负责最终版本交付的人员之间的混合体。就是说，它位于敌对行动现场，从产品生产到其运作，一切都在发生。

Chainstack是一个小型的，积极发展的初创企业，其开发团队位于新加坡，其任务是为客户提供机会，以省去基础架构和操作分散式应用程序的困难。不要要求Chainstack出售或购买加密货币，而要谈论企业区块链框架，他们将很乐意回答您。

头盔

这是Kubernetes的软件包管理器（图表）。将应用程序引入Kubernetes集群的最直观，最通用的方法。

当然，与创建自己的YAML清单和编写小型实用程序相比，这是一种更具结构性和工业性的方法。

头盔是目前最畅销和最受欢迎的头盔。

为什么要掌舵？主要是因为它受CNCF支持。 Cloud Native-一个大型组织，是Kubernetes，etcd，Fluentd等项目的母公司。

另一个重要事实，Helm是一个非常受欢迎的项目。当我在2019年1月正计划谈论如何使Helm安全时，该项目在GitHub上获得了千颗星。到五月，有1.2万。

许多人都对Helm感兴趣，因此，即使您仍然不使用它，也需要了解其安全性。 安全很重要。

Helm的核心团队受Microsoft Azure支持，因此与许多其他项目相比，这是一个相当稳定的项目。 7月中旬发布了Helm 3 Alpha 2，这表明很多人都在从事该项目，他们渴望并有能力开发和改进Helm。

Helm解决了Kubernetes中的几个根应用程序管理问题。

应用程序包装。甚至WordPress上的“ Hello，World”之类的应用程序已经包含了几种服务，我想将它们打包在一起。
管理这些应用程序的管理所带来的复杂性。
在安装或部署应用程序后不会结束的生命周期。它继续存在，需要更新，Helm为此提供帮助，并正在尝试为此采取正确的措施和政策。

包装的组织方式易于理解：存在与Linux，Windows或MacOS常规软件包管理器的工作完全一致的元数据。也就是说，一个存储库，取决于各种程序包，应用程序的元信息，设置，配置功能，信息索引等。所有这些Helm允许您获取和使用应用程序。

复杂性管理 。如果您有许多类似的应用程序，则需要参数化。模板随之而来，但是为了不采用自己的方式创建模板，可以直接使用Helm提供的功能。

应用程序生命周期管理 -在我看来，这是最有趣且尚未解决的问题。这就是为什么我适时来到Helm。我们需要监视应用程序生命周期，我们希望将CI / CD和应用程序周期转移到此范例中。

头盔允许您：

管理部署；介绍配置和修订的概念；
成功回滚；
为不同事件使用钩子；
添加其他应用程序检查并响应其结果。

此外，Helm还具有“电池” -大量美味的东西都可以以插件的形式包含在内，从而简化了您的生活。插件可以独立编写，它们非常隔离，不需要苗条的架构。如果您想实现某些功能，建议将其作为插件来实现，然后可以将其包含在上游。

舵基于三个主要概念：

图表回购 -清单的参数化描述和数组。
Config —即将要应用的值（文本，数值等）。
发布将最重要的两个组件放在一起，它们一起变成了发布。可以对发行版进行版本控制，从而实现生命周期的组织：安装时较小，而升级，降级或回滚时较大。

头盔架构

该图从概念上反映了Helm的高级体系结构。

让我提醒您，Helm与Kubernetes相关。因此，我们离不开Kubernetes集群（矩形）。 kube-apiserver组件位于向导中。没有头盔，我们有Kubeconfig。 Helm带来了一个小的二进制文件，也就是Helm CLI实用程序，该实用程序安装在计算机，笔记本电脑和大型机上-可以进行任何操作。

但这还不够。 Helm具有分iller服务器组件。他代表了Helm在集群中的利益，它与Kubernetes集群中的应用程序一样，就像其他任何应用程序一样。

图表仓库的下一个组件是图表存储库。有一个正式的存储库，可能有一个公司或项目的私有存储库。

互动互动

让我们看看当我们想使用Helm安装应用程序时架构组件如何交互。

我们说Helm install ，转到存储库（图表回购）并获得Helm图表。

Helm实用程序（Helm CLI）与Kubeconfig交互以找出要联系的集群。
收到此信息后，该实用程序将转而使用Tiller（位于我们集群中）作为应用程序。
Tiller转向Kube-apiserver在Kubernetes中执行操作，以创建一些对象（服务，pod，副本，机密等）。

此外，我们将使该方案复杂化，以查看整个Helm体系结构可遭受的攻击向量。然后，我们将尝试保护她。

攻击向量

第一个潜在的弱点是特权用户 API 。作为该计划的一部分，这是一个黑客，他已获得对Helm CLI的管理员访问权限。

没有特权的API用户如果位于附近某处，也可能很危险。这样的用户将具有不同的上下文，例如，可以在Kubeconfig的设置中将他固定在群集的一个名称空间中。

最有趣的攻击媒介可能是位于群集中靠近Tiller的某个位置并且可以访问它的进程。它可以是查看群集网络环境的Web服务器或微服务。

Chart Repo关联了一种异国情调但越来越流行的攻击选项。由不道德的作者创建的图表可能包含不安全的资源，您将凭信心执行该资源。或者，它可以替换您从官方资源库下载的图表，例如，以策略的形式创建资源并提升访问权限。

让我们尝试从所有这四个方面对付攻击，并找出Helm体系结构中存在问题的地方，以及可能没有的地方。

让我们扩大方案，添加更多元素，但保留所有基本组件。

Helm CLI与Chart Repo进行通信，与Kubeconfig进行交互，将工作转移到Tiller组件中的集群。

分iller由两个对象表示：

Tiller-deploy svc，它提供某种服务；
分iller部署荚（在图上以一个副本的单个副本形式），它运行访问集群的整个负载。

对于交互，使用了不同的协议和方案。从安全的角度来看，我们最感兴趣的是：

Helm CLI访问图表存储库的机制：什么协议，是否存在身份验证以及可以执行哪些操作。
Helm CLI使用kubectl与Tiller通信的协议。这是安装在群集中的RPC服务器。
Tiller本身可用于集群中的微服务，并且可以与Kube-apiserver进行交互。

我们将按顺序讨论所有这些方向。

RBAC

如果未启用RBAC，则谈论Helm或群集中其他服务的任何安全性是没有用的。

看来这本身并不是一个新的建议，但是我敢肯定，到目前为止，甚至在生产中也没有包括RBAC，因为这引起了很大的争议，还有很多需要配置的地方。不过，我敦促做到这一点。

https://rbac.dev/是RBAC的律师网站。它收集了很多有趣的材料，这些材料将有助于建立RBAC，说明为什么它是好的，以及在生产中原则上如何使用它。

我将尝试解释Tiller和RBAC的工作方式。分iller在某个服务帐户下的群集内工作。通常，如果未配置RBAC，则它将是超级用户。在基本配置中，蒂勒将是管理员。这就是为什么人们常说Tiller是通向您群集的SSH隧道的原因。实际上就是这种情况，因此您可以使用单独的专用服务帐户代替上图中的默认服务帐户。

初始化Helm时，首先将其安装在服务器上，可以使用--service-account设置服务--service-account 。这将使您以最少的必要权限集使用用户。没错，您必须创建一个这样的“花环”：Role和RoleBinding。

不幸的是，Helm不会为您这样做。您或您的Kubernetes集群管理员需要预先为服务帐户准备一组Role，RoleBinding，以转移Helm。

问题是-Role和ClusterRole有什么区别？区别在于，ClusterRole对所有名称空间均有效，这与常规的Role和RoleBinding不同，后者仅适用于专用名称空间。您可以为整个群集和所有名称空间配置策略，也可以分别为每个名称空间进行个性化设置。

值得一提的是，RBAC解决了另一个大问题。许多人抱怨说，Helm不是多租户（不支持多租户）。如果多个团队使用一个集群并使用Helm，则原则上不可能配置策略并区分他们在该集群中的访问权限，因为存在一个服务帐户，Helm可以在该服务帐户下工作，并且可以从该帐户下创建集群中的所有资源。有时候很不舒服。的确如此-作为二进制文件本身， Helm Tiller作为一个进程并不了解多租户 。

但是，有一种很棒的方法可以在群集中多次运行Tiller。这没有问题； Tiller可以在每个名称空间中运行。因此，您可以将RBAC，Kubeconfig用作上下文，并限制对特殊头盔的访问。

它看起来如下。

例如，有两个带有不同团队上下文的Kubeconfig（两个命名空间）：X团队用于开发团队和管理集群。管理集群具有自己的扩展名Tiller，分别位于Kube系统名称空间和高级服务帐户中。为开发团队提供单独的命名空间，他们将能够在特殊的命名空间中部署服务。

这是一种可行的方法，Tiller并不是那么繁琐，以至于可能会大大影响您的预算。这是快速修复方法之一。

可以自由地单独配置Tiller，并为Kubeconfig提供团队，特定开发人员或环境的环境：开发，暂存，生产（将所有内容都放在同一个集群上是可疑的，但是可以做到）。

继续我们的故事，从RBAC切换到谈论ConfigMap。

配置图

Helm使用ConfigMaps作为数据仓库。当我们谈论体系结构时，没有地方存储有关版本，配置，回滚等信息的数据库，为此使用ConfigMaps。

ConfigMap的主要问题是已知的-原则上它们是不安全的， 不可能在其中存储敏感数据 。我们正在谈论不应超出服务范围的所有内容，例如密码。现在，Helm最原始的方法是从使用ConfigMap转变为秘密。

这非常简单。重新定义“ Tiller”设置，并指定存储将是秘密。然后，对于每个部署，您将不会收到ConfigMap，而是一个秘密。

您可能会争辩说，秘密本身是一个奇怪的概念，并且不是很安全。但是，值得理解的是Kubernetes的开发人员正在这样做。从版本1.10开始，即很久以前，至少在公共云中，有可能连接正确的存储来存储机密。现在，团队正在努力更好地分发对机密，个人提交或其他实体的访问权限。

最好将Storage Helm转换成秘密，然后再将它们集中保护。

当然， 数据存储的限制为1 MB 。 Helm在这里使用etcd作为ConfigMap的分布式存储库。他们在那里认为这是用于复制等的合适数据块。关于Reddit的话题对此进行了有趣的讨论，我建议您在周末找到这种有趣的阅读材料，或者在这里阅读这些内容。

图表回购

图表是社会上最容易受到伤害的图表，可能成为“中间人”的来源，尤其是在使用股票解决方案的情况下。首先，我们讨论的是通过HTTP公开的存储库。

当然，您需要通过HTTPS公开Helm Repo-这是最佳选择，而且价格便宜。

注意图表签名的机制。该技术很容易丢脸。这与您在GitHub上使用的东西相同，后者是具有公钥和私钥的常规PGP机器。进行设置并确保拥有必要的键并签署所有内容，这实际上就是您的图表。

此外， Helm客户端支持TLS （不是服务器端的HTTP，而是双向TLS）。您可以使用服务器和客户端密钥进行通信。坦白地说，由于不喜欢相互证书，因此我不使用这种机制。原则上， chartmuseum （Helm 2的主要Helm Repo曝光工具）也支持基本身份验证。如果更方便，更安静，则可以使用基本身份验证。

还有一个helm-gcs插件，可让您在Google Cloud Storage上托管Chart Repos。因为使用了所有描述的机制，所以这非常方便，有效并且非常安全。

如果启用HTTPS或TLS，使用mTLS，连接基本身份验证以进一步降低风险，您将获得一个安全的通讯通道Helm CLI和Chart Repo。

gRPC API

下一步非常负责-保护Tiller，该Tiller在群集中，一方面是服务器，另一方面，它访问其他组件，并尝试以某人的身份进行自我介绍。

就像我说的那样，Tiller是公开gRPC的服务，Helm客户端通过gRPC来访问它。当然，默认情况下，TLS是关闭的。为什么要这样做是一个有争议的问题，在我看来，从一开始就简化了设置。

为了生产甚至进行升级，我建议在gRPC上启用TLS。

在我看来，与用于图表的mTLS不同，这在这里很合适，并且非常简单-生成PQI基础结构，创建证书，启动Tiller，在初始化期间传输证书。之后，您可以执行所有似乎已生成的证书和私钥的Helm命令。

因此，您可以保护自己免受集群外部对Tiller的所有请求。

因此，我们确保了与Tiller的连接通道，已经讨论了RBAC，并调整了Kubernetes apiserver的权限，减少了它可以与之交互的域。

保护头盔

让我们看一下最终的图。这是具有相同箭头的相同体系结构。

现在，所有连接都可以安全地涂成绿色：

对于Chart Repo，我们使用TLS或mTLS和基本身份验证；
用于Tiller的mTLS，它作为带有TLS的gRPC服务公开，我们使用证书；
群集使用具有Role和RoleBinding的特殊服务帐户。

我们明显地保护了群集，但是聪明的人说：

“只有一个绝对安全的解决方案-关闭计算机，它在一个混凝土盒子里，并由士兵保护着。”

有多种方法可以操纵数据并找到新的攻击媒介。但是，我相信这些建议将使基本的行业安全标准得以实施。

红利

这部分与安全性没有直接关系，但也将很有用。我将向您展示一些鲜为人知的有趣事情。例如，如何查找图表-官方和非官方。

github.com/helm/charts存储库现在具有约300个图表和两个流：稳定和孵化器。贡献者知道从孵化器到稳定器有多难，以及从稳定器中飞出是多么容易。但是，这不是搜索Prometheus图表的最佳工具，并且由于一个简单的原因，您喜欢的所有内容都不是方便搜索软件包的门户。

但是有一个hub.helm.sh服务，使用它可以更方便地查找图表。最重要的是，还有更多的外部存储库，并且有将近800个图表。另外，如果由于某些原因您不想将图表发送到稳定状态，则可以连接存储库。

尝试hub.helm.sh，让我们一起开发它。该服务在Helm项目下，如果您是前端供应商并且只想改善外观，您甚至可以在其UI中提供帮助。

我还想引起您对Open Service Broker API集成的注意 。听起来很麻烦而且难以理解，但是它解决了每个人都面临的问题。我将用一个简单的例子来解释。

有一个Kubernetes集群，我们要在其中运行经典应用程序-WordPress。通常，完整功能需要数据库。有许多不同的解决方案，例如，您可以启动全状态服务。这不是很方便，但是很多都可以。

像我们在Chainstack一样，其他公司也使用托管数据库（例如MySQL或PostgreSQL）作为服务器。因此，我们的数据库位于云中的某个位置。

但是出现了一个问题：您需要将我们的服务与数据库连接，创建风味数据库，传递凭据并以某种方式进行管理。所有这些通常由系统管理员或开发人员手动完成。当应用程序很少时也没有问题。如果数量很多，则需要结合使用。有这样的结合-这就是Service Broker。它允许您使用特殊的插件来访问公共云集群，并通过Broker从提供程序订购资源，就好像它是一个API。您可以为此使用本地Kubernetes工具。

这很简单。例如，您可以使用基本层（可以自定义）在Azure中查询托管MySQL。使用Azure API，将创建基础并准备使用。您无需干预，插件对此负责。例如，OSBA（Azure插件）将凭据返回给服务，并将其传递给Helm。您可以将WordPress与多云的MySQL结合使用，完全不处理托管数据库，也不必担心内部的全状态服务。

可以说Helm充当了胶水，一方面使您可以部署服务，另一方面却消耗了云提供商的资源。

您可以编写自己的插件并使用整个本地故事。然后，您只有自己的企业云提供商插件。我建议您尝试这种方法，特别是如果您规模庞大并且想要快速部署功能的开发，登台或整个基础结构时，尤其要这样做。这将使您的操作或DevOps的工作更加轻松。

我已经提到的另一个发现是helm-gcs插件 ，它允许您使用Google-buckets（对象存储）存储Helm图表。

仅需四个命令即可开始使用它：

安装插件；
启动它；
将路径设置为存储在gcp中的存储桶；
以标准方式发布图表。

优点是将使用用于授权的本机gcp方法。您可以使用服务帐户，也可以使用开发人员帐户。这非常方便，并且无需任何操作。如果您像我一样，提倡无忧无虑的哲学，那么这将非常方便，尤其是对于小型团队而言。

替代品

Helm不是唯一的服务管理解决方案。他有很多问题，这可能就是为什么第三版这么快出现的原因。当然，还有其他选择。

它可以作为专门的解决方案，例如Ksonnet或Metaparticle。您可以将经典的基础架构管理工具（Ansible，Terraform，Chef等）用于与我所讨论的相同的目的。

最后，还有一种运营商框架解决方案，其流行度正在增长。

操作员框架是您应注意的主要Helm替代方案。

它对于CNCF和Kubernetes来说更原生， 但是进入阈值更高 ，您需要更多的编程和更少的描述。

有各种附加组件，例如吃水，脚手架。它们极大地简化了生活，例如，开发人员简化了用于部署测试环境的发送和启动Helm的周期。我称他们为机会的延伸者。

这是位置的直观图。

在x轴上，您对正在发生的事情的个人控制级别，在y轴上，您在Kubernetes本地性级别上。 Helm版本2位于中间位置。在版本3中，它不是巨大的，但可控性和本地性级别都得到了改善。 Ksonnet级别的解决方案甚至不及Helm2。但是，值得一看的是，他们可以了解这个世界上还有什么。当然，您的配置管理器将在您的控制之下，但绝对不是Kubernetes的本机。

Operator Framework绝对是Kubernetes的本机框架，可让您更加优雅和细致地进行管理（但请记住入门级别）。而是，它适合于专用应用程序并为其创建管理，而不是适合使用Helm打包大量应用程序的批量收割机。

扩展程序只是简单地改善了控制能力，补充了工作流程或简化了CI / CD管道的工作。

头盔的未来

好消息是，Helm 3正在出现，Helm 3.0.0-alpha.2的Alpha版本已经发布，您可以尝试。它相当稳定，但功能仍然有限。

为什么需要头盔3？首先，这是Tiller消失的故事。正如您已经了解的那样，这是向前迈出的一大步，因为从架构安全性的角度来看，一切都得到了简化。

在Kubernetes 1.8或更早版本中创建头盔2时，许多概念还不成熟。例如，正在积极实施CRD的概念，Helm将使用CRD来存储结构。可以仅使用客户端，而不保留服务器端。因此，请使用本地Kubernetes命令来处理结构和资源。这是向前迈出的一大步。

将显示对本机OCI存储库的支持 （开放容器计划）。这是一项巨大的举措，Helm的主要兴趣在于发布其图表。举例来说，Docker Hub支持许多OCI标准。我并不奇怪，但是也许经典的Docker仓库提供者将开始为您提供机会为您放置其Helm图表。

对我来说，一个有争议的故事是Lua作为编写脚本的模板引擎的支持 。我不是Lua的忠实拥护者，但这将是一个完全可选的功能。我检查了3次-不需要使用Lua。因此，任何想要使用Lua的人，喜欢Go的人，都可以加入我们的庞大阵营并为此使用go-tmpl。

, — . int string, . JSONS-, values.

event-driven model . . Helm 3, , , , , .

Helm 3 , , Helm 2, Kubernetes . , Helm Kubernetes Kubernetes.

, DevOpsConf , ? , , 30 1 . 20 DevOps-.

telegram- .

头盔安全

头盔