将网络策略与 EKS 自动模式结合使用 - Amazon EKS
概述开始使用如何工作？注意事项
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

帮助改进此页面

要帮助改进本用户指南，请选择位于每个页面右侧窗格中的在 GitHub 上编辑此页面链接。

将网络策略与 EKS 自动模式结合使用

概述

随着客户使用 EKS 扩展其应用程序环境，网络流量隔离对于防止未经授权访问集群内外的资源变得越来越重要。对于在集群中同时运行多个不相关工作负载的多租户环境，这一点尤其重要。Kubernetes 网络策略能帮助您改进 Kubernetes 工作负载的网络安全状况，以及它们与集群外部端点的集成。EKS 自动模式支持不同类型的网络策略。

第 3 层和第 4 层隔离

标准 Kubernetes 网络策略在 OSI 网络模型的第 3 层和第 4 层上运行，让您能够控制 Amazon EKS 集群中 IP 地址或端口级别的流量。

使用案例

  • 在工作负载之间对网络流量进行分段，确保只有相关的应用程序才能相互通信。

  • 使用策略在命名空间级别隔离租户，以强制执行网络分离。

基于 DNS 的执行

客户通常在 EKS 中部署属于更广泛的分布式环境中一部分的工作负载，其中一些工作负载必须与集群外的系统和服务通信（北向流量）。这些系统和服务可以位于 Amazon 云中，也可以完全位于 Amazon 外部。基于域名系统（DNS）的策略允许您采用更稳定、更可预测的方法来防止容器组（pod）未经授权访问集群外部资源或端点，从而改进您的安全状况。这种机制无需手动跟踪并将特定 IP 地址加入允许列表。通过使用基于 DNS 的方法保护资源，您还可以更灵活地更新外部基础设施，而不必在上游服务器和主机发生变化时放松安全状况或修改网络策略。您可以使用完全限定域名（FQDN）或 DNS 域名的匹配模式筛选传送至外部端点的出口流量。这样您便可以更加灵活地将访问权限扩展到与特定集群外部端点关联的多个子域。

使用案例

  • 使用基于 DNS 的方法进行标准化，用于筛选从 Kubernetes 环境到集群外部端点的访问权限。

  • 在多租户环境中安全访问 Amazon 服务。

  • 在混合云环境中管理从容器组（pod）到本地工作负载的网络访问权限。

管理员（或集群范围）规则

在某些情况下，例如多租户场景，客户可能需要强制执行适用于整个集群的网络安全标准。无需为每个命名空间重复定义和维护不同的策略，而是可以使用单个策略来集中管理集群中不同工作负载的网络访问权限控制，无论其命名空间如何。这些类型的策略允许您扩大在第 3 层、第 4 层以及使用 DNS 规则时应用的网络筛选规则的实施范围。

使用案例

  • 集中管理 EKS 集群中所有（或部分）工作负载的网络访问权限控制。

  • 定义整个集群的默认网络安全状况。

  • 以更具运营效率的方式，将组织安全标准扩展到集群范围。

开始使用

先决条件

  • 启用了 EKS 自动模式的 Amazon EKS 集群

  • 配置好 kubectl 以连接到集群

第 1 步：启用网络策略控制器

要将网络策略与 EKS 自动模式结合使用，您首先需要通过将 ConfigMap 应用到集群来启用网络策略控制器。

  1. 使用以下内容创建名为 enable-network-policy.yaml 的文件：

    apiVersion: v1
kind: ConfigMap
metadata:
  name: amazon-vpc-cni
  namespace: kube-system
data:
  enable-network-policy-controller: "true"

  2. 将 ConfigMap 应用到集群：

    kubectl apply -f enable-network-policy.yaml

第 2 步：在节点类中启用网络策略

您需要首先确保节点类已配置为支持网络策略，然后才能使用这些策略。按照以下步骤进行操作：

  1. 创建或编辑包含以下内容的节点类 YAML 文件（例如 nodeclass-network-policy.yaml）：

    apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: network-policy-enabled
spec:
  # Enables network policy support
  networkPolicy: DefaultAllow
  # Optional: Enables logging for network policy events
  networkPolicyEventLogs: Enabled
  # Include other Node Class configurations as needed

  2. 将节点类配置应用到集群：

    kubectl apply -f nodeclass-network-policy.yaml

  3. 验证节点类是否已创建：

    kubectl get nodeclass network-policy-enabled

  4. 更新节点池以使用此节点类。有关更多信息，请参阅 为 EKS 自动模式创建节点池。

只要您的节点使用此节点类，既可以强制实施网络策略。现在，您可以开始创建和应用网络策略来控制集群内的流量。有关所有节点类配置选项，请参阅为 Amazon EKS 创建节点类。

第 3 步：创建和测试网络策略

您的 EKS 自动模式集群现已配置为支持 Kubernetes 网络策略。您可以使用 Amazon EKS 的网络策略的 Stars 演示 进行测试。

如何工作？

基于 DNS 的网络策略

在 EKS 自动模式中应用基于 DNS 的策略时的工作流程示意图
在 EKS 自动模式中应用基于 DNS 的策略时的工作流程示意图

  1. 平台团队将基于 DNS 的策略应用于 EKS 集群。

  2. 网络策略控制器负责监控集群内策略的创建情况，然后协调策略端点。在此使用案例中，网络策略控制器指示节点代理根据创建的策略中的允许列表域筛选 DNS 请求。使用 FQDN 或与 Kubernetes 资源配置中定义的模式相匹配的域名，将域名列入允许名单。

  3. 工作负载 A 尝试解析集群外部端点的 IP。DNS 请求首先通过代理，该代理根据通过网络策略应用的允许列表筛选此类请求。

  4. 一旦 DNS 请求通过 DNS 筛选器允许列表，就会被传输到 CoreDNS，

  5. 反过来，CoreDNS 会将请求发送到外部 DNS 解析器（Amazon Route 53 Resolver），获取域名背后的 IP 地址列表。

  6. 已解析的 IP 连同 TTL 都将在对 DNS 请求的响应中返回。然后，将这些 IP 写入 eBPF 映射中，该映射用于 IP 层执行的下一步。

  7. 随后，连接到容器组（pod）veth 接口的 eBPF 探测器将根据现有规则筛选从工作负载 A 到集群外部端点的出口流量。这可确保容器组（pod）只能向已加入允许列表的域 IP 发送集群外部流量。这些 IP 的有效性取决于从外部 DNS 解析器（Amazon Route 53 Resolver）检索到的 TTL。

使用应用程序网络策略

ApplicationNetworkPolicy 使用单个自定义资源定义（CRD）在命名空间级别将标准 Kubernetes 网络策略的功能与基于 DNS 的筛选相结合。因此，ApplicationNetworkPolicy 可以用于：

  1. 使用 IP 块和端口号定义网络堆栈第 3 层和第 4 层的限制。

  2. 定义网络堆栈第 7 层运行的规则，并允许您基于 FQDN 筛选流量。

重要说明：使用 ApplicationNetworkPolicy 定义的基于 DNS 的规则仅适用于在 EKS 自动模式启动的 EC2 实例中运行的工作负载。

示例

您的 EKS 自动模式集群中有一个工作负载，需要与带有 DNS 名称的负载均衡器背后的本地应用程序通信。您可以使用以下网络策略实现此目的：

apiVersion: networking.k8s.aws/v1alpha1
kind: ApplicationNetworkPolicy
metadata:
  name: my-onprem-app-egress
  namespace: galaxy
spec:
  podSelector:
    matchLabels:
      role: backend
  policyTypes:
  - Egress
  egress:
  - to:
    - domainNames:
      - "myapp.mydomain.com"
    ports:
    - protocol: TCP
      port: 8080

在 Kubernetes 网络级别，这将允许来自标有 role: backend 的“galaxy”命名空间中的任何容器组（pod）的出口，通过 TCP 端口 8080 连接到域名 myapp.mydomain.com。此外，您还需要为从 VPC 到公司数据中心的出口流量设置网络连接。

EKS 自动模式中的工作负载与本地应用程序通信示意图

管理员（或集群）网络策略

EKS 中的网络策略评估顺序示意图

使用集群网络策略

使用 ClusterNetworkPolicy 时，将首先评估管理员层策略，并且无法被覆盖。在评估管理员层策略后，将使用标准命名空间范围策略来执行应用的网络分段规则。这可以通过使用 ApplicationNetworkPolicy 或 NetworkPolicy 完成。最后，将强制执行定义了集群工作负载默认网络限制的基准层规则。如有需要，这些基准层规则可以被命名空间范围的策略所覆盖。

示例

您的集群中有一个要与其他租户工作负载隔离的应用程序。您可以明确阻止来自其他命名空间的集群流量，防止网络访问敏感的工作负载命名空间。

apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
  name: protect-sensitive-workload
spec:
  tier: Admin
  priority: 10
  subject:
    namespaces:
      matchLabels:
        kubernetes.io/metadata.name: earth
  ingress:
    - action: Deny
      from:
      - namespaces:
          matchLabels: {} # Match all namespaces.
      name: select-all-deny-all

注意事项

了解策略评估顺序

EKS 中支持的网络策略功能按特定顺序进行评估，以确保流量管理可预测且安全。因此，了解评估流程是非常重要的，这样才能为您的环境设计有效的网络安全状况。

  1. 管理员层策略（先进行评估）：首先对所有管理员层 ClusterNetworkPolicies 进行评估，然后再评估任何其他策略。在管理员层中，策略按优先级顺序处理（优先级序号最小者优先）。操作类型决定了接下来的操作。

    • Deny 操作（优先级最高）：当具有 Deny 操作的管理员策略与流量匹配时，无论采用何种其他策略，该流量都会立即被阻止。不再处理其他 ClusterNetworkPolicy 或 NetworkPolicy 规则。这样可以确保组织范围的安全控制不会被命名空间级别的策略所覆盖。

    • Allow 操作：评估 Deny 规则后，将按优先级顺序处理具有 Allow 操作的管理员策略（优先级序号最小者优先）。当 Allow 操作匹配时，流量将被接受，并且不再进行进一步的策略评估。这些策略可以根据标签选择器授予跨多个命名空间的访问权限，从而集中控制哪些工作负载可以访问特定资源。

    • Pass 操作：管理员层策略中的 Pass 操作将决策委托给较低层级。当流量与 Pass 规则匹配时，评估将跳过该流量的所有剩余管理层规则，直接进入 NetworkPolicy 层。这允许管理员将某些流量模式的控制权明确委托给应用程序团队。例如，您可以使用 Pass 规则将命名空间内的流量管理委托给命名空间管理员，同时保持对外部访问权限的严格控制。

  2. 网络策略层：如果没有与 Deny 或 Allow 匹配的管理员层策略，或者匹配了 Pass 操作，则接下来将评估命名空间范围的 ApplicationNetworkPolicy 和传统 NetworkPolicy 资源。这些策略在各个命名空间内提供精细的控制，并由应用程序团队管理。命名空间范围的策略只能比管理员策略更严格。它们无法覆盖管理员策略的 Deny 决策，但可以进一步限制管理员策略允许或通过的流量。

  3. 基准层管理员策略：如果没有管理员或命名空间范围的策略与流量匹配，则会评估基准层 ClusterNetworkPolicies。它们提供了可以被命名空间范围的策略覆盖的默认安全状况，允许管理员设置组织范围的默认值，同时让团队可以灵活地根据需要进行自定义。基准策略按优先级顺序进行评估（优先级序号最小者优先）。

  4. 默认拒绝（如果没有匹配的策略）：这种默认拒绝行为可确保仅允许明确允许的连接，从而保持稳固的安全状况。

应用最低权限原则

  • 从限制性策略开始，然后根据需要逐步添加权限：首先在集群级别实施默认拒绝策略，然后在验证合法的连接要求时，逐步添加允许规则。这种方法迫使团队明确证明每个外部连接的合理性，从而打造更加安全且可审计的环境。

  • 定期审计并删除未使用的策略规则：随着应用程序的发展，网络策略可能会随着时间的推移而积累，所留下的过时规则会不必要地扩大攻击面。实施定期审查流程，以确定并删除不再需要的策略规则，确保您的安全状况保持严密且可维护。

  • 尽可能使用特定的域名而不是宽泛的模式：虽然像 *.amazonaws.com 这类通配符模式提供了便利，但这也会授予对各种服务的访问权限。只要可行，请指定如 s3.us-west-2.amazonaws.com 等确切的域名，仅允许访问应用程序所需的特定服务，从而降低工作负载遭盗用时横向移动的风险。

在 EKS 中使用基于 DNS 的策略

  • 使用 ApplicationNetworkPolicy 定义的基于 DNS 的规则仅适用于在 EKS 自动模式启动的 EC2 实例中运行的工作负载。如果您运行的是混合模式集群（由 EKS 自动模式和非 EKS 自动模式 Worker 节点组成），则基于 DNS 的规则仅在 EKS 自动模式 Worker 节点（EC2 托管实例）中有效。

验证 DNS 策略

  • 使用与生产网络拓扑结构相同的暂存集群进行测试：您的暂存环境应复制生产的网络架构、外部依赖关系和连接模式，确保进行准确的策略测试。这包括相同的 VPC 配置、DNS 解析行为以及访问生产工作负载所需的相同外部服务。

  • 对关键网络路径实施自动测试：构建自动化测试，验证与基本外部服务的连接（作为 CI/CD 管道的一部分）。这些测试应验证在阻止未经授权的连接的同时是否允许合法的流量，从而持续验证随着基础设施的演变，您的网络策略是否仍能保持理想的安全状况。

  • 在策略更改后监控应用程序行为：将新的或经修改的网络策略部署到生产环境后，密切监控应用程序日志、错误率和性能指标，以此快速识别任何连接问题。制定明确的回滚程序，以便在策略更改导致意外应用程序行为或服务中断时可以快速还原这些更改。

与 Amazon Route 53 DNS 防火墙互动

当流量启动时，首先在容器组（pod）级别评估 EKS 管理员和网络策略。如果 EKS 网络策略允许出口到特定域，则该容器组（pod）随后会执行 DNS 查询，其随后会到达 Route 53 解析器。此时，将对 Route 53 的 DNS 防火墙规则进行评估。如果 DNS 防火墙阻止域查询，那么即使 EKS 网络策略允许 DNS 解析失败，也无法建立连接。这创建了互补的安全层：基于 EKS DNS 的网络策略为应用程序特定的访问要求和多租户安全边界提供容器组（pod）级别的出口控制，而 DNS 防火墙则提供 VPC 范围内针对已知恶意域的保护，并强制执行组织范围的阻止名单。