Kubernetes Operators的安全性影响

发布时间：

2023-10-13 13:01

在Kubernetes的早期版本中，Managing Resources是一个相对直接的过程，使用YAML标记来定义资源配置，然后将这些配置提交给集群。但后来发现，这需要太多人工处理，而且在操作层面效率太低，体验不佳。

Kubernetes演进的下一步是使用Helm Chart。有时被称为"Kubernetes的包管理器"，Helm允许开发人员使用模板语言共享整个应用程序设置。这使得共享配置变得容易，并允许我们方便地使用一个命令来部署应用程序。

但Helm是一个外部附加组件，其能力受限于我们可以通过现有的Kubernetes API实现的范围。因此，Kubernetes的下一步是通过Operators来扩展Kubernetes API，它使我们能够从集群内部添加自定义功能。

Kubernetes Operator是用于自动化以前需要人工操作的任务的工具。为了创建Kubernetes Operator，开发者需要编写自定义代码来与Kubernetes API进行交互，以自动管理应用程序的生命周期。这些自定义代码通常在集群中的一个或多个Pod中运行，但也可以通过适当的身份验证从集群外部与之交互。这使得Operators能够添加自定义功能并提供高级自动化管理。

在本文中，我们将查看一些适当的Operators权限范围示例，以及Operators创建者和终端用户在确保安全性方面的协作作用，以及使用Operators增强Kubernetes服务安全性的一些方法。

Kubernetes安全性与RBAC

要在Kubernetes集群中部署Kubernetes Operator，我们应该将Kubernetes的通用安全实践作为与Operator相关的考虑的基础。以下是这些通用性考虑的简要介绍。

Kubernetes中的主要权限系统是基于角色的访问控制（RBAC）授权，必须在启动集群时启用。它提供了额外的权限资源：Roles和RoleBindings，这些只适用于它们生效的命名空间范围；以及ClusterRoles和ClusterRoleBindings，这些适用于整个集群（只应在必要时使用）。

Roles定义了特权角色如何访问资源，而RoleBindings将用户或软件组件角色与Roles连接起来。与一般操作系统的安全性要求一样，只提供必要的权限并定期审查授予的权限以验证其是否仍然需要是很重要的运维措施。

以下是一个允许在指定的命名空间中读取Pod资源的角色示例：

apiGroups的空字符串表示核心API。为了匹配这一点，我们可以定义一个角色绑定，将这个角色分配给特定的用户帐户：

Operator 部署通常附带其自己的角色和绑定。用户应该特别检查这些角色和绑定，以确切了解第三方授予用户的集群权限。

范围和权限

Kubernetes Operator的安全性与一条信任链相关，该链涵盖了从创建者和存储库开始，一直延伸到Operator传递到用户集群的整个过程。与RBAC系统类似，限制Operator的权限需要尽可能的减少，但在使用过程中，Kubernetes Operator需要在集群中执行各种任务，因此它们通常需要较高级别的权限来完成这些任务。为了确保安全性，开发人员需要谨慎地权衡这些权限，以防止过度赋予权限，从而最小化潜在的安全风险

与角色和角色绑定类似，Operator可以在命名空间范围内或整个集群的所有命名空间中运行。将Kubernetes应用程序放置在它们各自独立的命名空间中有助于将它们与其他应用程序和Kubernetes系统隔离，提高安全性。

在可行的情况下，Operator开发者应选择命名空间范围的授权，以避免风险扩散到同一集群上的其他应用。如果Operator需要管理整个集群中的所有应用程序，则需要使用集群范围的Operator。

为了防止Pod和容器操纵Kubernetes系统，可以使用securityContexts，这也适用于Operator容器。以下是一个限制Pod权限的YAML片段示例：

我们假设此示例中的容器正在运行在其所操作的Kubernetes集群上。使用这个代码片段，我们可以防止进程获得root权限并修改其根文件系统。如果由于任何原因Operator被入侵，攻击者将受到相关执行和用户权限的限制。

接下来是定义集群范围的Pod安全限制。在Kubernetes版本1.21之前，我们可以使用PodSecurityPolicy (PSP) 对象来实现这一点。不过，它现在已经被弃用。它的继任者PodSecurityAdmission (PSA)，是Kubernetes版本1.23中的一个Beta功能。

但是这个新的PSA不允许像上面示例中的YAML那样具有同样精细的自定义控制。相反，我们可以选择应用于每个命名空间的三个新定义的策略级别：privileged、baseline和restricted。

在这个示例中，我们的命名空间被配置为强制执行中级基线安全级别，并在适当命名的受限级别下发出警告。有关这些策略的确切定义在Kubernetes关于Pod安全标准的文档中列出。

Kubernetes Operators的安全和好处

尽管Kubernetes Operators引入了一些安全性考虑，但它们也可以增强集群的安全性。正如前面讨论的那样，Kubernetes Operators执行通常由人工操作员执行的操作和配置，而人工操作员可能会犯错误，这是常见的。由程序执行的配置和控制更可靠且可重复，相对于由人工操作员执行的操作来说更为稳定。

当Operators被正确编写时，它们可以消除疏忽甚至恶意错误。响应速度也是安全性的重要因素。在警报和解决问题方面，软件Operators相对于人工操作员具有显著的优势。

大多数部署到集群中的操作都涉及到日常应用程序的运维，但也可以将专门的安全管理服务部署到集群中。最好由Operators中的控制循环来指导这些服务。