本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

网络安全

网络安全有几个方面。第一个涉及应用限制服务之间网络流量流动的规则。第二个涉及在传输过程中对流量进行加密。在 EKS 上实施这些安全措施的机制多种多样，但通常包括以下项目：

交通管制

网络加密

网络策略

在 Kubernetes 集群中，默认情况下允许所有 Pod 与 Pod 的通信。尽管这种灵活性可能有助于促进实验，但它并不安全。Kubernetes 网络策略为你提供了一种限制 Pod 之间的网络流量（通常称为 East/West流量）以及 Pod 与外部服务之间的网络流量的机制。Kubernetes 网络策略在 OSI 模型的第 3 层和第 4 层运行。网络策略使用 pod、命名空间选择器和标签来识别源和目标 Pod，但也可以包括 IP 地址、端口号、协议或它们的组合。网络策略可以应用于 Pod 的入站或出站连接，通常称为入口和出口规则。

借助 Amazon VPC CNI 插件的原生网络策略支持，您可以实施网络策略来保护 kubernetes 集群中的网络流量。它与上游 Kubernetes 网络策略 API 集成在一起，确保了兼容性并遵守了 Kubernetes 标准。您可以使用上游 API 支持的不同标识符定义策略。默认情况下，允许所有入口和出口流量流向 Pod。如果指定了带有 PolicyType Ingress 的网络策略，则只允许来自容器节点的连接和入口规则允许的连接。同样适用于出口规则。如果定义了多条规则，则在做出决策时会考虑所有规则的并集。因此，评估顺序不会影响策略结果。

建议

网络策略入门-遵循最小权限原则

创建默认拒绝策略

与 RBAC 策略一样，建议在网络策略中遵循最低权限访问原则。首先，创建一个 “全部拒绝” 策略，限制命名空间中的所有入站和出站流量。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

默认拒绝

创建允许 DNS 查询的规则

一旦设置了默认的 “全部拒绝” 规则，就可以开始对其他规则进行分层，例如允许 pod 查询 CoreDNS 以进行名称解析的规则。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-access
  namespace: default
spec:
  podSelector:
    matchLabels: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53

允许 dns 访问

逐步添加规则，有选择地允许两者之间的流量流动 namespaces/pods

了解应用程序要求并根据需要创建精细的入口和出口规则。以下示例显示如何将端口 80 上的入口流量限制为 f app-one ro client-one m。这有助于最大限度地减少攻击面并降低未经授权访问的风险。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-app-one
  namespace: default
spec:
  podSelector:
    matchLabels:
      k8s-app: app-one
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          k8s-app: client-one
    ports:
    - protocol: TCP
      port: 80

允许进入应用程序一

监控网络策略的执行

package kubernetes.admission
import data.kubernetes.networkpolicies

deny[msg] {
    input.request.kind.kind == "Pod"
    pod_label_value := {v["k8s-app"] | v := input.request.object.metadata.labels}
    contains_label(pod_label_value, "sample-app")
    np_label_value := {v["k8s-app"] | v := networkpolicies[_].spec.podSelector.matchLabels}
    not contains_label(np_label_value, "sample-app")
    msg:= sprintf("The Pod %v could not be created because it is missing an associated Network Policy.", [input.request.object.metadata.name])
}
contains_label(arr, val) {
    arr[_] == val
}

问题排查

监控 vpc-网络策略控制器、节点代理日志

启用 EKS 控制平面控制器管理器日志来诊断网络策略功能。您可以将控制平面日志流式传输到CloudWatch 日志组，并使用CloudWatch日志见解执行高级查询。从日志中，您可以查看哪些 pod 端点对象已解析为网络策略、策略的协调状态，以及调试该策略是否按预期运行。

此外，亚马逊 VPC CNI 允许您从 EKS 工作节点收集策略执行日志并将其导出到亚马逊 Cloudwatch。启用后，您可以利用 CloudWatch Container Insights 来提供与网络策略相关的使用情况的见解。

亚马逊 VPC CNI 还提供了一个软件开发工具包，该软件开发工具包提供了与节点上的 eBPF 程序进行交互的接口。将 SDK 部署到节点上时即会安装。aws-node你可以找到安装在节点/opt/cni/bin目录下的 SDK 二进制文件。在发布时，SDK 为检查 eBPF 程序和地图等基本功能提供支持。

sudo /opt/cni/bin/aws-eks-na-cli ebpf progs

记录网络流量元数据

AWS VPC 流量日志捕获有关流经 VPC 的流量的元数据，例如源和目标 IP 地址和端口以及accepted/dropped 数据包。可以分析这些信息，以查找 VPC 内资源（包括 Pod）之间的可疑或异常活动。但是，由于 pod 的 IP 地址在被替换时经常发生变化，因此 Flow Log 本身可能不够。Calico Enterprise 使用容器标签和其他元数据扩展了流量日志，使解密容器之间的流量变得更加容易。

安全组

EKS 使用 AWS VPC 安全组 (SG) 来控制 Kubernetes 控制平面和集群工作节点之间的流量。安全组还用于控制工作节点、其他 VPC 资源和外部 IP 地址之间的流量。当您配置 EKS 集群（使用 Kubernetes 版本 1.14-eks.3 或更高版本）时，会自动为您创建集群安全组。该安全组允许 EKS 控制平面和托管节点组中的节点之间不受限制的通信。为简单起见，建议您将集群 SG 添加到所有节点组，包括非托管节点组。

在 Kubernetes 版本 1.14 和 EKS 版本 eks.3 之前，为 EKS 控制平面和节点组配置了单独的安全组。控制平面和节点组安全组的最低和建议规则可以在控制平面安全组的最低规则https://docs.aws.amazon.com/eks/latest/userguide/sec-group-reqs.html.中找到。控制平面安全组的最低规则允许端口 443 从工作节点 SG 入站。这条规则允许 kubelet 与 Kubernetes API 服务器进行通信。它还包括端口 10250，用于流向工作节点 SG 的出站流量；10250 是 kubelet 监听的端口。同样，最低节点组规则允许端口 10250 从控制平面 SG 入站，443 出站到控制平面 SG。最后，还有一条规则允许节点组中的节点之间进行不受限制的通信。

如果您需要控制在集群内运行的服务与在集群外运行的服务（例如 RDS 数据库）之间的通信，请考虑为 pod 设置安全组。使用容器安全组，您可以将现有的安全组分配给一组 pod。

您可以通过创建SecurityGroupPolicy对象并指定 a PodSelector 或 a 来控制将哪些 pod 分配给安全组ServiceAccountSelector。将选择器设置为{}会将中引用的 SG 分配给命名空间中的所有 pod 或命名空间中的所有服务帐户。SecurityGroupPolicy在为 pod 实施安全组之前，请务必熟悉所有注意事项。

虽然 pod 的安全组提供了一 AWS-native 种无需策略守护程序开销即可控制集群内外的网络流量的方法，但还有其他选项可供选择。例如，Cilium 策略引擎允许您在网络策略中引用 DNS 名称。Calico 企业版包含将网络策略映射到 AWS 安全组的选项。如果您已经实现了像 Istio 这样的服务网格，则可以使用出口网关将网络出口限制到特定的、完全合格的域或 IP 地址。有关此选项的更多信息，请阅读有关 Istio 中出口流量控制的三部分系列。

何时为 Pod 使用网络策略与安全组？

何时使用 Kubernetes 网络策略

何时为 pod 使用 AWS 安全组 (SGP)

为 pod 使用安全组和网络策略的最佳实践

在网络安全方面，分层方法通常是最有效的解决方案。结合使用 kubernetes 网络策略和 SGP 可以为在 EKS 中运行的应用程序提供强大的深度防御策略。

服务网格策略实施或 Kubernetes 网络策略

A service mesh 是专用的基础架构层，您可以将其添加到应用程序中。它允许您透明地添加可观察性、流量管理和安全性等功能，而无需将其添加到自己的代码中。

服务网格在 OSI 模型的第 7 层（应用程序）上执行策略，而 kubernetes 网络策略在第 3 层（网络）和第 4 层（传输）上运行。这个领域有许多产品，比如 AWS AppMesh、Istio、Linkerd 等，

何时使用服务网格执行策略

选择 Kubernetes 网络策略以获得更简单的用例

ThirdParty 网络策略引擎

如果您有高级策略要求，例如全球网络策略、支持基于 DNS 主机名的规则、第 7 层规则、基于规则和明确 deny/log 操作等， ServiceAccount 可以考虑使用第三方网络策略引擎。 Calico 是 Tigera 的开源策略引擎，可与 EKS 配合使用。除了实现全套 Kubernetes 网络策略功能外，Calico 还支持具有更丰富功能的扩展网络策略，包括与 Istio 集成时对第 7 层规则的支持，例如 HTTP。Calico 策略的范围可以限定为命名空间、Pod、服务帐号或全局范围。当策略的范围限定为某个服务帐号时，它会将一组 ingress/egress 规则与该服务帐号相关联。制定适当的 RBAC 规则后，您可以防止团队覆盖这些规则，从而允许 IT 安全专业人员安全地委托对命名空间的管理。Cilium的维护者Isovalent还扩展了网络策略，包括对第7层规则（例如HTTP）的部分支持。Cilium 还支持 DNS 主机名，这可用于限制 Kubernetes 与在 VPC 内外运行的资源 Services/Pods 之间的流量。相比之下，Calico Enterprise包含一项功能，允许您将Kubernetes网络策略映射到AWS安全组以及DNS主机名。

你可以在以下网址找到常见 Kubernetes 网络策略的列表。Calic https://github.com/ahmetb/kubernetes-network-policy-recipes. o 的一组类似规则可在以下网址找到 https://docs.projectcalico.org/security/calico-network-policy.

迁移到 Amazon VPC CNI 网络策略引擎

为了保持一致性并避免意外的 pod 通信行为，建议仅在集群中部署一个网络策略引擎。如果您想从 3P 迁移到 VPC CNI 网络策略引擎，我们建议您在启用 VPC CNI 网络策略支持之前将现有的 3P NetworkPolicy CRD 转换为 Kubernetes NetworkPolicy 资源。而且，在生产环境中应用迁移策略之前，请在单独的测试集群中对其进行测试。这使您可以识别和解决 Pod 通信行为中的任何潜在问题或不一致之处。

迁移工具

为了协助您的迁移过程，我们开发了一个名为 K8s 网络策略迁移器的工具，可将您现有的网络策略 CRD 转换为 Kubernetes 原生 Calico/Cilium 网络策略。转换后，您可以直接在运行 VPC CNI 网络策略控制器的新集群上测试转换后的网络策略。该工具旨在帮助您简化迁移过程并确保平稳过渡。

请注意，AWS VPC CNI 网络策略工程团队目前不支持迁移工具，它是尽最大努力向客户提供的。我们鼓励您使用此工具来简化迁移过程。如果您在使用该工具时遇到任何问题或错误，我们恳请您创建GitHub问题。您的反馈对我们非常宝贵，将有助于我们持续改进服务。

其他资源

传输中加密

需要遵守 PCI、HIPAA 或其他法规的应用程序可能需要在传输过程中对数据进行加密。如今，TLS 实际上是加密网络流量的选择。TLS 与其前身 SSL 一样，使用加密协议通过网络提供安全通信。TLS 使用对称加密，其中加密数据的密钥是根据会话开始时协商的共享密钥生成的。以下是在 Kubernetes 环境中加密数据的几种方法。

Nitro 实例

默认情况下，以下 Nitro 实例类型（例如 C5n、G4、I3en、M5dn、M5n、P3dn、P3dn、R5dn 和 R5n）之间交换的流量会自动加密。当存在中间跃点（例如传输网关或负载均衡器）时，流量不会加密。有关传输中加密的更多详细信息以及默认支持网络加密的实例类型的完整列表，请参阅传输中加密。

服务网格

传输中的加密也可以通过 App Mesh、Linkerd v2 和 Istio 等服务网格来实现。 AppMesh 支持带有 X.509 证书的 mTL 或 Envoy 的秘密发现服务 (SDS)。Linkerd 和 Istio 都支持 mTL。

aws-app-mesh-examples GitHub 存储库提供了在 Envoy 容器中使用 X.509证书和 SPIRE 作为 SDS 提供商配置 mTL 的演练：

App Mesh 还支持使用由 AWS 证书管理器 (ACM) 颁发的私有证书或存储在虚拟节点本地文件系统中的证书进行 TLS 加密。

aws-app-mesh-examples GitHub 存储库提供了使用 ACM 颁发的证书和 Envoy 容器打包的证书配置 TLS 的演练：

入口控制器和负载均衡器

入口控制器是您智能地将来自集群外部的 HTTP/S流量路由到集群内部运行的服务的一种方式。通常，这些入口由第 4 层负载均衡器前置，例如经典负载均衡器或网络负载均衡器 (NLB)。加密流量可以在网络中的不同位置终止，例如在负载均衡器、入口资源或 Pod 上。终止 SSL 连接的方式和地点最终将由贵组织的网络安全政策决定。例如，如果你有一个需要端到端加密的策略，你必须解密 Pod 上的流量。这将给你的 Pod 带来额外的负担，因为它必须花费大量时间来建立初始握手。总体 SSL/TLS 处理非常占用 CPU 资源。因此，如果您有灵活性，可以尝试在 Ingress 或负载均衡器上执行 SSL 卸载。

在 AWS 弹性负载均衡器中使用加密

AWS 应用程序负载均衡器 (ALB) 和网络负载均衡器 (NLB) 都支持传输加密（SSL 和 TLS）。ALB 的alb.ingress.kubernetes.io/certificate-arn注解允许您指定要向 ALB 添加哪些证书。如果您省略注解，控制器将尝试使用主机字段匹配可用的 AWS 证书管理器 (ACM) 证书，向需要该注解的监听器添加证书。从 EKS v1.15 开始，你可以在 NLB 中使用service.beta.kubernetes.io/aws-load-balancer-ssl-cert注解，如下例所示。

apiVersion: v1
kind: Service
metadata:
  name: demo-app
  namespace: default
  labels:
    app: demo-app
  annotations:
     service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
     service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "<certificate ARN>"
     service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443"
     service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "http"
spec:
  type: LoadBalancer
  ports:
  - port: 443
    targetPort: 80
    protocol: TCP
  selector:
    app: demo-app
//---
kind: Deployment
apiVersion: apps/v1
metadata:
  name: nginx
  namespace: default
  labels:
    app: demo-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-app
  template:
    metadata:
      labels:
        app: demo-app
    spec:
      containers:
        - name: nginx
          image: nginx
          ports:
            - containerPort: 443
              protocol: TCP
            - containerPort: 80
              protocol: TCP

以下是其他 SSL/TLS 终止示例。

带有证书管理器的 ACM 私有 CA

您可以使用 ACM 私有证书颁发机构 (CA) 和证书管理器（一种用于分发、续订和吊销证书的常用 Kub ernetes 插件）启用 TLS 和 mTLS 来保护入口处、容器上和 pod 之间的 EKS 应用程序工作负载。ACM Private CA 是一种高度可用、安全的托管式 CA，无需管理自己的 CA 所需的前期和维护成本。如果您使用默认的 Kubernetes 证书颁发机构，则有机会提高安全性并满足 ACM 私有 CA 的合规性要求。相比之下，ACM 私有 CA 在 FIPS 140-2 第 3 级硬件安全模块（非常安全）中保护私钥（非常安全），而默认 CA 则存储在内存中编码的密钥（不太安全）。集中式 CA 还使您可以在 Kubernetes 环境内外对私有证书进行更多控制并提高其可审计性。

Short-Lived 工作负载之间双向 TLS 的 CA 模式

在 EKS 中将 ACM 私有 CA 用于 mTL 时，建议您使用具有短期 CA 模式的短期证书。尽管可以在通用 CA 模式下颁发短期证书，但对于需要经常颁发新证书的用例，使用短期 CA 模式更具成本效益（比普通模式便宜约 75%）。除此之外，你应该尝试使私有证书的有效期与 EKS 集群中 pod 的生命周期保持一致。在此处了解有关 ACM 私有 CA 及其优势的更多信息。

ACM 设置说明

首先，按照 ACM 私有 CA 技术文档中提供的步骤创建私有 CA。拥有私有 CA 后，按照常规安装说明安装证书管理器。安装证书管理器后，按照中的设置说明安装私有 CA Kubernetes 证书管理器插件。 GitHub 该插件允许证书管理器从 ACM 私有 CA 请求私有证书。

现在你已经有了私有 CA 和一个安装了证书管理器和插件的 EKS 集群，是时候设置权限并创建颁发者了。更新 EKS 节点角色的 IAM 权限，以允许访问 ACM 私有 CA。将<CA_ARN>替换为您的私有 CA 中的值：

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Sid": "awspcaissuer",
            "Action": [
                "acm-pca:DescribeCertificateAuthority",
                "acm-pca:GetCertificate",
                "acm-pca:IssueCertificate"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:acm-pca:us-west-2:123456789012:certificate-authority/12345678-1234-1234-1234-123456789012"
        }
    ]
}

https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html也可以使用 IAM 账户或 IRSA 的服务角色。有关完整示例，请参阅下面的 “其他资源” 部分。

在亚马逊 EKS 中创建发行人，方法是创建一个名为 cluster-issuer.yaml 的自定义资源定义文件，其中包含以下文本，将信息替换<CA_ARN>为您的私有 CA。<Region>

apiVersion: awspca.cert-manager.io/v1beta1
kind: AWSPCAClusterIssuer
metadata:
          name: demo-test-root-ca
spec:
          arn: <CA_ARN>
          region: <Region>

部署您创建的发行者。

kubectl apply -f cluster-issuer.yaml

您的 EKS 集群配置为向私有 CA 请求证书。现在，您可以使用 cert-manager 的Certificate资源通过将issuerRef字段的值更改为您在上面创建的私有 CA 颁发者来颁发证书。有关如何指定和请求证书资源的更多详细信息，请查看 cert-manager 的证书资源指南。请在此处查看示例。

带有 Istio 和证书管理器的 ACM 私有 CA

如果您在 EKS 集群中运行 Istio，则可以禁用 Istio 控制平面（特别是istiod）作为根证书颁发机构（CA），并将 ACM 私有 CA 配置为工作负载之间 mTL 的根 CA。如果你采用这种方法，可以考虑在 ACM 私有 CA 中使用短期 CA 模式。有关更多详细信息，请参阅上一节和这篇博客文章。

证书签名在 Istio 中的工作原理（默认）

Kubernetes 中的工作负载使用服务帐号进行识别。如果您未指定服务帐号，Kubernetes 将自动为您的工作负载分配一个服务帐号。此外，服务帐号会自动挂载关联的令牌。服务账户使用此令牌让工作负载通过 Kubernetes API 进行身份验证。服务账户可能足以作为 Kubernetes 的身份，但是 Istio 有自己的身份管理系统和 CA。当工作负载使用其 envoy sidecar 代理启动时，它需要从 Istio 分配一个身份，才能被认为是可信的，并允许它与网格中的其他服务通信。

为了从 Istio 获取此身份，会向 Istio 控制平面istio-agent发送一个称为证书签名请求（或 CSR）的请求。此 CSR 包含服务帐号令牌，因此可以在处理工作负载之前验证其身份。该验证过程由istiod注册机构（简称 RA）和 CA 处理。RA 充当看门人，确保只有经过验证的 CSR 才能通过 CA。CSR 通过验证后，它将被转发到 CA，然后由该机构颁发包含服务帐号的 SPIFFE 身份的证书。该证书被称为 SPIFFE 可验证身份证件（或 SVID）。SVID 被分配给请求服务用于识别和加密通信服务之间传输的流量。

Istio 证书签名请求的默认流程：

使用 ACM 私有 CA 在 Istio 中如何进行证书签名

您可以使用名为 Istio 证书签名请求代理 (istio-csr) 的证书管理器插件将 Istio 与 ACM 私有 CA 集成。该代理允许证书管理器颁发者（在本例中为 ACM 私有 CA）保护 Istio 工作负载和控制平面组件。istio-csr 代理提供的服务与 i stiod 在验证传入 CSR 的默认配置中提供的服务相同。但是，经过验证，它将请求转换为证书管理器支持的资源（即与外部 CA 颁发机构的集成）。

每当有来自工作负载的 CSR 时，它就会被转发到 istio-csr，后者将向 ACM 私有 CA 申请证书。istio-csr 和 ACM 私有 CA 之间的这种通信由 AWS 私有 CA 发行者插件启用。证书管理器使用此插件向 ACM 私有 CA 请求 TLS 证书。颁发者插件将与 ACM 私有 CA 服务通信，为工作负载请求签名证书。证书签名后，它将返回给 istio-csr，后者将读取签名的请求，并将其返回到启动 CSR 的工作负载中。

使用 istio-csr 提出 Istio 证书签名请求的流程

图片:: istio-csr-with-acm-private-ca.png [使用 istio-csr 提出 Istio 证书签名请求的流程]

带有私有 CA 设置说明的 Istio

Istio 证书签名请求

图片:: istio-csr-requests.png [Istio 证书签名请求]

工具和资源