• Pod によって送信されるマルチキャストパケットは、NetworkPolicy オブジェクトに関係なく、プロジェクトの他のすべての Pod に送信されます。Pod はユニキャストで通信できない場合でもマルチキャストで通信できます。
• 1 つのプロジェクトの Pod によって送信されるマルチキャストパケットは、NetworkPolicy オブジェクトがプロジェクト間の通信を許可する場合であっても、それ以外のプロジェクトの Pod に送信されることはありません。

• Pod で送信されるマルチキャストパケットはプロジェクトにあるその他の全 Pod に送信されます。
• あるプロジェクトの Pod によって送信されるマルチキャストパケットは、各プロジェクトが結合し、マルチキャストが結合した各プロジェクトで有効にされている場合にのみ、他のプロジェクトの Pod に送信されます。

前提条件

• OpenShift CLI (oc) がインストールされている。
• cluster-admin または dedicated-admin ロールを持つユーザーでクラスターにログインする必要があります。

手順

• 以下のコマンドを実行し、プロジェクトのマルチキャストを有効にします。<namespace> を、マルチキャストを有効にする必要のある 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 引数を使用する場合、信頼バンドルはトラストストアに追加され、クラスターシステムの egress トラフィックの検証に使用されます。このシナリオでは、バンドルがプロキシーで使用するように設定されていません。

  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 フィールドで定義されるネットワークに含まれていないワーカーをスケールアップする場合、それらをこの一覧に追加し、接続の問題を防ぐ必要があります。

  httpProxy または httpsProxy フィールドのいずれも設定されていない場合に、このフィールドは無視されます。

前提条件

• Red Hat OpenShift Service on AWS クラスターがある。
• クラスターが 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 引数を使用する場合、信頼バンドルはトラストストアに追加され、クラスターシステムの egress トラフィックの検証に使用されます。このシナリオでは、バンドルがプロキシーで使用するように設定されていません。

  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 フィールドで定義されるネットワークに含まれていないワーカーをスケールアップする場合、それらをこの一覧に追加し、接続の問題を防ぐ必要があります。

  httpProxy または httpsProxy フィールドのいずれも設定されていない場合に、このフィールドは無視されます。

前提条件

• クラスター管理者の権限がある。
• rosa CLI ツールをインストールしている。

手順

• rosa edit コマンドを使用して、プロキシーを変更します。--http-proxy および --https-proxy 引数に空の文字列を渡して、クラスターからプロキシーをクリアする必要があります。

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

  注記

  プロキシーはプロキシー引数の 1 つしか使用しない場合がありますが、空のフィールドは無視されるため、空の文字列を --http-proxy 引数と --https-proxy 引数の両方に渡しても問題は発生しません。

  出力例

  I: Updated cluster <cluster_name>

検証

• rosa describe コマンドを使用して、プロキシーがクラスターから削除されたことを確認できます。

  $ rosa describe cluster -c <cluster_name>

  削除する前に、プロキシー IP がプロキシーセクションに表示されます。

  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 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>

• すべてのトラフィックを拒否します。

  プロジェクトに deny by default (デフォルトで拒否) を実行させるには、すべての Pod に一致するが、トラフィックを一切許可しない NetworkPolicy オブジェクトを追加します。

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

• Red Hat OpenShift Service on AWS Ingress コントローラーからの接続のみを許可します。

  プロジェクトで Red Hat OpenShift Service on AWS Ingress コントローラーからの接続のみを許可するには、以下の 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

• namespace および Pod セレクターの両方を使用して接続を受け入れます。

  namespace と 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

• namespace を使用して分離する必要のある Pod のグループを組み込み、OVS フロールールの数を減らします。

  namespace 全体を選択する NetworkPolicy オブジェクトは、namespaceSelectors または空の podSelectors を使用して、namespace の VXLAN 仮想ネットワーク ID に一致する単一の OVS フロールールのみを生成します。

• 分離する必要のない Pod は元の namespace に維持し、分離する必要のある Pod は 1 つ以上の異なる namespace に移します。
• 追加のターゲット設定された namespace 間のネットワークポリシーを作成し、分離された Pod から許可する必要のある特定のトラフィックを可能にします。

• 同じ spec.podSelector 仕様を持つネットワークポリシーの場合、ingress ルールまたは egress ルールを持つ複数のネットワークポリシーを使用するよりも、複数の Ingress ルールまたは egress ルールを持つ 1 つのネットワークポリシーを使用する方が効率的です。

• podSelector または namespaceSelector 仕様に基づくすべての Ingress または egress ルールは、number of pods selected by network policy + number of pods selected by ingress or egress rule に比例する数の OVS フローを生成します。そのため、Pod ごとに個別のルールを作成するのではなく、1 つのルールで必要な数の Pod を選択できる podSelector または namespaceSelector 仕様を使用することが推奨されます。

  たとえば、以下のポリシーには 2 つのルールが含まれています。

  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

  以下のポリシーは、上記と同じ 2 つのルールを 1 つのルールとして表現しています。

  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 仕様に適用されます。異なるネットワークポリシーに同じ ingress ルールまたは egress ルールがある場合、共通の spec.podSelector 仕様で 1 つのネットワークポリシーを作成する方が効率的な場合があります。たとえば、以下の 2 つのポリシーには異なるルールがあります。

  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

  以下のネットワークポリシーは、上記と同じ 2 つのルールを1 つのルールとして表現しています。

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

  この最適化は、複数のセレクターを 1 つのセレクターとして表現する場合に限り適用できます。セレクターが異なるラベルに基づいている場合、この最適化は適用できない可能性があります。その場合は、ネットワークポリシーの最適化に特化して新規ラベルをいくつか適用することを検討してください。

• ネットワークポリシーの作成

前提条件

• OpenShift Cluster Manager Hybrid Cloud Console にログインしている。
• Red Hat OpenShift Service on AWS クラスターを作成している。
• クラスターにアイデンティティープロバイダーを設定している。
• 設定したアイデンティティープロバイダーにユーザーアカウントを追加している。

前提条件

• クラスターが、NetworkPolicy オブジェクトをサポートするネットワークプラグインを使用している (例: mode: NetworkPolicy が設定された OpenShift SDN ネットワークプロバイダー)。このモードは OpenShiftSDN のデフォルトです。
• OpenShift CLI (oc) がインストールされている。
• admin 権限を持つユーザーとしてクラスターにログインしている。

前提条件

• OpenShift CLI (oc) がインストールされている。
• 管理者としてログインしている。
• あるポートを公開する Web アプリケーションと、そのポートでトラフィックをリッスンする TCP エンドポイントがあります。

検証

• 作成した route リソースを確認するには、次のコマンドを実行します。

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

  1

  この例では、ルートの名前は hello-openshift です。

前提条件

• 実行中のクラスターでデプロイ済みの Ingress コントローラーが必要になります。

• ルートごとに HSTS を有効にします。
• ルートごとに HSTS を無効にします。
• ドメインごとに HSTS を適用するか、ドメインと組み合わせた namespace ラベルを使用します。

前提条件

• 公開したいサービスがあります。
• 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 証明書が必要です。
• 公開する必要のあるサービスが必要です。

• reencrypt 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 証明書が必要です。
• 公開する必要のあるサービスが必要です。

• edge TLS termination およびカスタム証明書を使用して、セキュアな 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 termination を使用したセキュリティー保護されたルート

  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 は、エンドポイントでトラフィックに証明書を提供します。これは、必須となるクライアント証明書をサポートするための唯一の方法です (相互認証とも呼ばれる)。