• pod 发送的多播数据包将传送到项目中的所有其他 pod，而无需考虑 NetworkPolicy 对象。即使在无法通过单播通信时，Pod 也能通过多播进行通信。
• 一个项目中的 pod 发送的多播数据包不会传送到任何其他项目中的 pod，即使存在允许项目间通信的 NetworkPolicy 对象。

• pod 发送的多播数据包将传送到项目中的所有其他 pod。
• 只有在各个项目接合在一起并且每个接合的项目上都启用了多播时，一个项目中的 pod 发送的多播数据包才会传送到其他项目中的 pod。

先决条件

• 安装 OpenShift CLI (oc) 。
• 您必须使用具有 cluster-admin 或 dedicated-admin 角色的用户登录集群。

流程

• 运行以下命令，为项目启用多播。使用您要启用多播的项目的名称替换 <namespace>。

  $ oc annotate netnamespace <namespace> \
      netnamespace.network.openshift.io/multicast-enabled=true

先决条件

• 您已确认代理可以从安装集群的 VPC 访问。该代理还必须从 VPC 的专用子网访问。

流程

• 指定创建集群时的代理配置：

  $ rosa create cluster \
   <other_arguments_here> \
   --additional-trust-bundle-file <path_to_ca_bundle_file> \ 1 2 3
   --http-proxy http://<username>:<password>@<ip>:<port> \ 4 5
   --https-proxy https://<username>:<password>@<ip>:<port> \ 6 7
   --no-proxy example.com 8

  1 4 6

  additional-trust-bundle-file、http-proxy 和 https-proxy 参数都是可选。

  2

  如果您使用没有 http-proxy 或 https-proxy 参数的 additional-trust-bundle-file 参数，则会将信任捆绑包添加到信任存储中，并用来验证集群系统出口流量。在这种情况下，捆绑包没有配置为与代理一起使用。

  3

  additional-trust-bundle-file 参数是一个指向 PEM 编码 X.509 证书的捆绑包的文件路径，这些证书全部连接在一起。additionalTrustBundle 参数是必需的，除非代理的身份证书由来自 RHCOS 信任捆绑包的颁发机构签名。如果您使用不要求额外代理配置但需要额外 CA 的 MITM 透明代理网络，您必须提供 MITM CA 证书。

  5 7

  http-proxy 和 https-proxy 参数必须指向有效的 URL。

  8

  要排除代理的目标域名、IP 地址或网络 CIDR 的逗号分隔列表。

  在域前面加上 . 以仅匹配子域。例如： .y.com 匹配 x.y.com，但不匹配 y.com。使用 * 可对所有目的地绕过所有代理。如果您扩展了未包含在安装配置中 networking.machineNetwork[].cidr 字段定义的 worker，您必须将它们添加到此列表中，以防止连接问题。

  如果未设置 httpProxy 或 httpsProxy 字段，则此字段将被忽略。

前提条件

• 在 AWS 集群上有一个 Red Hat OpenShift Service。
• 您的集群部署在 VPC 中。

验证

• 在 Networking 页面上的 Virtual Private Cloud (VPC) 部分下，验证集群的代理配置是否如预期。

前提条件

• 您已在安装主机上安装和配置了最新的 ROSA (rosa) 和 OpenShift (oc) CLI。
• 您有一个在 VPC 中部署的 ROSA 集群。

流程

• 编辑集群配置以添加或删除集群范围代理详情：

  $ rosa edit cluster \
   --cluster $CLUSTER_NAME \
   --additional-trust-bundle-file <path_to_ca_bundle_file> \ 1 2 3
   --http-proxy http://<username>:<password>@<ip>:<port> \ 4 5
   --https-proxy https://<username>:<password>@<ip>:<port> \ 6 7
    --no-proxy example.com 8

  1 4 6

  additional-trust-bundle-file、http-proxy 和 https-proxy 参数都是可选。

  2

  如果您使用没有 http-proxy 或 https-proxy 参数的 additional-trust-bundle-file 参数，则会将信任捆绑包添加到信任存储中，并用来验证集群系统出口流量。在这种情况下，捆绑包没有配置为与代理一起使用。

  3

  additional-trust-bundle-file 参数是一个指向 PEM 编码 X.509 证书的捆绑包的文件路径，这些证书全部连接在一起。additionalTrustBundle 参数是必需的，除非代理的身份证书由来自 RHCOS 信任捆绑包的颁发机构签名。如果您使用不要求额外代理配置但需要额外 CA 的 MITM 透明代理网络，您必须提供 MITM CA 证书。

  注意

  您不应该尝试在集群中直接更改代理或其他信任捆绑包配置。这些更改必须使用 ROSA CLI (rosa) 或 Red Hat OpenShift Cluster Manager 加以应用。直接对集群所做的任何更改都会被自动恢复。

  5 7

  http-proxy 和 https-proxy 参数必须指向有效的 URL。

  8

  要排除代理的目标域名、IP 地址或网络 CIDR 的逗号分隔列表。

  在域前面加上 . 以仅匹配子域。例如： .y.com 匹配 x.y.com，但不匹配 y.com。使用 * 可对所有目的地绕过所有代理。如果您扩展了未包含在安装配置中 networking.machineNetwork[].cidr 字段定义的 worker，您必须将它们添加到此列表中，以防止连接问题。

  如果未设置 httpProxy 或 httpsProxy 字段，则此字段将被忽略。

前提条件

• 您必须具有集群管理员特权。
• 已安装 ROSA CLI (rosa)。

流程

• 使用 rosa edit 命令修改代理。您必须将空字符串传递给 --http-proxy 和 --https-proxy 参数，才能清除集群中的代理：

  $ rosa edit cluster -c <cluster_name> --http-proxy "" --https-proxy ""

  注意

  虽然代理可能只使用一个代理参数，但空字段将被忽略，因此将空字符串传递给 --http-proxy 和 --https-proxy 参数不会造成任何问题。

  输出示例

  I: Updated cluster <cluster_name>

验证

• 您可以使用 rosa describe 命令验证代理是否已从集群中删除：

  $ rosa describe cluster -c <cluster_name>

  在删除前，代理 IP 会显示在 proxy 部分：

  Name:                       <cluster_name>
  ID:                         <cluster_internal_id>
  External ID:                <cluster_external_id>
  OpenShift Version:          4.13.0
  Channel Group:              stable
  DNS:                        <dns>
  AWS Account:                <aws_account_id>
  API URL:                    <api_url>
  Console URL:                <console_url>
  Region:                     us-east-1
  Multi-AZ:                   false
  Nodes:
   - Control plane:           3
   - Infra:                   2
   - Compute:                 2
  Network:
   - Type:                    OVNKubernetes
   - Service CIDR:            <service_cidr>
   - Machine CIDR:            <machine_cidr>
   - Pod CIDR:                <pod_cidr>
   - Host Prefix:             <host_prefix>
  Proxy:
   - HTTPProxy:               <proxy_url>
  Additional trust bundle:    REDACTED

  删除代理后，代理部分会被删除：

  Name:                       <cluster_name>
  ID:                         <cluster_internal_id>
  External ID:                <cluster_external_id>
  OpenShift Version:          4.13.0
  Channel Group:              stable
  DNS:                        <dns>
  AWS Account:                <aws_account_id>
  API URL:                    <api_url>
  Console URL:                <console_url>
  Region:                     us-east-1
  Multi-AZ:                   false
  Nodes:
   - Control plane:           3
   - Infra:                   2
   - Compute:                 2
  Network:
   - Type:                    OVNKubernetes
   - Service CIDR:            <service_cidr>
   - Machine CIDR:            <machine_cidr>
   - Pod CIDR:                <pod_cidr>
   - Host Prefix:             <host_prefix>
  Additional trust bundle:    REDACTED

前提条件

• 您必须具有集群管理员特权。
• 已安装 ROSA CLI (rosa)。
• 集群添加了证书颁发机构。

流程

• 使用 rosa edit 命令修改 CA 信任捆绑包。您必须将空字符串传递给 --additional-trust-bundle-file 参数，以便从集群中清除信任捆绑包：

  $ rosa edit cluster -c <cluster_name> --additional-trust-bundle-file ""

  输出示例

  I: Updated cluster <cluster_name>

验证

• 您可以使用 rosa describe 命令验证信任捆绑包是否已从集群中删除：

  $ rosa describe cluster -c <cluster_name>

  在删除前，会显示额外的信任捆绑包部分，以便将其值用于安全目的：

  Name:                       <cluster_name>
  ID:                         <cluster_internal_id>
  External ID:                <cluster_external_id>
  OpenShift Version:          4.13.0
  Channel Group:              stable
  DNS:                        <dns>
  AWS Account:                <aws_account_id>
  API URL:                    <api_url>
  Console URL:                <console_url>
  Region:                     us-east-1
  Multi-AZ:                   false
  Nodes:
   - Control plane:           3
   - Infra:                   2
   - Compute:                 2
  Network:
   - Type:                    OVNKubernetes
   - Service CIDR:            <service_cidr>
   - Machine CIDR:            <machine_cidr>
   - Pod CIDR:                <pod_cidr>
   - Host Prefix:             <host_prefix>
  Proxy:
   - HTTPProxy:               <proxy_url>
  Additional trust bundle:    REDACTED

  删除代理后，额外的信任捆绑包会被删除：

  Name:                       <cluster_name>
  ID:                         <cluster_internal_id>
  External ID:                <cluster_external_id>
  OpenShift Version:          4.13.0
  Channel Group:              stable
  DNS:                        <dns>
  AWS Account:                <aws_account_id>
  API URL:                    <api_url>
  Console URL:                <console_url>
  Region:                     us-east-1
  Multi-AZ:                   false
  Nodes:
   - Control plane:           3
   - Infra:                   2
   - Compute:                 2
  Network:
   - Type:                    OVNKubernetes
   - Service CIDR:            <service_cidr>
   - Machine CIDR:            <machine_cidr>
   - Pod CIDR:                <pod_cidr>
   - Host Prefix:             <host_prefix>
  Proxy:
   - HTTPProxy:               <proxy_url>

• 拒绝所有流量：

  要使项目默认为拒绝流量，请添加一个匹配所有 pod 但不接受任何流量的 NetworkPolicy 对象：

  kind: NetworkPolicy
  apiVersion: networking.k8s.io/v1
  metadata:
    name: deny-by-default
  spec:
    podSelector: {}
    ingress: []

• 只允许 AWS Ingress Controller 上的 Red Hat OpenShift Service 的连接：

  要使项目只允许 AWS Ingress Controller 上的 Red Hat OpenShift Service 的连接，请添加以下 NetworkPolicy 对象。

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-from-openshift-ingress
  spec:
    ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            network.openshift.io/policy-group: ingress
    podSelector: {}
    policyTypes:
    - Ingress

• 只接受项目中 pod 的连接：

  要使 pod 接受同一项目中其他 pod 的连接，但拒绝其他项目中所有 pod 的连接，请添加以下 NetworkPolicy 对象：

  kind: NetworkPolicy
  apiVersion: networking.k8s.io/v1
  metadata:
    name: allow-same-namespace
  spec:
    podSelector: {}
    ingress:
    - from:
      - podSelector: {}

• 仅允许基于 pod 标签的 HTTP 和 HTTPS 流量：

  要对带有特定标签（以下示例中的 role=frontend）的 pod 仅启用 HTTP 和 HTTPS 访问，请添加类似如下的 NetworkPolicy 对象：

  kind: NetworkPolicy
  apiVersion: networking.k8s.io/v1
  metadata:
    name: allow-http-and-https
  spec:
    podSelector:
      matchLabels:
        role: frontend
    ingress:
    - ports:
      - protocol: TCP
        port: 80
      - protocol: TCP
        port: 443

• 使用命名空间和 pod 选择器接受连接：

  要通过组合使用命名空间和 pod 选择器来匹配网络流量,您可以使用类似如下的 NetworkPolicy 对象：

  kind: NetworkPolicy
  apiVersion: networking.k8s.io/v1
  metadata:
    name: allow-pod-and-namespace-both
  spec:
    podSelector:
      matchLabels:
        name: test-pods
    ingress:
      - from:
        - namespaceSelector:
            matchLabels:
              project: project_name
          podSelector:
            matchLabels:
              name: test-pods

• 使用命名空间使其包含需要隔离的 pod 组，可以减少 OVS 流规则数量。

  使用 namespaceSelector 或空 podSelector 选择整个命名空间的NetworkPolicy 对象会只生成 一个与命名空间的 VXLAN 虚拟网络 ID（VNID）匹配的 OVS 流量规则。

• 保留不需要在原始命名空间中隔离的 pod，并将需要隔离的 pod 移到一个或多个不同的命名空间中。
• 创建额外的目标跨命名空间网络策略，以允许来自不同隔离的 pod 的特定流量。

• 对于具有相同 spec.podSelector spec 的网络策略，使用带有多个 ingress 或 egress 规则的一个网络策略比带有 ingress 或 egress 子集的多个网络策略更高效。

• 每个基于 podSelector 或 namespaceSelector spec 的 ingress 或 egress 规则会生成一个的 OVS 流数量，它与由网络策略选择的 pod 数量 + 由 ingress 或 egress 选择的 pod 数量成比例因此，最好使用在一个规则中可以选择您所需的 pod 的 podSelector 或 namespaceSelector 规格，而不是为每个 pod 创建单独的规则。

  例如，以下策略包含两个规则：

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
   name: test-network-policy
  spec:
    podSelector: {}
    ingress:
      - from:
         - podSelector:
             matchLabels:
               role: frontend
      - from:
         - podSelector:
             matchLabels:
               role: backend

  以下策略表示这两个规则与以下相同的规则：

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
   name: test-network-policy
  spec:
    podSelector: {}
    ingress:
      - from:
         - podSelector:
             matchExpressions:
               - {key: role, operator: In, values: [frontend, backend]}

  相同的指南信息适用于 spec.podSelector spec。如果不同的网络策略有相同的 ingress 或 egress 规则，则创建一个带有通用的 spec.podSelector spec 可能更有效率。例如，以下两个策略有不同的规则：

  metadata:
   name: policy1
  spec:
   podSelector:
     matchLabels:
       role: db
    ingress:
      - from:
         - podSelector:
             matchLabels:
               role: frontend
  
  metadata:
   name: policy2
  spec:
   podSelector:
     matchLabels:
       role: client
    ingress:
      - from:
         - podSelector:
             matchLabels:
               role: frontend

  以下网络策略将这两个相同的规则作为一个：

  metadata:
   name: policy3
  spec:
   podSelector:
     matchExpressions:
       - {key: role, operator: In, values: [db, client]}
    ingress:
      - from:
         - podSelector:
             matchLabels:
               role: frontend

  当只有多个选择器表示为一个选择器时，您可以应用此优化。如果选择器基于不同的标签，则可能无法应用此优化。在这些情况下，请考虑为网络策略优化应用一些新标签。

• 创建网络策略

前提条件

• 已登陆到 OpenShift Cluster Manager Hybrid Cloud Console。
• 您在 AWS 集群上创建了 Red Hat OpenShift Service。
• 已为集群配置身份提供程序。
• 将您的用户帐户添加到配置的身份提供程序中。

前提条件

• 集群使用支持 NetworkPolicy 对象的网络插件，如设置了 mode: NetworkPolicy 的 OpenShift SDN 网络供应商。此模式是 OpenShift SDN 的默认模式。
• 已安装 OpenShift CLI（oc）。
• 您可以使用具有 admin 权限的用户登陆到集群。

前提条件

• 已安装 OpenShift CLI（oc）。
• 以管理员身份登录。
• 您有一个 web 应用，用于公开端口和侦听端口上流量的 TCP 端点。

验证

• 要验证您创建的路由资源，请运行以下命令：

  $ oc get routes -o yaml <name of resource> 1

  1

  在本例中，路由名为 hello-openshift。

前提条件

• 您需要在运行的集群中部署了 Ingress Controller。

• 根据每个路由启用 HSTS
• 根据每个路由禁用 HSTS
• 对一组域强制每个域的 HSTS，或者结合使用命名空间标签与域

前提条件

• 您有一个要公开的服务。
• 您可以访问 OpenShift CLI(oc)。

验证

• 运行以下命令，验证 Red Hat OpenShift Service on AWS 是否为 Ingress 对象创建了预期的路由：

  $ oc get routes -o yaml

  输出示例

  apiVersion: v1
  items:
  - apiVersion: route.openshift.io/v1
    kind: Route
    metadata:
      name: frontend-j9sdd 1
      ...
    spec:
    ...
      tls: 2
        insecureEdgeTerminationPolicy: Redirect
        termination: edge 3
    ...

  1

  路由的名称包括 Ingress 对象的名称，后跟一个随机的后缀。

  2

  要使用默认证书，路由不应指定 spec.certificate。

  3

  路由应指定 edge 终止策略。

前提条件

• 您可以在 PEM 编码文件中有一个证书/密钥对，其中的证书对路由主机有效。
• 您可以在 PEM 编码文件中有一个单独的 CA 证书来补全证书链。
• 您必须在 PEM 编码文件中有单独的目标 CA 证书。
• 您必须具有要公开的服务。

前提条件

• 您必须在 PEM 编码文件中有一个证书/密钥对，其中的证书对路由主机有效。
• 您可以在 PEM 编码文件中有一个单独的 CA 证书来补全证书链。
• 您必须在 PEM 编码文件中有单独的目标 CA 证书。
• 您必须具有要公开的服务。

• 使用重新加密 TLS 终止和自定义证书，创建安全 Route 资源：

  $ oc create route reencrypt --service=frontend --cert=tls.crt --key=tls.key --dest-ca-cert=destca.crt --ca-cert=ca.crt --hostname=www.example.com

  如果您检查生成的 Route 资源，它应该类似于如下：

  安全路由 YAML 定义

  apiVersion: route.openshift.io/v1
  kind: Route
  metadata:
    name: frontend
  spec:
    host: www.example.com
    to:
      kind: Service
      name: frontend
    tls:
      termination: reencrypt
      key: |-
        -----BEGIN PRIVATE KEY-----
        [...]
        -----END PRIVATE KEY-----
      certificate: |-
        -----BEGIN CERTIFICATE-----
        [...]
        -----END CERTIFICATE-----
      caCertificate: |-
        -----BEGIN CERTIFICATE-----
        [...]
        -----END CERTIFICATE-----
      destinationCACertificate: |-
        -----BEGIN CERTIFICATE-----
        [...]
        -----END CERTIFICATE-----

  如需了解更多选项，请参阅 oc create route reencrypt --help。

前提条件

• 您必须在 PEM 编码文件中有一个证书/密钥对，其中的证书对路由主机有效。
• 您可以在 PEM 编码文件中有一个单独的 CA 证书来补全证书链。
• 您必须具有要公开的服务。

• 使用边缘 TLS 终止和自定义证书，创建安全 Route 资源。

  $ oc create route edge --service=frontend --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=www.example.com

  如果您检查生成的 Route 资源，它应该类似于如下：

  安全路由 YAML 定义

  apiVersion: route.openshift.io/v1
  kind: Route
  metadata:
    name: frontend
  spec:
    host: www.example.com
    to:
      kind: Service
      name: frontend
    tls:
      termination: edge
      key: |-
        -----BEGIN PRIVATE KEY-----
        [...]
        -----END PRIVATE KEY-----
      certificate: |-
        -----BEGIN CERTIFICATE-----
        [...]
        -----END CERTIFICATE-----
      caCertificate: |-
        -----BEGIN CERTIFICATE-----
        [...]
        -----END CERTIFICATE-----

  如需了解更多选项，请参阅 oc create route edge --help。

前提条件

• 您必须具有要公开的服务。

流程

• 创建 Route 资源：

  $ oc create route passthrough route-passthrough-secured --service=frontend --port=8080

  如果您检查生成的 Route 资源，它应该类似于如下：

  使用 Passthrough 终止的安全路由

  apiVersion: route.openshift.io/v1
  kind: Route
  metadata:
    name: route-passthrough-secured 1
  spec:
    host: www.example.com
    port:
      targetPort: 8080
    tls:
      termination: passthrough 2
      insecureEdgeTerminationPolicy: None 3
    to:
      kind: Service
      name: frontend

  1

  对象的名称，长度限于 63 个字符。

  2

  termination 字段设置为 passthrough。这是唯一需要 tls 的字段。

  3

  可选的 insecureEdgeTerminationPolicy。禁用后唯一有效的值是 None、Redirect 或为空。

  目标 pod 负责为端点上的流量提供证书。目前，这是唯一支持需要客户端证书的方法，也称双向验证。