网络安全概述

容器服务集群中的网络安全措施，主要包括：流量管制和网络加密。VKE 集群中提供多种功能支持上述网络安全措施。如下表所示。

策略对比

使用场景

在集群中使用 Kubernetes 网络策略和安全组进行流量管制，适用于不同的场景，详情如下表所示。

关键区别

Kubernetes 网络策略和安全组的主要区别，如下表所示。

网络策略（NetworkPolicy）

在 Kubernetes 集群中，默认情况下允许所有 Pod 到 Pod 的通信。尽管这种灵活性可能有助于降低网络复杂度，但它并不安全。Kubernetes 网络策略为您提供了一种机制，用于限制 Pod 之间的网络流量（通常称为 东西向流量）以及 Pod 和外部服务之间的网络流量。

Kubernetes 网络策略在 OSI 模型的第 3 层和第 4 层运行。网络策略使用 Pod、命名空间选择器和标签来识别源和目标 Pod，同时也可以包括 IP 地址、端口号、协议或这些内容的组合。网络策略可以应用于 Pod 的入站或出站连接，通常称为入口规则和出口规则。Kubernetes 网络策略需集群 CNI 插件支持，VKE 通过 VPC-CNI 插件原生集成此能力。

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

网络策略入门

当使用网络策略管控集群中的 Pod 流量时，常见的最佳实践是采用 最低权限原则，即首先禁止所有的 Pod 出站流量和入站流量，然后根据需求逐步放开指定的流量。实现集群中 Pod 流量的最小化原则。具体的操作流程，如下所示：

步骤一：创建默认拒绝策略

与 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

步骤三：逐步添加规则以选择性地允许命名空间/容器之间的流量流动

了解应用程序要求并根据需要创建细粒度的入口和出口规则。本例中以只允许 client-app 访问 backend-app 的 80 端口为例，这有助于最大限度地减少攻击面并降低未经授权访问的风险。

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

推荐工具

当您配置和使用网络策略时，可以使用以下常见的工具，学习、编写和验证网络策略的正确性和有效性。

安全组

安全组是火山引擎 VPC 提供的安全策略。安全组由一系列安全组规则组成，用于控制网卡的出入流量，每张网卡必须加入安全组。安全组基于白名单原理设计，故网卡的流量必须被安全组允许才会放通。

在容器服务中配置安全组的最佳实践，请参见 安全组配置最佳实践。

服务网格

什么是服务网格？

服务网格是专为应用程序设计的独立基础设施层。它允许透明地为应用添加可观测性、流量管理和安全能力，而无需修改业务代码。

• 工作层级：服务网格的策略实施作用于 OSI 模型的第 7 层（应用层）（如 HTTP/gRPC）。
• 常见工具：Istio、Linkerd 以及火山引擎 微服务引擎（MSE）（完美兼容 ISTIO）等。

何时使用服务网格进行策略实施？

1. 已有服务网格技术投入：如果团队已部署服务网格（如 Istio），可复用其能力。
2. 需要高级功能，包括：
   • 流量管理：负载均衡、熔断、限流、超时控制等。
   • 可观测性：获取服务性能的详细指标（延迟、错误率、QPS、请求量等）。
   • 安全增强：通过双向 TLS（mTLS）加密服务间通信。

何时选择 Kubernetes 网络策略？

1. 简单场景需求：仅需限制 Pod 之间的通信权限（如按命名空间或标签隔离）。
2. 资源效率优先：网络策略的资源消耗远低于服务网格，适合小型集群或无需复杂流量控制的场景。

关键区别

网络加密

配置 HTTPS 类型的外部负载均衡器（Service 层）

配置 Service 时基于如下注解，能够快速部署 HTTPS 加密的负载均衡器。

方案优势：

• 全链路加密：通过 HTTPS 保护用户到负载均衡器的流量，避免中间人攻击。
• 自动化管理：集成火山引擎 CLB 的证书服务，支持证书自动续期与绑定。

配置 HTTPS 类型的 Ingress

通过 Ingress 资源实现七层路由的 HTTPS 加密，适用于复杂路由场景（如多域名、多路径）。

前提条件

• 在火山引擎控制台完成域名备案及 SSL 证书配置。
• 已创建 ALBInstance，详情请参见 通过 kubectl 创建 ALB Ingress。

配置步骤

使用如下 YAML 配置，创建 HTTPS 类型的 ALB Ingress。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: alb-ingress-demo # 路由规则的名称
  namespace: default  # 路由规则所属的命名空间
  annotations:
    ingress.vke.volcengine.com/loadbalancer-port: "443" # 监听器端口号
    ingress.vke.volcengine.com/loadbalancer-protocol: "https"  # 监听器协议。本例中取值为 https
spec:
  ingressClassName: alb  # ALB Instance 的资源名称
  rules:
  - host: example.com  # 需要对外提供访问的域名
    http:
      paths:
      - pathType: Prefix # 路径匹配规则，默认为 Prefix（前缀匹配）
        path: / # 请求匹配的路径
        backend:
          service:
            name: service-demo # 需要对接的服务名称
            port: 
              number: 80 # 需要对接服务的端口号

方案优势：

• 统一入口加密：集中管理多服务的 HTTPS 流量，降低配置复杂度。
• 灵活路由策略：支持按域名/路径分流，同时保障加密安全。

在服务网格中配置 mTLS

在 Istio 中管理 TLS 版本时，若需去掉证书管理部分（如证书生成、更新等），可通过以下方式直接配置 TLS 协议版本。

全局配置最低 TLS 版本

通过 Istio 的安装配置文件IstioOperator指定全局最低 TLS 协议版本。例如，强制所有工作负载使用 TLS 1.3 及以上版本。

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    meshMTLS:
      minProtocolVersion: TLSv1_3

此配置会在Istio控制平面安装时生效，所有服务通信将仅支持 TLS 1.3。

基于命名空间或工作负载的细粒度控制

可以为特定命名空间或服务单独配置 TLS 版本，可通过PeerAuthentication资源实现。

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: tls-policy
  namespace: foo
spec:
  mtls:
    mode: STRICT
  portLevelMtls:
    8080:
      mode: STRICT
  minProtocolVersion: TLSv1_3

此策略会覆盖全局配置，仅对命名空间foo下的服务生效。

与自动双向 TLS 的兼容性

Istio 的 自动双向 TLS（Auto mTLS） 功能会根据工作负载是否注入 Sidecar 自动协商加密方式。当配置最低 TLS 版本后，Auto mTLS 会遵循该限制，仅使用符合版本的协议。