Kubernetes 安全速查表

概述

本速查表提供了保护 Kubernetes 集群的起点。它分为以下类别：

• 接收 Kubernetes 更新警报
• 引言：什么是 Kubernetes？
• 保护 Kubernetes 主机安全
• 保护 Kubernetes 组件安全
• 使用 Kubernetes 控制台
• Kubernetes 安全最佳实践：构建阶段
• Kubernetes 安全最佳实践：部署阶段
• Kubernetes 安全最佳实践：运行时阶段

有关 Kubernetes 的更多信息，请参阅附录。

接收安全更新和漏洞报告的警报

加入 kubernetes-announce 群组（https://kubernetes.ac.cn/docs/reference/issues-security/security/）以获取安全公告邮件。有关如何报告漏洞的更多信息，请参阅安全报告页面（https://kubernetes.ac.cn/docs/reference/issues-security/security）。

引言：什么是 Kubernetes？

Kubernetes 是一个开源容器编排引擎，用于自动化容器化应用程序的部署、扩展和管理。该开源项目由云原生计算基金会 (CNCF) 托管。

当您部署 Kubernetes 时，您会获得一个集群。Kubernetes 集群由一组工作机器（称为节点）组成，这些机器运行容器化应用程序。控制平面管理集群中的工作节点和 Pod。

控制平面组件

控制平面的组件对集群做出全局决策，并检测和响应集群事件。它由 kube-apiserver、etcd、kube-scheduler、kube-controller-manager 和 cloud-controller-manager 等组件组成。

组件： kube-apiserver
描述： 暴露 Kubernetes API。API 服务器是 Kubernetes 控制平面的前端。

组件： etcd
描述： 一个一致且高可用的键值存储，用作 Kubernetes 所有集群数据的后端存储。

组件： kube-scheduler
描述： 监视新创建的但未分配节点的 Pod，并为它们选择一个运行节点。

组件： kube-controller-manager
描述： 运行控制器进程。逻辑上，每个控制器是一个单独的进程，但为了降低复杂性，它们都被编译成一个单一的二进制文件并在一个进程中运行。

组件： cloud-controller-manager
描述： 云控制器管理器允许您将集群链接到云提供商的 API，并将与该云平台交互的组件与仅与您的集群交互的组件分离。

节点组件

节点组件在每个节点上运行，维护运行中的 Pod 并提供 Kubernetes 运行时环境。它由 kubelet、kube-proxy 和容器运行时等组件组成。

组件： kubelet
描述： 在集群中每个节点上运行的代理。它确保容器在 Pod 中运行。

组件： kube-proxy
描述： 在集群中每个节点上运行的网络代理，实现了 Kubernetes Service 概念的一部分。

容器： 运行时
描述： 容器运行时是负责运行容器的软件 |

第 1 节：保护 Kubernetes 主机安全

Kubernetes 可以通过多种方式部署：在裸机上、本地数据中心内以及在公共云中（在虚拟机上自定义构建 Kubernetes 或使用托管服务）。由于 Kubernetes 旨在高度可移植，客户可以轻松迁移其工作负载并在多个安装之间切换。

由于 Kubernetes 可以设计用于各种场景，这种灵活性在保护 Kubernetes 集群安全方面却是一个弱点。负责部署 Kubernetes 平台的工程师必须了解其集群的所有潜在攻击向量和漏洞。

为了强化 Kubernetes 集群的基础主机，我们建议您安装最新版本的操作系统，加固操作系统，实施必要的补丁管理和配置管理系统，实施基本的防火墙规则，并采取特定的数据中心安全措施。

更新 Kubernetes

由于没有人能够追踪您 Kubernetes 集群的所有潜在攻击向量，因此首要且最佳的防御措施是始终运行最新稳定版 Kubernetes。

如果发现运行中的容器存在漏洞，建议始终更新源镜像并重新部署容器。尽量避免直接更新运行中的容器，因为这可能会破坏镜像与容器的关系。

Example: apt-update

借助 Kubernetes 的滚动更新功能，升级容器变得极其简单——这允许通过将其镜像升级到最新版本来逐步更新运行中的应用程序。

Kubernetes 发布计划

Kubernetes 项目维护最近三个次要版本的发布分支，并根据严重性和可行性将适用的修复程序（包括安全修复程序）反向移植到这些发布分支。补丁发布会定期从这些分支中发布，必要时还会发布额外的紧急版本。因此，始终建议将 Kubernetes 集群升级到最新可用的稳定版本。建议查阅版本偏差策略以获取更多详细信息：https://kubernetes.ac.cn/docs/setup/release/version-skew-policy/。

有多种技术，如滚动更新和节点池迁移，可让您以最小的中断和停机时间完成更新。

--

第 2 节：保护 Kubernetes 组件安全

本节讨论如何保护 Kubernetes 组件。它涵盖以下主题：

• 保护 Kubernetes 控制台安全
• 限制对 etcd 的访问（重要）
• 控制对敏感端口的网络访问
• 控制对 Kubernetes API 的访问
• 在 Kubernetes 中实施基于角色的访问控制
• 限制对 Kubelet 的访问

--

保护 Kubernetes 控制台安全

Kubernetes 控制台是一个用于管理集群的 Web 应用程序。它不是 Kubernetes 集群本身的一部分，必须由集群所有者安装。因此，有很多关于如何操作的教程。不幸的是，其中大多数教程都会创建一个具有非常高权限的服务帐户。这导致特斯拉和其他一些公司通过配置不当的 K8s 控制台被黑客攻击。（参考：特斯拉云资源被入侵运行加密货币挖矿恶意软件 - https://arstechnica.com/information-technology/2018/02/tesla-cloud-resources-are-hacked-to-run-cryptocurrency-mining-malware/）

为防止通过控制台进行攻击，您应该遵循以下一些建议：

• 不要在没有额外认证的情况下将控制台暴露给公共网络。没有必要从局域网外部访问如此强大的工具。
• 启用基于角色的访问控制（见下文），以便您可以限制控制台使用的服务帐户。
• 不要授予控制台的服务帐户过高的权限。
• 按用户授予权限，这样每个用户只能看到他们应该看到的内容。
• 如果您正在使用网络策略，您可以阻止甚至来自内部 Pods 对控制台的请求（这不会影响通过 kubectl proxy 的代理隧道）。
• 在 1.8 版本之前，控制台有一个拥有完全权限的服务帐户，因此请检查是否没有剩余的 cluster-admin 角色绑定。
• 部署控制台时，应使用支持多因素认证的认证反向代理。这可以通过嵌入式 OIDC id_tokens 或使用 Kubernetes 模拟来实现。这允许您使用用户的凭据访问控制台，而不是使用特权 ServiceAccount。此方法可用于本地部署和托管云集群。

--

限制对 etcd 的访问（重要）

etcd 是一个关键的 Kubernetes 组件，它存储状态和秘密信息，应与集群的其余部分区别对待进行保护。对 API 服务器的 etcd 具有写入权限相当于获得整个集群的根权限，即使是读取权限也可以相当容易地用于权限提升。

Kubernetes 调度器将在 etcd 中搜索没有节点的 Pod 定义。然后它将找到的 Pod 发送到一个可用的 kubelet 进行调度。提交的 Pod 的验证由 API 服务器在写入 etcd 之前执行，因此直接写入 etcd 的恶意用户可以绕过许多安全机制，例如 PodSecurityPolicies。

管理员应始终使用从 API 服务器到 etcd 服务器的强凭据，例如通过 TLS 客户端证书进行相互认证，并且通常建议将 etcd 服务器隔离在只有 API 服务器才能访问的防火墙后面。

限制对主 etcd 实例的访问

允许集群内其他组件以读写权限访问完整键空间的主 etcd 实例，相当于授予集群管理员访问权限。强烈建议为其他组件使用单独的 etcd 实例，或者使用 etcd ACL 限制对键空间子集的读写访问。

--

控制对敏感端口的网络访问

强烈建议在集群和集群节点上配置认证和授权。由于 Kubernetes 集群通常监听一系列定义明确且独特的端口，攻击者更容易识别并攻击这些集群。

下面提供了 Kubernetes 中使用的默认端口概述。请确保您的网络阻止了对这些端口的访问，并且您应该认真考虑将对 Kubernetes API 服务器的访问限制在受信任的网络中。

控制平面节点

协议	端口范围	用途
TCP	6443	Kubernetes API 服务器
TCP	2379-2380	etcd 服务器客户端 API
TCP	10250	Kubelet API
TCP	10259	kube-scheduler
TCP	10257	kube-controller-manager
TCP	10255	只读 Kubelet API

工作节点

协议	端口范围	用途
TCP	10248	Kubelet Healthz API
TCP	10249	Kube-proxy Metrics API
TCP	10250	Kubelet API
TCP	10255	只读 Kubelet API
TCP	10256	Kube-proxy Healthz API
TCP	30000-32767	NodePort 服务

--

控制对 Kubernetes API 的访问

Kubernetes 对抗攻击者的第一道防线是限制和保护对 API 请求的访问，因为这些请求用于控制 Kubernetes 平台。欲了解更多信息，请参考文档：https://kubernetes.ac.cn/docs/reference/access-authn-authz/controlling-access/。

此部分包含以下主题：

• Kubernetes 如何处理 API 授权
• Kubernetes 外部 API 认证（推荐）
• Kubernetes 内置 API 认证（不推荐）
• 在 Kubernetes 中实施基于角色的访问控制
• 限制对 Kubelet 的访问

--

Kubernetes 如何处理 API 授权

在 Kubernetes 中，您的请求必须经过身份验证（登录）才能获得授权（被授予访问权限），并且 Kubernetes 期望 REST API 请求中常见的属性。这意味着现有的组织范围或云提供商范围的访问控制系统（可能处理其他 API）可与 Kubernetes 授权配合使用。

当 Kubernetes 使用 API 服务器授权 API 请求时，权限默认是拒绝的。它根据所有策略评估所有请求属性，并允许或拒绝该请求。API 请求的所有部分都必须被某个策略允许才能继续执行。

--

Kubernetes 外部 API 认证（推荐）

由于 Kubernetes 内部 API 认证机制的弱点，我们强烈建议大型或生产集群使用外部 API 认证方法之一。

• OpenID Connect (OIDC) 允许您外部化认证、使用短期令牌并利用集中式组进行授权。
• GKE、EKS 和 AKS 等托管 Kubernetes 发行版支持使用其各自 IAM 提供商的凭据进行身份验证。
• Kubernetes 模拟可用于托管云集群和本地集群，以外部化认证，而无需访问 API 服务器配置参数。

除了选择合适的认证系统外，API 访问应被视为特权操作，并对所有用户访问启用多因素认证 (MFA)。

有关更多信息，请查阅 Kubernetes 认证参考文档：https://kubernetes.ac.cn/docs/reference/access-authn-authz/authentication。

--

Kubernetes 内置 API 认证选项（不推荐）

Kubernetes 提供了多种用于 API 服务器认证的内部机制，但这些机制通常只适用于非生产或小型集群。我们将简要讨论每种内部机制，并解释为什么不应该使用它们。

• 静态令牌文件：认证使用存储在 API 服务器节点上 CSV 文件中的明文令牌。警告：在此文件中的凭证无法修改，直到 API 服务器重新启动。

• X509 客户端证书可用，但不适用于生产环境，因为 Kubernetes 不支持证书吊销。因此，这些用户凭证无法在不轮换根证书颁发机构密钥并重新颁发所有集群证书的情况下进行修改或吊销。

• 服务帐户令牌也可用作身份验证。它们的主要目的是允许在集群中运行的工作负载向 API 服务器进行身份验证，但它们也可以用于用户身份验证。

--

在 Kubernetes 中实施基于角色的访问控制

基于角色的访问控制 (RBAC) 是一种根据组织内单个用户的角色来管理对计算机或网络资源访问的方法。幸运的是，Kubernetes 带有一个集成的基于角色的访问控制 (RBAC) 组件，其中包含默认角色，允许您根据客户端可能要执行的操作来定义用户职责。您应该将 Node 和 RBAC 授权器与 NodeRestriction 准入插件结合使用。

RBAC 组件将传入的用户或组与一组链接到角色的权限进行匹配。这些权限将动词（获取、创建、删除）与资源（Pod、服务、节点）结合起来，并且可以是命名空间范围或集群范围的。RBAC 授权使用 `rbac.authorization.k8s.io` API 组来驱动授权决策，允许您通过 Kubernetes API 动态配置策略。

要启用 RBAC，请启动 API 服务器，并将 `--authorization-mode` 标志设置为包含 RBAC 的逗号分隔列表；例如：

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

有关使用 RBAC 的详细示例，请参阅 Kubernetes 文档：https://kubernetes.ac.cn/docs/reference/access-authn-authz/rbac

--

限制对 Kubelet 的访问

Kubelet 暴露 HTTPS 端点，这些端点授予对节点和容器的强大控制权。默认情况下，Kubelet 允许未经身份验证的访问此 API。生产集群应启用 Kubelet 认证和授权。

有关更多信息，请参阅 Kubelet 认证/授权文档：https://kubernetes.ac.cn/docs/reference/access-authn-authz/kubelet-authn-authz/

--

第 3 节：Kubernetes 安全最佳实践：构建阶段

在构建阶段，您应该通过构建安全的镜像并扫描这些镜像是否存在已知漏洞来保护您的 Kubernetes 容器镜像。

--

什么是容器镜像？

容器镜像 (CI) 是一个不可变、轻量级、独立的、可执行的软件包，其中包含运行应用程序所需的一切：代码、运行时、系统工具、系统库和设置 [https://dockerd.com.cn/resources/what-container]。每个镜像都共享宿主机中操作系统的内核。

您的容器镜像 (CI) 必须基于经批准且安全的基层镜像构建。此基层镜像必须定期扫描和监控，以确保所有容器镜像都基于安全可靠的镜像。实施强有力的治理策略，以确定如何在受信任的镜像仓库中构建和存储镜像。

--

确保容器镜像 (CI) 是最新的

确保您的镜像（以及您包含的任何第三方工具）是最新的，并使用其组件的最新版本。

--

仅在您的环境中使用授权镜像

从未知来源下载和运行容器镜像 (CI) 非常危险。请确保只允许运行符合组织策略的镜像，否则组织将面临运行易受攻击甚至恶意容器的风险。

--

使用 CI 流水线控制和识别漏洞

Kubernetes 容器注册表充当系统中所有容器镜像的中央存储库。根据您的需求，您可以使用公共存储库或私有存储库作为容器注册表。我们建议您将批准的镜像存储在私有注册表中，并且只将批准的镜像推送到这些注册表，这会自动将进入您的流水线的潜在镜像数量从数十万个公开可用镜像中减少到一小部分。

此外，我们强烈建议您添加一个 CI 流水线，将安全评估（例如漏洞扫描）集成到构建过程中。此流水线应审查所有批准用于生产并用于构建镜像的代码。镜像构建完成后，应对其进行安全漏洞扫描。只有在没有发现问题的情况下，镜像才会被推送到私有注册表，然后部署到生产环境。如果安全评估机制未能通过任何代码，它应该在流水线中创建一个故障，这将帮助您发现存在安全问题的镜像并阻止它们进入镜像注册表。

许多源代码仓库提供扫描功能（例如 Github、GitLab），并且许多 CI 工具提供与开源漏洞扫描器（例如 Trivy 或 Grype）的集成。

项目正在为 Kubernetes 开发镜像授权插件，以防止未经授权的镜像部署。有关更多信息，请参阅 PR：https://github.com/kubernetes/kubernetes/pull/27129。

--

最小化所有容器镜像 (CI) 中的功能

作为一种最佳实践，谷歌和其他科技巨头多年来一直严格限制其运行时容器中的代码。这种方法提高了扫描器（例如 CVE）的信噪比，并减少了建立来源的负担，只保留您需要的内容。

考虑使用最小化的容器镜像 (CI)，例如 distroless 镜像（见下文）。如果无法做到，请不要在容器镜像中包含操作系统包管理器或 shell，因为它们可能存在未知漏洞。如果您绝对必须包含任何操作系统包，请在生成过程的后续步骤中移除包管理器。

--

尽可能使用 distroless 或空镜像

Distroless 镜像显著减少了攻击面，因为它们不包含 shell 且比其他镜像包含更少的软件包。有关 distroless 镜像的更多信息，请参阅：https://github.com/GoogleContainerTools/distroless。

空镜像，非常适合像 Go 这样静态编译的语言，因为镜像为空——攻击面真正最小化——只有您的代码！

有关更多信息，请参阅：https://hub.docker.com/_/scratch

---

第 4 节：Kubernetes 安全最佳实践：部署阶段

一旦 Kubernetes 基础设施就位，您必须在部署任何工作负载之前对其进行安全配置。在配置基础设施时，请确保您对正在部署的容器镜像 (CI) 以及它们的部署方式有可见性，否则您将无法识别和响应安全策略违规行为。在部署之前，您的系统应该知道并能够告诉您：

• 正在部署什么——包括有关所用镜像的信息，例如组件或漏洞，以及将要部署的 Pod。
• 将部署到何处——哪些集群、命名空间和节点。
• 如何部署——是否以特权模式运行，可以与哪些其他部署通信，以及是否应用了 Pod 安全上下文。
• 可以访问什么——包括秘密、卷以及其他基础设施组件，例如主机或编排器 API。
• 是否合规？——是否符合您的策略和安全要求。

--

使用命名空间隔离 Kubernetes 资源的代码

命名空间使您能够创建逻辑分区，强制隔离资源并限制用户权限的范围。

--

为请求设置命名空间

要为当前请求设置命名空间，请使用 `--namespace` 标志。请参考以下示例：

kubectl run nginx --image=nginx --namespace=<insert-namespace-name-here>
kubectl get pods --namespace=<insert-namespace-name-here>

--

设置命名空间偏好

您可以使用以下命令在该上下文中永久保存所有后续 `kubectl` 命令的命名空间：

kubectl config set-context --current --namespace=<insert-namespace-name-here>

然后使用以下命令进行验证：

kubectl config view --minify | grep namespace:

有关命名空间的更多信息，请访问：https://kubernetes.ac.cn/docs/concepts/overview/working-with-objects/namespaces

--

使用 ImagePolicyWebhook 管理镜像来源

我们强烈建议您使用准入控制器 `ImagePolicyWebhook` 来阻止使用未经批准的镜像，拒绝使用未经批准镜像的 Pods，并拒绝符合以下条件的容器镜像 (CI)：

• 近期未扫描过的镜像
• 使用未明确允许的基层镜像的镜像
• 来自不安全注册表的镜像

了解更多关于 webhook 的信息，请访问：https://kubernetes.ac.cn/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook

--

实施持续安全漏洞扫描

由于新漏洞不断被发现，您可能无法总是了解您的容器是否包含最新披露的漏洞 (CVE) 或过时的软件包。为了保持强大的安全态势，请定期对第一方容器（您已构建并先前扫描过的应用程序）以及第三方容器（来自受信任的仓库和供应商）进行生产环境扫描。

ThreatMapper 等开源项目可以帮助识别和优先处理漏洞。

--

将安全上下文应用于您的 Pod 和容器

安全上下文是在部署 yaml 中定义的一个属性，它控制所有 Pod/容器/卷的安全参数，并且应该在您的整个基础设施中应用。当安全上下文属性在所有地方都正确实施时，它可以消除依赖特权访问的整个类别的攻击。例如，如果您在安全上下文中指定只读根文件系统，任何依赖于安装软件或写入文件系统的攻击都将被阻止。

当您为 Pod 配置安全上下文时，仅授予资源在您的容器和卷中运行所需的特权。安全上下文属性中的一些重要参数是：

安全上下文设置

1. SecurityContext->runAsNonRoot
   描述：指示容器应以非 root 用户身份运行。

2. SecurityContext->Capabilities
   描述：控制分配给容器的 Linux 功能。

3. SecurityContext->readOnlyRootFilesystem
   描述：控制容器是否能够写入根文件系统。

4. PodSecurityContext->runAsNonRoot
   描述：阻止容器作为 Pod 的一部分以“root”用户身份运行 |

安全上下文示例：包含安全上下文参数的 Pod 定义

apiVersion: v1

kind: Pod
metadata:
  name: hello-world
spec:
  containers:
  # specification of the pod’s containers
  # ...
  # ...
  # Security Context
  securityContext:
    readOnlyRootFilesystem: true
    runAsNonRoot: true

有关 Pods 安全上下文的更多信息，请参阅文档：https://kubernetes.ac.cn/docs/tasks/configure-pod-container/security-context

--

持续评估容器使用的权限

我们强烈建议您的所有容器都应遵循最小特权原则，因为您的安全风险受到授予容器的能力、角色绑定和特权的严重影响。每个容器都应仅具有执行其预期功能所需的最小特权和能力。

利用 Pod 安全标准和内置 Pod 安全准入控制器来强制执行容器权限级别

Pod 安全标准与 Pod 安全准入控制器结合使用，允许集群管理员对 Pod 的 securityContext 字段强制执行要求。存在三种 Pod 安全标准配置文件：

• 特权 (Privileged)：无限制，允许已知的权限提升。旨在用于需要特权才能正常运行的系统和基础设施级别工作负载。允许所有 `securityContext` 设置。
• 基线 (Baseline)：旨在用于常见容器化工作负载的最低限制性策略，同时防止已知的权限提升。面向非关键应用程序的开发人员和操作人员。最危险的 `securityContext` 设置（例如 `securityContext.privileged`、`hostPID`、`hostPath`、`hostIPC`）是不允许的。
• 受限 (Restricted)：最严格的策略，旨在强制执行当前的 Pod 强化实践，但可能会牺牲一些兼容性。适用于安全关键型工作负载或不受信任的用户。受限策略包含基线策略中的所有强制措施，此外还有更严格的要求，例如要求删除所有功能、强制执行 `runAsNotRoot` 等。

每个配置文件都有明确的设置基线，可以在此处找到更详细的信息。

Pod 安全准入控制器允许您在违反定义策略时进行强制执行、审计或警告。audit 和 warn 模式可用于确定当设置为 enforce 模式时，特定的 Pod 安全标准是否通常会阻止 Pod 的部署。

下面是一个命名空间的示例，该命名空间只允许部署符合受限 Pod 安全标准的 Pod：

apiVersion: v1
kind: Namespace
metadata:
  name: policy-test
  labels:    
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

集群管理员应妥善组织并强制执行集群命名空间上的策略，仅在绝对必要时（例如对于需要访问底层主机的关键集群服务）才允许特权策略。命名空间应设置为可强制执行并支持其风险级别的最低 Pod 安全策略。

如果需要超越这三种配置文件（特权、基线、受限）的更精细的策略强制执行，可以使用第三方准入控制器，如 OPA Gatekeeper 或 Kyverno，或内置的验证准入策略。

使用 Pod 安全策略来控制 Pod 的安全相关属性，包括容器权限级别

警告
Kubernetes 已弃用 Pod 安全策略，转而支持 Pod 安全标准和 Pod 安全准入控制器，并在 v1.25 版本中将其移除。请考虑改用 Pod 安全标准和 Pod 安全准入控制器。

所有安全策略应包含以下条件：

• 应用程序进程不以 root 身份运行。
• 不允许权限提升。
• 根文件系统是只读的。
• 使用默认（屏蔽）的 /proc 文件系统挂载。
• 不应使用主机网络或进程空间——使用 hostNetwork: true 将导致网络策略被忽略，因为 Pod 将使用其主机网络。
• 消除未使用和不必要的 Linux 功能。
• 使用 SELinux 选项进行更细粒度的进程控制。
• 为每个应用程序提供其自己的 Kubernetes 服务帐户。
• 如果容器不需要访问 Kubernetes API，请勿让其挂载服务帐户凭据。

有关 Pod 安全策略的更多信息，请参阅文档：https://kubernetes.ac.cn/docs/concepts/policy/pod-security-policy/。

--

使用服务网格提供额外安全性

服务网格是一个基础设施层，可以快速、安全、可靠地处理应用程序中服务之间的通信，这有助于降低管理微服务和部署的复杂性。它们提供了一种统一的方式来保护、连接和监控微服务。服务网格在运行这些容器和微服务时，能够很好地解决操作挑战和问题。

服务网格的优势

服务网格提供以下优势：

1. 可观测性

它生成跟踪和遥测指标，使您能够轻松理解系统并快速找出任何问题的根本原因。

2. 专用安全功能

它提供安全功能，可以快速识别进入集群的任何受损流量，并且如果正确实施，可以保护网络内部的服务。它还可以帮助您通过 mTLS、入口和出口控制等方式管理安全性。

3. 使用 mTLS 保护微服务的能力

由于保护微服务安全很困难，有许多工具可以解决微服务安全问题。然而，服务网格是解决网络内部传输中流量加密最优雅的解决方案。

它通过相互 TLS (mTLS) 对服务之间的流量进行加密来提供防御，网格可以自动加密和解密请求和响应，从而减轻了应用程序开发人员的负担。网格还可以通过优先重用现有持久连接来提高性能，这减少了计算成本高昂的新连接创建的需求。借助服务网格，您可以保护线上传输的流量，并为每个微服务进行基于身份的强大认证和授权。

我们看到服务网格对企业公司具有巨大价值，因为网格允许您查看 mTLS 是否在您的每个服务之间启用并正常工作。此外，如果安全状态发生变化，您可以立即收到警报。

4. 入口和出口控制

它允许您监控和处理通过网格的受损流量。例如，如果 Istio 作为入口控制器与 Kubernetes 集成，它可以负责入口的负载均衡。这使得防御者可以通过入口规则在边界添加一层安全性，而出口控制则允许您查看和管理外部服务，并控制您的服务如何与流量交互。

5. 运营控制

它可以帮助安全和平台团队设置正确的宏观控制以强制执行访问控制，同时允许开发人员进行他们所需的定制，以便在这些护栏内快速行动。

6. 管理 RBAC 的能力

服务网格可以帮助防御者实施一个强大的基于角色的访问控制 (RBAC) 系统，这可以说是大型工程组织中最关键的要求之一。即使是安全的系统也可能被特权过高的用户或员工轻易规避，而 RBAC 系统可以：

• 将特权用户限制在执行其工作职责所需的最小特权范围内
• 确保对系统的访问默认设置为“全部拒绝”
• 帮助开发人员确保详细说明角色和职责的适当文档到位，这是企业中最关键的安全问题之一。

服务网格的缺点

尽管服务网格具有许多优势，但它们也带来了一系列独特的挑战，其中一些列举如下：

• 增加了一个新的复杂层

当在已经复杂的环境中引入代理、边车和其他组件时，这会显著增加开发和操作的复杂性。

• 需要额外的专业知识

如果在 Kubernetes 等编排器之上添加 Istio 等网格，操作员需要同时精通这两种技术。

• 基础设施可能变慢

因为服务网格是一种侵入性且复杂的技，它可能会显著降低架构的速度。

• 需要采用另一个平台

由于服务网格具有侵入性，它们迫使开发人员和操作员适应一个高度固定的平台并遵守其规则。

实施集中式策略管理

有许多项目能够为 Kubernetes 集群提供集中式策略管理，包括 Open Policy Agent (OPA) 项目、Kyverno 或 验证准入策略（一项在 1.30 版普遍可用的内置功能）。为了提供一个更深入的示例，本速查表将重点关注 OPA。

OPA 于 2016 年启动，旨在统一不同技术和系统中的策略强制执行，它可用于在 Kubernetes 等平台上强制执行策略。目前，OPA 是 CNCF 的一个孵化项目。它可以在技术栈中创建统一的安全策略强制执行方法。虽然开发人员可以通过 RBAC 和 Pod 安全策略对集群施加细粒度控制，但这些技术仅适用于集群内部，而不适用于集群外部。

由于 OPA 是一个通用、与领域无关的策略执行工具，不依赖于任何其他项目，因此策略查询和决策不遵循特定格式。因此，它可以与 API、Linux SSH 守护程序、像 Ceph 这样的对象存储集成，只要提供所需数据，您可以使用任何有效的 JSON 数据作为请求属性。OPA 允许您选择输入和输出——例如，您可以选择让 OPA 返回一个布尔型 JSON 对象、一个数字、一个字符串，甚至一个复杂的数据对象。

OPA 最常见的用例

用于应用程序授权的 OPA

OPA 可以为开发人员提供一种现成的授权技术，从而使团队不必从头开发。它使用专门用于编写和强制执行规则的声明性策略语言，例如“Alice 可以写入此存储库”或“Bob 可以更新此帐户”。这项技术提供了一套丰富的工具，允许开发人员将策略集成到他们的应用程序中，并允许最终用户也为其租户创建策略。

如果您已经有一个内部开发的应用程序授权解决方案，您可能不想换用 OPA。但是，如果您希望通过转向一个能够随微服务扩展并允许您分解单体应用程序的解决方案来提高开发人员效率，那么您将需要一个分布式授权系统，而 OPA（或其相关竞争对手之一）可能是答案。

用于 Kubernetes 准入控制的 OPA

由于 Kubernetes 为开发人员提供了对传统“计算、网络和存储”孤岛的巨大控制权，他们可以利用它完全按照自己的意愿设置网络和存储。但这意味管理员和安全团队必须确保开发人员不会自毁（或连累他人）。

OPA 可以通过允许安全团队构建策略来解决这些安全问题，这些策略要求所有容器镜像都来自受信任的来源，防止开发人员以 root 身份运行软件，确保存储始终标记加密位并且存储不会仅仅因为 Pod 重启而被删除，限制互联网访问等等。

它还可以允许管理员确保策略更改不会无意中造成比好处更多的损害。OPA 直接集成到 Kubernetes API 服务器中，它拥有完全的权限来拒绝任何准入策略认为不属于集群的资源——无论是计算相关的、网络相关的、存储相关的等等。此外，策略可以带外运行以监控结果，如果开发人员需要及早反馈，OPA 的策略可以在开发生命周期早期（例如 CICD 流水线甚至开发人员的笔记本电脑上）暴露。

用于服务网格授权的 OPA

最后，OPA 可以规范服务网格架构的使用。通常，即使涉及修改源代码，管理员也会通过在服务网格中构建策略来确保符合合规性规定。即使您不嵌入 OPA 来实现应用程序授权逻辑（上面讨论的首要用例），您也可以通过将授权策略放入服务网格来控制微服务 API。但是，如果您出于安全考虑，可以在服务网格中实施策略以限制微服务架构中的横向移动。

限制集群上的资源使用

在 Kubernetes 中为容器定义资源配额非常重要，因为 Kubernetes 集群中的所有资源默认都以无限制的 CPU 和内存请求/限制创建。如果您运行资源无限制的容器，您的系统将面临拒绝服务 (DoS) 或“吵闹邻居”场景的风险。幸运的是，OPA 可以在命名空间上使用资源配额，这将限制授予该命名空间的资源数量或容量，并通过定义其 CPU 容量、内存或持久磁盘空间来限制该命名空间。

此外，OPA 可以限制每个命名空间中存在多少 Pod、服务或卷，并且可以限制上述某些资源的最大或最小大小。当未指定默认限制时，资源配额将提供默认限制，并阻止用户为内存等常用保留资源请求不合理的高值或低值。

以下是在相应 yaml 中定义命名空间资源配额的示例。它将命名空间中的 Pod 数量限制为 4 个，将它们的 CPU 请求限制在 1 到 2 之间，内存请求限制在 1GB 到 2GB 之间。

compute-resources.yaml:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    pods: "4"
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi

将资源配额分配给命名空间

kubectl create -f ./compute-resources.yaml --namespace=myspace

有关配置资源配额的更多信息，请参阅 Kubernetes 文档：https://kubernetes.ac.cn/docs/concepts/policy/resource-quotas/。

使用 Kubernetes 网络策略控制 Pod 和集群之间的流量

如果您的集群运行不同的应用程序，一个被攻破的应用程序可能会攻击其他相邻的应用程序。这种情况可能发生，因为 Kubernetes 默认允许每个 Pod 与其他所有 Pod 进行通信。如果允许来自外部网络端点的入口，Pod 将能够将其流量发送到集群外部的端点。

强烈建议开发人员实施网络分段，因为这是一项关键的安全控制，可确保容器只能与经批准的其他容器通信，并防止攻击者在容器之间进行横向移动。然而，由于容器网络身份 (IP) 的“动态”性质，在云中应用网络分段具有挑战性。

虽然 Google Cloud Platform 的用户可以受益于防止跨集群通信的自动防火墙规则，但其他用户可以通过使用网络防火墙或 SDN 解决方案在本地部署来实现类似的实现。此外，Kubernetes Network SIG 正在研究将大大改进 Pod 到 Pod 通信策略的方法。一个新的网络策略 API 应该解决围绕 Pod 创建防火墙规则的需求，限制容器化应用程序的网络访问。

以下是一个网络策略示例，它控制“后端”Pod 的网络，仅允许来自“前端”Pod 的入站网络访问：

POST /apis/net.alpha.kubernetes.io/v1alpha1/namespaces/tenant-a/networkpolicys
{
  "kind": "NetworkPolicy",
  "metadata": {
    "name": "pol1"
  },
  "spec": {
    "allowIncoming": {
      "from": [{
        "pods": { "segment": "frontend" }
      }],
      "toPorts": [{
        "port": 80,
        "protocol": "TCP"
      }]
    },
    "podSelector": {
      "segment": "backend"
    }
  }
}

有关配置网络策略的更多信息，请参阅 Kubernetes 文档：https://kubernetes.ac.cn/docs/concepts/services-networking/network-policies。

保护数据安全

将秘密作为秘密保存

了解凭证和密钥等敏感数据如何在您的基础设施中存储和访问非常重要。Kubernetes 将它们保存在“秘密 (secret)”中，这是一个包含敏感数据（如密码或令牌）的小对象。

最好将秘密挂载到容器中的只读卷中，而不是将其作为环境变量暴露。此外，秘密必须与镜像或 Pod 分开保存，否则任何有权访问镜像的人也将有权访问秘密，即使一个 Pod 无法访问另一个 Pod 的秘密。处理多个进程并具有公共访问权限的复杂应用程序在这方面尤其脆弱。

对静态秘密进行加密

始终使用经过充分审查的备份和加密解决方案来加密您的备份，并考虑在可能的情况下使用全盘加密，因为 etcd 数据库包含通过 Kubernetes API 可访问的任何信息。访问此数据库可能会让攻击者对集群的状态有显著的可见性。

Kubernetes 支持静态加密，这是一项在 1.7 版本中引入、自 1.13 版本以来为 v1 beta 的功能，它将加密 etcd 中的 Secret 资源，并防止有权访问您的 etcd 备份的各方查看这些秘密的内容。虽然此功能目前处于 Beta 阶段，但当备份未加密或攻击者获得对 etcd 的读取权限时，它提供了一个额外的防御级别。

Kubernetes Secret 资源的替代方案

由于外部秘密管理器可以存储和管理您的秘密，而不是将它们存储在 Kubernetes Secret 中，您可能需要考虑这种安全替代方案。秘密管理器相比使用 Kubernetes Secrets 具有许多优势，包括能够跨多个集群（或云）处理秘密，以及能够集中控制和轮换秘密。

有关秘密及其替代方案的更多信息，请参阅文档：https://kubernetes.ac.cn/docs/concepts/configuration/secret/。

另请参阅秘密管理速查表，了解更多关于管理秘密的详细信息和最佳实践。

发现暴露的秘密

我们强烈建议您根据“最小特权”原则审查容器中存在的秘密材料，并评估泄露所带来的风险。

请记住，SecretScanner 和 ThreatMapper 等开源工具可以扫描容器文件系统，查找敏感资源，例如 API 令牌、密码和密钥。这些资源对于任何有权访问未加密容器文件系统的用户（无论是在构建期间、在注册表或备份中静态存储时，还是运行时）都是可访问的。

---

第 5 节：Kubernetes 安全最佳实践：运行时阶段

当 Kubernetes 基础设施进入运行时阶段时，容器化应用程序将面临一系列新的安全挑战。您必须了解运行环境的可见性，以便在威胁出现时能够检测并响应。

如果您在构建和部署阶段主动保护您的容器和 Kubernetes 部署，您可以大大降低运行时安全事件发生的可能性以及后续响应所需的精力。

首先，监控最与安全相关的容器活动，包括：

• 进程活动
• 容器化服务之间的网络通信
• 容器化服务与外部客户端和服务器之间的网络通信

由于容器和 Kubernetes 的声明性特性，通过观察容器行为来检测异常通常比在虚拟机中更容易。这些属性使得更容易内省您已部署的内容及其预期活动。

使用 Pod 安全准入机制阻止部署有风险的容器/Pod

先前推荐的Pod 安全策略已弃用，并由Pod 安全准入取代，后者是一项允许您在 Kubernetes 集群中对 Pod 强制执行安全策略的新功能。

建议使用 `baseline` 级别作为所有 Pod 的最低安全要求，以确保整个集群达到标准安全水平。然而，集群应努力应用遵循 Pod 强化最佳实践的 `restricted` 级别。

有关配置 Pod 安全准入的更多信息，请参阅文档：https://kubernetes.ac.cn/docs/tasks/configure-pod-container/enforce-standards-admission-controller/。

容器运行时安全

如果在运行时加固容器，安全团队就能够在容器或工作负载运行状态下检测和响应威胁和异常。通常，这是通过拦截低级系统调用并查找可能表明存在漏洞的事件来实现的。应触发警报的事件示例包括：

• 容器内部运行了 shell
• 容器从主机挂载了敏感路径，例如 /proc
• 运行中的容器意外读取了敏感文件，例如 /etc/shadow
• 建立了出站网络连接

Sysdig 的 Falco 等开源工具可以通过为防御者提供大量开箱即用的检测以及创建自定义规则的能力，帮助操作人员快速上手容器运行时安全。

容器沙箱

当容器运行时被允许直接调用主机内核时，内核通常会与硬件和设备交互以响应请求。尽管 Cgroups 和命名空间为容器提供了一定程度的隔离，但内核仍然存在很大的攻击面。当防御者必须处理多租户和高度不受信任的集群时，他们通常会添加额外的沙箱层，以确保不会出现容器逃逸和内核漏洞利用。下面，我们将探讨一些有助于进一步隔离运行中容器与主机内核的开源技术：

• Kata Containers：Kata Containers 是一个开源项目，它使用精简的虚拟机来最小化资源占用并最大化性能，最终进一步隔离容器。
• gVisor：gVisor 是一个比虚拟机（即使是精简版）更轻量级的内核。它是用 Go 编写的独立内核，位于容器和主机内核之间。它是一个强大的沙箱——gVisor 支持容器中约 70% 的 Linux 系统调用，但仅对主机内核使用约 20 个系统调用。
• Firecracker：它是一个在用户空间运行的超轻量级虚拟机。由于它受 seccomp、cgroup 和命名空间策略的限制，系统调用非常有限。Firecracker 在设计时考虑了安全性，但它可能不支持所有的 Kubernetes 或容器运行时部署。

阻止容器加载不需要的内核模块

由于 Linux 内核在某些情况下（例如连接硬件或挂载文件系统时）会自动从磁盘加载内核模块，这可能是一个重要的攻击面。与 Kubernetes 特别相关的是，即使是非特权进程，也可能仅仅通过创建适当类型的套接字，就导致加载某些与网络协议相关的内核模块。这种情况可能允许攻击者利用管理员认为未使用的内核模块中的安全漏洞。

为防止特定模块自动加载，您可以从节点卸载它们，或添加规则来阻止它们。在大多数 Linux 发行版上，您可以通过创建文件（例如 /etc/modprobe.d/kubernetes-blacklist.conf）并包含以下内容来完成此操作：

# DCCP is unlikely to be needed, has had multiple serious
# vulnerabilities, and is not well-maintained.
blacklist dccp

# SCTP is not used in most Kubernetes clusters, and has also had
# vulnerabilities in the past.
blacklist sctp

为了更通用地阻止模块加载，您可以使用 Linux 安全模块（例如 SELinux）完全拒绝容器的 `module_request` 权限，从而在任何情况下都阻止内核为容器加载模块。（Pod 仍然能够使用手动加载的模块，或内核代表某些更高特权进程加载的模块）。

比较和分析同一部署中 Pod 的不同运行时活动

当容器化应用程序出于高可用性、容错或规模原因进行复制时，这些副本的行为应该几乎相同。如果某个副本与其它副本存在显著偏差，防御者将需要进一步调查。您的 Kubernetes 安全工具应与其它外部系统（电子邮件、PagerDuty、Slack、Google Cloud Security Command Center、SIEMs [安全信息和事件管理] 等）集成，并利用部署标签或注解在检测到潜在威胁时向负责特定应用程序的团队发出警报。如果您选择使用商业 Kubernetes 安全供应商，他们应该支持与外部工具的广泛集成。

监控网络流量以限制不必要或不安全的通信

容器化应用程序通常会大量使用集群网络，因此观察活跃的网络流量是了解应用程序如何相互交互并识别意外通信的好方法。您应该观察您活跃的网络流量，并将其与基于您的 Kubernetes 网络策略所允许的流量进行比较。

同时，将活跃流量与允许的流量进行比较，可以为您提供关于未发生但被允许的事件的宝贵信息。有了这些信息，您可以进一步收紧您的允许网络策略，从而移除多余的连接并减少您的整体攻击面。

像 https://github.com/kinvolk/inspektor-gadget 或 https://github.com/deepfence/PacketStreamer 这样的开源项目可能会有所帮助，商业安全解决方案也提供不同程度的容器网络流量分析。

如果发生入侵，将可疑 Pod 扩展到零

通过使用 Kubernetes 原生控制，将可疑 Pod 扩展到零，或终止并重启被入侵应用程序的实例，从而遏制成功的入侵。

频繁轮换基础设施凭据

秘密或凭据的生命周期越短，攻击者利用该凭据的难度就越大。为证书设置较短的生命周期并自动化其轮换。使用可控制颁发令牌可用时长的身份验证提供商，并尽可能使用短生命周期。如果您在外部集成中使用服务账户令牌，请计划频繁轮换这些令牌。例如，一旦引导阶段完成，用于设置节点的引导令牌应被撤销或移除其授权。

日志

Kubernetes 提供基于集群的日志记录，允许您将容器活动记录到中央日志中心。当创建集群时，每个容器的标准输出和标准错误输出可以通过运行在每个节点上的 Fluentd 代理（进入 Google Stackdriver Logging 或 Elasticsearch）被摄取，并使用 Kibana 查看。

启用审计日志

审计记录器是一个测试版功能，它记录 API 执行的操作，以便在发生泄露时进行后续分析。建议启用审计日志记录，并将审计文件归档到安全的服务器上。

确保日志监控异常或不必要的 API 调用，特别是任何授权失败（这些日志条目将显示状态消息“Forbidden”）。授权失败可能意味着攻击者正试图滥用被盗凭据。

托管的 Kubernetes 提供商，包括 GKE，在其云控制台中提供对此数据的访问，并可能允许您设置授权失败警报。

审计日志

审计日志对于合规性很有用，因为它们应该帮助您回答发生了什么、谁做了什么以及何时发生的问题。Kubernetes 提供基于策略的 kube-apiserver 请求的灵活审计。这些有助于您按时间顺序跟踪所有活动。

这是一个审计日志的示例

{
  "kind":"Event",
  "apiVersion":"audit.k8s.io/v1beta1",
  "metadata":{ "creationTimestamp":"2019-08-22T12:00:00Z" },
  "level":"Metadata",
  "timestamp":"2019-08-22T12:00:00Z",
  "auditID":"23bc44ds-2452-242g-fsf2-4242fe3ggfes",
  "stage":"RequestReceived",
  "requestURI":"/api/v1/namespaces/default/persistentvolumeclaims",
  "verb":"list",
  "user": {
    "username":"[email protected]",
    "groups":[ "system:authenticated" ]
  },
  "sourceIPs":[ "172.12.56.1" ],
  "objectRef": {
    "resource":"persistentvolumeclaims",
    "namespace":"default",
    "apiVersion":"v1"
  },
  "requestReceivedTimestamp":"2019-08-22T12:00:00Z",
  "stageTimestamp":"2019-08-22T12:00:00Z"
}

定义审计策略

审计策略设置规则，这些规则定义了应该记录哪些事件以及事件包含时存储哪些数据。审计策略对象结构在 audit.k8s.io API 组中定义。当事件被处理时，它会按照顺序与规则列表进行比较。第一个匹配的规则设置事件的“审计级别”。

已知的审计级别包括

• None - 不记录与此规则匹配的事件
• Metadata - 记录请求元数据（请求用户、时间戳、资源、动词等），但不记录请求或响应体
• Request - 记录事件元数据和请求体，但不记录响应体。这不适用于非资源请求
• RequestResponse - 记录事件元数据、请求和响应体。这不适用于非资源请求

您可以使用 --audit-policy-file 标志将包含策略的文件传递给 kube-apiserver。如果省略该标志，则不记录任何事件。请注意，审计策略文件中必须提供 rules 字段。没有（0）条规则的策略被视为非法。

理解日志记录

Kubernetes 日志记录的一个主要挑战是理解生成了哪些日志以及如何使用它们。让我们首先审视 Kubernetes 日志记录架构的整体概况。

容器日志记录

可以从 Kubernetes 集群收集的第一层日志是您的容器化应用程序生成的日志。记录容器最简单的方法是写入标准输出（stdout）和标准错误（stderr）流。

清单如下。

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
    - name: example
      image: busybox
      args: [/bin/sh, -c, 'while true; do echo $(date); sleep 1; done']

要应用清单，请运行

kubectl apply -f example.yaml

要查看此容器的日志，请运行

kubectl log <container-name> command.

为了持久化容器日志，常见的方法是将日志写入日志文件，然后使用一个 Sidecar 容器。如上文 Pod 配置所示，Sidecar 容器将与应用程序容器在同一个 Pod 中运行，挂载相同的卷并单独处理日志。

Pod 清单示例如下

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
  - name: example
    image: busybox
    args:
    - /bin/sh
    - -c
    - >
      while true;
      do
        echo "$(date)\n" >> /var/log/example.log;
        sleep 1;
      done
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  - name: sidecar
    image: busybox
    args: [/bin/sh, -c, 'tail -f /var/log/example.log']
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  volumes:
  - name: varlog
    emptyDir: {}

节点日志记录

当运行在 Kubernetes 上的容器将其日志写入 stdout 或 stderr 流时，容器引擎会将它们流式传输到 Kubernetes 配置设置的日志驱动程序。

在大多数情况下，这些日志将位于您主机上的 /var/log/containers 目录中。Docker 支持多种日志驱动程序，但不幸的是，驱动程序配置不通过 Kubernetes API 支持。

一旦容器被终止或重启，kubelet 就会将日志存储在节点上。为了防止这些文件耗尽主机的所有存储空间，Kubernetes 节点实现了一个日志轮换机制。当容器从节点中被驱逐时，所有带有相应日志文件的容器也会被驱逐。

根据您主机上运行的操作系统和附加服务，您可能需要查看其他日志。

例如，可以使用以下命令检索 systemd 日志

journalctl -u

集群日志记录

在 Kubernetes 集群本身中，有很长的集群组件列表可以被记录，以及可以使用的额外数据类型（事件、审计日志）。这些不同类型的数据共同为您提供了对 Kubernetes 作为系统运行情况的可见性。

其中一些组件在容器中运行，另一些则在操作系统层面运行（在大多数情况下，是 systemd 服务）。systemd 服务写入 journald，而运行在容器中的组件则将日志写入 /var/log 目录，除非容器引擎已配置为以不同方式流式传输日志。

事件

Kubernetes 事件可以指示任何 Kubernetes 资源状态变化和错误，例如超出资源配额或待处理的 Pod，以及任何信息性消息。

以下命令返回特定命名空间内的所有事件

kubectl get events -n <namespace>

NAMESPACE LAST SEEN TYPE   REASON OBJECT MESSAGE
kube-system  8m22s  Normal   Scheduled            pod/metrics-server-66dbbb67db-lh865                                       Successfully assigned kube-system/metrics-server-66dbbb67db-lh865 to aks-agentpool-42213468-1
kube-system     8m14s               Normal    Pulling                   pod/metrics-server-66dbbb67db-lh865                                       Pulling image "aksrepos.azurecr.io/mirror/metrics-server-amd64:v0.2.1"
kube-system     7m58s               Normal    Pulled                    pod/metrics-server-66dbbb67db-lh865                                       Successfully pulled image "aksrepos.azurecr.io/mirror/metrics-server-amd64:v0.2.1"
kube-system     7m57s               Normal     Created                   pod/metrics-server-66dbbb67db-lh865                                       Created container metrics-server
kube-system     7m57s               Normal    Started                   pod/metrics-server-66dbbb67db-lh865                                       Started container metrics-server
kube-system     8m23s               Normal    SuccessfulCreate          replicaset/metrics-server-66dbbb67db             Created pod: metrics-server-66dbbb67db-lh865

以下命令将显示此特定 Kubernetes 资源的最新事件

kubectl describe pod <pod-name>

Events:
  Type    Reason     Age   From                               Message
  ----    ------     ----  ----                               -------
  Normal  Scheduled  14m   default-scheduler                  Successfully assigned kube-system/coredns-7b54b5b97c-dpll7 to aks-agentpool-42213468-1
  Normal  Pulled     13m   kubelet, aks-agentpool-42213468-1  Container image "aksrepos.azurecr.io/mirror/coredns:1.3.1" already present on machine
  Normal  Created    13m   kubelet, aks-agentpool-42213468-1  Created container coredns
  Normal  Started    13m   kubelet, aks-agentpool-42213468-1  Started container coredns

第五部分：总结

尽早将安全性嵌入到容器生命周期中

您必须尽早将安全性集成到容器生命周期中，并确保安全团队和 DevOps 团队之间的一致性和共同目标。安全可以（也应该）成为一个赋能者，让您的开发人员和 DevOps 团队能够自信地构建和部署具备可扩展性、稳定性和安全性的生产就绪型应用程序。

使用 Kubernetes 原生安全控制来降低操作风险

尽可能利用 Kubernetes 内置的原生控制来强制执行安全策略，这样您的安全控制就不会与编排器冲突。与其使用第三方代理或垫片来强制执行网络分段，不如使用 Kubernetes 网络策略来确保安全的网络通信。

利用 Kubernetes 提供的上下文来优先处理修复工作

请注意，在庞大的 Kubernetes 环境中手动分类安全事件和策略违规行为非常耗时。

例如，如果一个包含严重性评分达到或超过 7 的漏洞的部署包含特权容器并对外开放，则应提高其修复优先级；但如果它位于测试环境并支持非关键应用程序，则应降低其优先级。

---

参考资料

控制平面文档 - https://kubernetes.ac.cn

1. 每个人都必须遵循的 Kubernetes 安全最佳实践 - https://www.cncf.io/blog/2019/01/14/9-kubernetes-security-best-practices-everyone-must-follow
2. 保护集群 - https://kubernetes.ac.cn/docs/tasks/administer-cluster/securing-a-cluster
3. Kubernetes 部署安全最佳实践 - https://kubernetes.ac.cn/blog/2016/08/security-best-practices-kubernetes-deployment
4. Kubernetes 安全最佳实践 - https://phoenixnap.com/kb/kubernetes-security-best-practices
5. Kubernetes 安全 101：风险与 29 条最佳实践 - https://www.stackrox.com/post/2020/05/kubernetes-security-101
6. 15 条 Kubernetes 安全最佳实践以保护您的集群 - https://www.mobilise.cloud/15-kubernetes-security-best-practice-to-secure-your-cluster
7. Kubernetes 安全终极指南 - https://neuvector.com/container-security/kubernetes-security-guide
8. 黑客的 Kubernetes 安全指南 - https://techbeacon.com/enterprise-it/hackers-guide-kubernetes-security
9. 11 种（不被）入侵的方法 - https://kubernetes.ac.cn/blog/2018/07/18/11-ways-not-to-get-hacked
10. 12 条 Kubernetes 配置最佳实践 - https://www.stackrox.com/post/2019/09/12-kubernetes-configuration-best-practices/#6-securely-configure-the-kubernetes-api-server
11. Kubernetes 日志记录实用指南 - https://logz.io/blog/a-practical-guide-to-kubernetes-logging
12. Kubernetes Web UI（Dashboard） - https://kubernetes.ac.cn/docs/tasks/access-application-cluster/web-ui-dashboard
13. 特斯拉云资源被黑客入侵以运行加密货币挖矿恶意软件 - https://arstechnica.com/information-technology/2018/02/tesla-cloud-resources-are-hacked-to-run-cryptocurrency-mining-malware
14. 开放策略代理：云原生授权 - https://blog.styra.com/blog/open-policy-agent-authorization-for-the-cloud
15. 策略即代码简介：开放策略代理（OPA） - https://www.magalix.com/blog/introducing-policy-as-code-the-open-policy-agent-opa
16. 服务网格提供什么 - https://aspenmesh.io/wp-content/uploads/2019/10/AspenMesh_CompleteGuide.pdf
17. 服务网格的三大技术优势及其操作限制，第一部分 - https://glasnostic.com/blog/service-mesh-istio-limits-and-benefits-part-1
18. 开放策略代理：什么是 OPA 以及它是如何工作的（示例） - https://spacelift.io/blog/what-is-open-policy-agent-and-how-it-works
19. 将 Kubernetes 指标发送到 Kibana 和 Elasticsearch - https://logit.io/sources/configure/kubernetes/
20. Kubernetes 安全清单 - https://kubernetes.ac.cn/docs/concepts/security/security-checklist/