Kubernetes 安全最佳实践：保护您的秘密

Kubernetes 是一个可用于微服务的开源容器编排平台。当我们想要部署容器化应用程序、自动化管理和扩展应用程序时，Kubernetes 非常有用。

在容器中运行单个微服务而不是在同一虚拟机中运行多个进程几乎总是更安全。每当我们在 Kubernetes 中启动任何 pod 时，该 pod 都会托管在节点内。Kubernetes 中有两种类型的节点可用。第一个是Master节点，第二个是Worker节点。应用程序代码在集群内部的工作节点中运行。工作节点托管 Pod 并将资源报告发送给主节点。顾名思义，主节点是所有工作节点的主节点，工作节点是主节点的从节点。Master节点和Worker节点共同组成一个集群。

什么是 Kubernetes 安全性？

Kubernetes主要搞云环境，包括集群、容器、云和代码。本质上，代码、集群和容器的结合关系到 Kubernetes 的安全性。因此，特性包括云环境中的容器安全、集群安全、访问控制和应用安全，围绕这些特性构建 Kubernetes 集群安全。

经常扫描整个系统以识别漏洞和错误配置，以立即确保系统安全。此外，Kubernetes API 和 Pod 容器安全性是 Kubernetes 安全性的重要方面，这对于商业安全解决方案来说是必需的，使 Kubernetes 具有弹性和可扩展性，并包含有价值的信息。

Kubernetes 安全吗？

众所周知，组织正在向云迈进，这里的云指的是 Kubernetes。Kubernetes 在行业中的使用正在增加。根据云原生计算基金会 (CNCF) 的最新年度调查，83% 的组织使用 Kubernetes。在这 83% 的组织中，23% 的组织使用超过 11 个 Kubernetes 集群进行生产。

随着 Kubernetes 使用的增加，与 Kubernetes 集群相关的安全问题和担忧也迅速增加。红帽企业对 500 名 DevOps 专业人员进行了调查，以检查 Kubernetes 的安全性和采用情况。该调查得出以下结论：

• 大约 94% 的 DevOps 专业人员至少报告过一起安全事件。
• 由于安全问题，其中 54% 推迟了应用程序的发布。
• 大约 59% 的人表示，安全性是使用 Kubernetes 集群最大的担忧。

Kubernetes 安全最佳实践：4C 安全模型

在为 Kubernetes 安全创建纵深防御策略时，必须安装各种安全措施。即使是相同的方法也被云原生安全性所遵循和推荐。云原生系统将其安全态势和技术分为四层。以下是这四层：

4C 安全模型分别代表云、集群、容器和代码。从开发阶段开始到部署阶段结束，我们上面提到的所有四个层都为所涉及的所有步骤提供了安全性。

使用这个 4C 安全模型，我们将分别讨论这四个层的 Kubernetes 安全最佳实践。让我们从云层开始一一讨论 Kubernetes 安全最佳实践。

云

云层代表服务器基础设施。当我们在任何云服务提供商（CSP）上设置服务器时，都会涉及到各种服务。云服务提供商处理管理操作系统、平台和网络等服务，但消费者仍然负责保护和监控数据。

防火墙和加密

“Secrets”对象在 Kubernetes 中用于存储或保存敏感数据或信息。这里，敏感数据可以是任何用户名、密码、令牌、密钥和其他必要数据。秘密可以帮助我们减少潜在的攻击面。Pod 可以访问私有数据，因为秘密为 Pod 生命周期提供了灵活性。为了网络安全，我们需要监控网络流量。防火墙还可以识别潜在的不安全流量。对秘密资源进行加密至关重要，因此 Kubernetes 支持加密。

需要注意的一件事是 etcd 配置文件的加密。这很重要，因为该文件在 Kubernetes 的 API 服务器级别以简单的纯文本格式存储。加密文件的好处是，即使攻击者获得了对 etcd 文件的读写访问权限，他也无法理解任何内容。要解密 etcd 文件，需要加密密钥来加密该文件。只有 API 服务器中存储有加密密钥。

建议启用防火墙规则、监控活动网络流量并仅启用本地端口。在控制平面，也称为主节点，必须开放的端口有6443、2379、2380、10250、8472等一些端口。对于工作节点，也有一些端口。分别是 10250、10255 和 8472。

阻止访问 Kube API 服务器

Kubernetes API 访问控制过程涉及三个步骤。以下是这三个步骤：

• 请求访问已验证。
• 真实性有保证。
• 传递到准入控制进行访问。

在身份验证操作开始之前，将适当检查 TLS 连接和网络访问控制设置。认证过程有时可能会很复杂或复杂。

为了控制平面和 Kubelet 之间的通信、与控制平面的内部通信或与 API 服务器的连接，只能使用 TLS 连接。我们可以使用 Kube-API 服务器命令行将 TLS 证书和 TLS 私钥文件发送到 API 服务器。

出于通信目的，Kubernetes API 使用两个 HTTP 端口。第一个端口是本地端口，第二个端口是安全端口。本地端口不执行任何请求的身份验证和授权，因为它不需要任何传输层身份验证提供程序或安全连接。因此，确保本地端口在 Kubernetes 集群外部无法访问或开放就变得更加关键。

此外，由于存在安全漏洞的可能性，服务帐户应尽快接受全面审核，特别是当它们链接到用于专门 Kubernetes 管理任务的特定命名空间和服务帐户令牌时。每个应用程序都应该有其唯一的服务帐户，而不是使用默认的服务帐户。

本节将详细讨论保持 Kubernetes 集群安全的方法。让我们分别简要地研究一下所有的方法。

应用最小访问权限

Kubernetes 为其元素提供了一些基本的安全性，例如授权。因此，要访问集群组件，您需要登录，以便您访问集群组件或集群节点的请求获得授权。在这里，我们可以使用基于角色的访问控制（RBAC）。使用 RBAC，我们可以声明哪个实体可以使用 Kubernetes API 在特定资源上执行特定活动。它是 Kubernetes API 身份验证限制访问的最佳、最有效的方法之一。还建议启用审核日志记录以提高安全性。

Kubernetes API

为了做出任何授权决策，RBAC 授权使用rbac.authorization.k8s.io API 组。它可以根据需要进行策略更改。RBAC 激活涉及在将权限标志设置为包含 RBAC 的逗号分隔列表后重新启动 API 服务器。

kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options

请考虑以下示例。它只是提供 pod 供读取，作为“默认”命名空间中的角色。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata: 

 namespace: default  
 name: read-user
rules:
 - apiGroups: [""]  
   resources: ["pods"]  
   verbs: ["get", "watch", "list"]

使用准入控制器和网络策略

在 Kubernetes 容器编排系统中，准入控制器插件强制执行集群的治理和使用。准入控制器可以捕获经过身份验证的 API 请求并更改或拒绝它们。因此，他们也被称为守门人。

准入控制器可以通过在整个集群中强制执行适当的 Pod 安全策略和状态来提高安全性。内置 Pod 安全策略准入控制器就是这种情况的一个合适示例。除此之外，它还可以用来阻止容器以 root 身份运行或保证根文件系统始终以只读方式安装。

容器

在集群环境中，容器使用容器运行时引擎运行。Kubernetes 最常见的容器运行时环境是 Docker。它还附带了各种映像，程序员可以使用它们来设置从 Linux 到 Nginx 服务器的任何内容。

使用经过验证的图像来避免不需要的向量获得访问权限

为了避免易受攻击的镜像，必须扫描所有容器镜像，并且只允许那些遵循或符合组织策略的容器镜像。这是因为组织更容易受到此类安全风险的影响。众所周知，大部分代码通常取自开源项目，因此扫描图像是否存在安全漏洞并遵循组织制定的网络策略变得更加重要。对于所有容器镜像，容器注册表是中央存储库。您应该避免在容器映像本身中加载不需要的内核模块。

私有注册表应用作容器注册表，而不是公共注册表，因为公共注册表的安全性低于远程注册表。只有通过组织的网络策略验证的图像才必须存储在私有注册表中。这样，我们可以通过减少易受攻击的映像的使用来减少组织操作系统的攻击面。

扫描图像的过程也可以安装在CI管道中。这里，CI代表持续集成。让我们看看什么是图像扫描。在此过程中，系统会扫描映像中的 CVE、漏洞或不良做法。由于它安装在 CI/CD 管道中，因此漏洞无法到达注册表。它还可以防止由于使用第三方图像而导致的管道漏洞。

限制应用程序权限

支持在运行容器时使用 root 权限的最有力论据之一是需要防止权限升级。root 用户可以在系统上运行不同的命令，就像 root 用户可以在容器系统中运行任何命令一样。对于 root 用户来说命令执行变得非常容易。这给不良行为者带来了困难，即使他们以某种方式获得了访问权限。

软件包的安装方法、用户的创建、服务的启动以及其他此类活动都需要进行充分的审查。这可能会给应用程序开发人员带来不同的挑战。我们还应该避免在虚拟机上以 root 用户身份运行应用程序，以防止安全风险。容器也会发生同样的情况。除 root 之外的任何其他用户都不应具有写入权限。

如果容器被破坏，根用户将有权访问并能够在底层主机上运行任何操作系统命令，就像以根用户身份登录一样。这会带来危险，包括：-

• 可以访问文件系统挂载
• 还可以访问其他云资源
• 访问用于连接其他资源的凭据。（我们应该使用密码管理器来避免这种情况）
• 恶意软件可以安装在主机操作系统上。

代码

尽管我们可能在容器中运行各种应用程序，但有时我们将代码层称为应用程序安全性。此外，企业最能控制的是传输层安全。由于您的应用程序及其关联的数据库通常对互联网开放，因此如果所有其他组件都受到保护，攻击者将集中尝试攻击系统的这一部分。

扫描漏洞

大多数应用程序软件本质上依赖于库、其他第三方组件和开源包。因此，其中任何一个的漏洞肯定会影响整体性能。因此，您当前使用的程序很可能包含漏洞。

实施 Kubernetes 安全最佳实践

在本节中，我们将讨论 Kubernetes 安全最佳实践在不同领域的实施。

资源管理

为了执行容器，每个 Pod 都可以使用各种资源，包括内存和 CPU。因此，声明 Pod 时需要指定每个容器必须分配多少资源。

安全上下文

容器和 Pod 具有安全上下文，解释它们的权限和访问控制设置。自主访问控制 (DAC) 需要根据用户 ID（容器的基本术语）授权渗透某个项目。

环境安全更新

当容器承受各种开源软件和其他软件时，有可能稍后发现安全漏洞。最终，跟上软件更新并扫描图像以查看是否发现并修补了任何漏洞至关重要。此外，还可以使用 Kubernetes 的滚动更新功能升级到平台上的最新版本，从而改进正在运行的应用程序的安全工具。

左移方法

Kubernetes 在设计时不会立即将网络策略应用到 pod。包含 Pod 的容器几乎是不可更改的，这意味着它们会被调度。或者，当它们不可用时，它们会被重新部署和销毁。

因此，通过左移测试可以快速识别和解决容器生命周期中的缺陷，从而更有效地管理容器。

Kubernetes 中如何处理安全性？

Kubernetes 中的安全性是通过 RBAC（基于角色的访问控制）、网络策略、容器运行时安全性以及定期更新来解决漏洞等功能进行管理的。

Kubernetes 存在安全风险吗？

Kubernetes 本身并不存在安全风险，但配置错误、网络访问和控制不足以及部署不当可能会引入安全漏洞。

如何保护 Kubernetes 集群的安全？

为了保护 Kubernetes 集群的安全，需要实施强大的访问控制、启用审核日志记录、频繁轮换基础设施凭证、使用网络策略、采用容器运行时安全性并定期进行安全审核。