VPCクラスタにおけるアウトバウンド・トラフィック保護の管理

仮想プライベートクラウド 4.15 そしてその後

Red Hat OpenShift on IBM Cloudの送信トラフィック保護を管理するための以下のオプションを確認してください。VPCクラスタ。 すべてのアウトバウンドアクセスを許可することも、アプリが必要とするコンポーネントへのアウトバウンドトラフィックを選択的に許可することもできます。

以下のシナリオの多くでは、特定のリソースへのアウトバウンド・トラフィックを許可する方法として、「kube-<clusterID> セキュリティ・グループにカスタム・ルールを追加するオプションがあります。 kube-<clusterID> セキュリティ・グループに追加したルールは、「ibmcloud oc security-group reset 後で実行すると削除されることに注意。 セキュリティグループをリセットすると、デフォルトのルールが復元され、追加したルールが削除されます。

送信トラフィック保護を無効にする

仮想プライベートクラウド 4.15 そしてその後

新しいクラスタの送信トラフィック保護を無効にするための以下のオプションを確認してください。

outbound traffic protection enable」と「disable コマンドを使用することで、アウトバウンド・トラフィックの保護のオンとオフを切り替えることができる。 すべてのアウトバウンドトラフィックを許可する設定から移行する場合、この2つの設定を切り替えるとよいでしょう。

オプション1：クラスタ作成時に送信トラフィック保護を無効にする

このオプションは、すべてのアウトバウンドネットワーク接続を許可する。

  • コンソールで、Allow outbound traffic オプションを選択する。
  • CLIでは、'cluster create vpc-gen2 コマンド を使用してクラスタを作成するときに、'--disable-outbound-traffic-protection オプションを指定します。
  • Terraformで'disable_outbound_traffic_protection = true オプションを指定する。
  • APIで「disableOutboundTrafficProtection=true オプションを指定する。

オプション2：カスタムセキュリティグループを通してアウトバウンドトラフィックを許可する

クラスタを作成する前に、クラスタがアクセスする必要がある外部サイトまたはサービスへのアクセスを許可する カスタムセキュリティグループ をVPCに作成します。 次に、クラスタ作成時にこのセキュリティ・グループをクラスタにアタッチします。

  • コンソールで、カスタムセキュリティグループを指定します。
  • CLIでは、'cluster create vpc-gen2 コマンド を使用してクラスタを作成するときに、'--cluster-security-group <security-group-ID> オプションを指定し、カスタム・セキュリティ・グループIDを含めます。
  • Terraformで'security_groups オプションを指定し、カスタムグループを含める。

既存クラスタのアウトバウンド・トラフィック保護を無効にする

仮想プライベートクラウド 4.15 そしてその後

クラスタのプロビジョニング後にアウトバウンド・トラフィック保護を無効にするオプションを確認してください。

オプション1：CLIから送信トラフィック保護を無効にする

このオプションは、すべての外部ネットワーク接続を許可する。

ibmcloud oc vpc outbound-traffic-protection disable --cluster CLUSTER

オプション 2: デフォルトのクラスタワーカーセキュリティグループにセキュリティグループルールを追加する

特定の外部サイトへのアクセスを許可するセキュリティグループルールをクラスタワーカーセキュリティグループ (kube-<clusterID>) に追加することができます。 クラスタがアクセスする必要のあるサイトまたはサブネットごとに、この手順を繰り返します。 詳しくは、アウトバウンドトラフィックを選択的に許可するシナリオ例 を参照してください。

ibmcloud is sg-rulec kube-CLUSTERID outbound icmp_tcp_udp --remote IP-ADDRESS-OR-SUBNET

既存クラスタのアウトバウンド・トラフィック保護を有効にする

仮想プライベートクラウド 4.15 そしてその後

既存の4.15クラスタでアウトバウンド・プロテクションを有効にするには、以下のコマンドを実行します。 アウトバウンド・トラフィック保護を有効にすると、すべてのアウトバウンド・トラフィックがブロックされることに注意してください。

ibmcloud oc vpc outbound-traffic-protection enable --cluster CLUSTER

アウトバウンド・トラフィックを選択的に許可するシナリオ例

quay.io などの外部コンテナー登録、Red Hat Marketplace、OperatorHub などの一般的なリソースやコンポーネントへの送信トラフィックを許可する方法については、以下のセクションを参照してください。 カスタムセキュリティグループルールを作成することによってアウトバウンドトラフィックを選択的に許可する場合、「ibmcloud oc security-group reset コマンドを実行してセキュリティグループをデフォルトの設定にリセットすると、変更が削除されることに注意してください。

DockerHub'quay.io ような外部コンテナ登録からイメージにアクセスする。

DockerHub'quay.io、'registry.redhat.com などのレジストリからイメージにアクセスするには、以下のオプションのいずれかを選択します。

  • 送信トラフィック保護を無効にする。
    ibmcloud oc vpc outbound-traffic-protection disable --cluster CLUSTER
  • アプリに必要な画像を'icr.io にミラーリングする。 これらの画像をIBM Cloud Container Registryにプル、タグ付け、プッシュします。 詳しくは、IBM Cloud Container Registryに画像をプッシュする を参照してください。

Red Hat Marketplaceと OperatorHubへのアウトバウンドトラフィックを許可する

以下の手順で、すべてのアウトバウンド・トラフィックを有効にする。 これを有効にしたくない場合は、 アプリに必要な「 Red Hat Marketplace 」および「 OperatorHub 」のイメージをミラーリングする を、ご自身の icr.io に置き換えてください。

  1. 送信トラフィック保護を無効にする。

    ibmcloud oc vpc outbound-traffic-protection disable --cluster CLUSTER

  2. クラスタ上のOperatorHubにパッチを適用して、ポッドを起動できるようにします。

    oc patch OperatorHub cluster --type json -p '[{"op": "remove", "path": "/spec/disableAllDefaultSources"}]'

これらの変更を後で戻し、「OperatorHub,無効にするには、以下の手順を実行する。

  1. アウトバウンド・トラフィック保護を有効にする。

    ibmcloud oc vpc outbound-traffic-protection enable --cluster CLUSTER

  2. クラスタのOperatorHubにパッチを当ててポッドを無効にする

    oc patch OperatorHub cluster --type json -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'

イメージストリームへのアウトバウンドトラフィックを許可する

クラスタからイメージストリームにアクセスするには、以下のオプションから選択します。

  • 必要な画像をレジストリ「icr.io」にミラーリングする。 詳しくは、IBM Cloud Container Registryに画像をプッシュする を参照してください。

  • 送信トラフィック保護を無効にする。

    ibmcloud oc vpc outbound-traffic-protection disable --cluster CLUSTER

  • 使用する画像ストリームのIPアドレスに対して、セキュリティグループルールを「kube-<clusterID> セキュリティグループに追加します。 画像ストリームのIPアドレスは変更される可能性がある。

    ibmcloud is sg-rulec kube-vpegw-<clusterID> inbound tcp --port-min PORT  --port-max PORT --remote IP-OR-CIDR

テレメトリーによる遠隔健康監視のためのアウトバウンド・トラフィックの許可

リモートヘルスモニタリングを許可するには、以下のコマンドを実行して、送信トラフィックの保護を無効にする必要があります。

ibmcloud oc vpc outbound-traffic-protection disable --cluster CLUSTER

VPE経由で4.15クラスタとWebコンソールにアクセスする

プライベートvpeゲートウェイ経由でのクラスタアクセスを許可するようにKubernetesを設定できます。 このオプションは、プライベートのみ、またはパブリックとプライベートの両方のVPCクラスタで使用できます。 アクセスはプライベート・エンドポイントを経由するため、顧客はクラスタにアクセスするためにクライアントからVPCにVPNを設定する必要がある。

4.15クラスタ以降、VPEアクセスを機能させるには、追加のセキュリティ・グループ・ルールが必要です。 追加のセキュリティ・グループ・ルールは、プライベート専用のクラスタと、パブリックおよびプライベートのエンドポイントを持つクラスタの両方に必要です。

  1. VPNサーバーをリストアップします。

    ibmcloud is vpn-servers

  2. VPNサーバーの詳細を取得します。

    ibmcloud is vpn-server SERVER

  3. VPNサーバーのクライアントIPプールを取得します。

    ibmcloud is vpn-server | grep "Client IP pool"

  4. クラスタの詳細を取得し、VPEポートをメモする。

    ibmcloud ks cluster get --cluster CLUSTERID

  5. クライアントでVPNを開始する。

  6. VPE経由でクラスタにアクセスします。

    ibmcloud ks cluster config --admin --cluster CLUSTERID --endpoint vpe

  7. ポッドをリストします。 クライアントがVPEゲートウェイを経由してVPN経由でクラスタにアクセスできないため、このコマンドは失敗することに注意してください。

    kubectl get pods -A

  8. kube-vpegw-<clusterID>」にVPN用のセキュリティグループルールを追加する。 この場合のリモートは、VPNのクライアントIPのCIDRに由来する。

    ibmcloud is sg-rulec kube-vpegw-<clusterID> inbound tcp --port-min PORT  --port-max PORT --remote IP-OR-CIDR

    コマンドの例。

    ibmcloud is sg-rulec kube-vpegw-<clusterID> inbound tcp --port-min 30829  --port-max 30829 --remote 192.168.192.0/22

  9. ポッドをリストします。

    kubectl get pods -A

ウェブフックのアウトバウンドトラフィックを許可する

URL またはクラスタ外部のサービスに連絡する Webhook を使用している場合は、クラスタワーカーから URL または外部サービスへの送信トラフィックを許可するセキュリティグループルールを追加する必要があります。 あるいは、送信トラフィックの保護を完全に無効にすることもできます。

通常、クラスタサービス参照を使用するアドミッションウェブフックでは、変更は必要ありません。

次の例では、クラスタ・サービスに接続するアドミッションWebhookは、マスターがデフォルトで許可されているKonnectivity接続を介してサービスに接続するため、通常は変更を必要としません。 例外は、そのクラスタサービスを実装しているポッドが、 URL または何らかの外部サービスに接続する必要がある場合です。 もしそうなら、この例に示すように、それらのポッドが URL または外部サービスにアクセスすることを許可する。

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: my-cluster-service.webhook.io
webhooks:
- admissionReviewVersions:
  - v1
  clientConfig:
    caBundle: ABCDEFG...
    service:
      name: my-admission-webhook
      namespace: default
      path: /validate
      port: 443
...

ただし、アドミッション・ウェブフックが URL を使用する場合は、追加のセキュリティー・グループ・ルールが必要です。

URL に接続するウェブフックの例。

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: my-url.webhook.io
webhooks:
- admissionReviewVersions:
  - v1
  clientConfig:
    caBundle: ABCDEFG...
    url: https://webhook.ibm.com:20001/validate
...

Webhook の外部 URL またはサービスへのアクセスを許可するには、以下のオ プションのいずれかを選択します

  • 以下のコマンドを実行して、送信トラフィック保護を無効にする。

    ibmcloud oc vpc outbound-traffic-protection disable --cluster CLUSTER

  • クラスターワーカーに接続を許可するために、'kube-<clusterID> セキュリティグループにアウトバウンドセキュリティグループルールを追加します。 前の例では、ポート「20001」の「webhook.ibm.com サービスが使われている。

    1. dig を使って、 URL にアクセスするためのIPを調べる。
        dig +short URL
    ```
    コマンドの例。
    ```sh {: pre}
    dig +short webhook.ibm.com
    ```
    出力例
    ```sh {: screen}
    1.2.3.4
    4.5.6.7
    ```
1. 返されたIPアドレスごとにルールを作成する。

```sh {: pre}
    ibmcloud is sg-rulec kube-<clusterID> outbound icmp_tcp_udp --remote <IP-address-or-subnet>
    ```
    コマンドの例。
    ```sh {: pre}
    ibmcloud is sg-rulec kube-CLUSTERID outbound tcp --port-min 20001 --port-max 20001 --remote 1.2.3.4
    ibmcloud is sg-rulec kube-CLUSTERID outbound tcp --port-min 20001 --port-max 20001 --remote 4.5.6.7
    ```

詳細については、「 動的アクセス制御 」を参照してください。

パブリック・サービスへのアウトバウンド・トラフィックを許可する

アプリケーションによって呼び出される外部サービスが、そのサービスをホストするために使用されるIP/CIDRの小さなセットを持っていて、それがあまり頻繁に変更されない場合、「kube-clusterID セキュリティグループ上でそれらのIPまたはCIDRへのアウトバウンドアクセスを選択的に許可することができます。

次の例では、github.comのAPIを'api.github.com で使用しています。

  1. curl によってIPをプログラムで検索する。

    curl -sS -H "Accept: application/vnd.github+json" https://api.github.com/meta | jq '.api'

  2. 前のステップで見つけた各CIDRを、「kube-clusterID セキュリティグループの送信セキュリティグループルールの宛先として追加する。 あるいは、クラスタ作成時にクラスタワーカーに追加するカスタムセキュリティグループを作成することもできます。

    ibmcloud is sg-rulec kube-<clusterID> outbound icmp_tcp_udp --remote <IP-address-or-subnet>

詳しくは GitHub'sのIPアドレス についてをご覧ください。

ハブおよびスポークVPCのアウトバウンド・トラフィック保護に関する考察

ハブ＆スポークモデルでは、DNS解決に使用されるのはハブのVPCクラスタのみです。 スポーククラスタはハブを経由してDNSにアクセスする。 ハブクラスタとスポーククラスタは多くの場合、異なるVPCにあり、それらはTransit Gatewayて接続されている。

バージョン4.15以降のクラスタでは、それぞれのセキュリティ・グループを調整しないと、ハブ＆スポーク・モデルは機能しません。 これらの調整により、ハブとスポークVPC間のトラフィックが可能になる。

  1. 各スポーククラスタの「kube-<clusterID> セキュリティグループにルールを追加して、スポークVPC内のクラスタがハブVPCにアクセスできるように更新します。 ハブクラスターワーカーが配置されている各VPC サブネットのCIDRに送信ルールを追加してください。 例えば、スポークが1つのハブに接続しており、そのハブに3つのゾーンにワーカーがいる場合、スポークの「kube-<clusterID> セキュリティグループに3つのルールを、各サブネットに1つずつ追加する必要があります。

    ibmcloud is sg-rulec kube-<spoke-clusterID> outbound icmp_tcp_udp --remote <hub-subnet-CIDR>

  2. ハブの共有VPEゲートウェイのセキュリティグループ（kube-vpegw-vpcID）にルールを追加して、スポークからのトラフィックを許可するようにハブクラスタを更新します。または、共有 VPE ゲートウェイに独自のカスタムセキュリティグループを使用している場合は、代わりにそのカスタムセキュリティグループにルールを追加します。

  3. 以下のコマンドを実行して、VPEゲートウェイを見つけ、ゲートウェイの詳細を見て、関連するセキュリティグループを見つける。 次のステップでルールを追加するために、セキュリティグループIDをメモしておく。

    ibmcloud is egs

  4. スポークワーカーが配置されている各VPC サブネットからインバウンドルールを追加します。 例えば、スポークが3つの異なるゾーンに配備されているが、それぞれのゾーンで1つのサブネットに配備されている場合、ハブの共有VPEゲートウェイのセキュリティグループに3つのルールが追加されます。

    ibmcloud is sg-rulec kube-vpegw-<hub-vpcID> inbound icmp_tcp_udp --remote <spoke-subnet-CIDR>

パブリックネットワーク経由でクラスタAPIサーバへの一時的なトラフィックを許可する

VPCクラスタワーカーはクラスタマスターとの通信にプライベートネットワークを使用します。 以前は、パブリックサービスのエンドポイントが有効になっているVPCクラスタでは、プライベートネットワークがブロックされているか利用できない場合、クラスタワーカーはクラスタマスタとの通信にパブリックネットワークを使用するようにフォールバックできました。

4.15以降のクラスタでは、クラスタワーカーからのパブリックアウトバウンドトラフィックがブロックされているため、パブリックネットワークにフォールバックすることはできません。 このパブリックネットワークバックアップオプションを許可するために、アウトバウンドトラフィックの保護を無効にしたいかもしれませんが、より良い選択肢があります。 その代わりに、プライベートネットワークを介したワーカーとマスターの接続に一時的な問題が発生した場合、その時点でクラスタマスター「apiserver ポートへのアウトバウンドトラフィックを許可する一時的なセキュリティグループルールを「kube-clusterID セキュリティグループに追加することができます。 その後、問題が解決したら、一時的なルールを削除することができる。

プライベート・ネットワークがダウンしている場合にパブリック・ネットワーク経由のトラフィックを許可するには、以下のオプションのいずれかを選択します。

  • kube-clusterID セキュリティグループに、APIサーバーへのトラフィックを許可するセキュリティグループルールを追加する。

    1. クラスタの詳細を取得し、APIサーバーのポートを控えておいてください。
        ic ks cluster get --cluster <clusterID>
    ```
    APIサーバーのポートが「`30685` である場合の出力例。

    ```sh {: screen}
    Name:                           prestg-sbd-vpc-4.15
    ID:                             coekl4a107ovqfndhh60
    ...
    Public Service Endpoint URL:    https://c100-e.containers.cloud.ibm.com:30685
    Private Service Endpoint URL:   https://c100.private.containers.cloud.ibm.com:30685
    ...
    ```
1. `kube-<clusterID>`」から「`0.0.0.0/0`」への送信セキュリティグループルールを追加し、すべてのパブリックネットワークアクセスを許可する。
```sh {: pre}
    ibmcloud is sg-rulec kube-<clusterID> outbound tcp --port-min <API port> --port-max <API port> --remote 0.0.0.0/0
    ```
    APIサーバーのポートを'`30685` とした場合のコマンド例。
    ```sh {: pre}
    ibmcloud is sg-rulec kube-<clusterID> outbound tcp --port-min 30685 --port-max 30685 --remote 0.0.0.0/0
    ```

  • 送信トラフィック保護を無効にする。

    ibmcloud oc vpc outbound-traffic-protection disable --cluster CLUSTER

プライベート専用RHCOSクラスタでのSysdig統合の検証

sysdig-agent ポッドが RHCOS ワーカーを使用するプライベート専用クラスタ上の CrashLoopBackOff にある場合、送信トラフィック保護を無効にするか、 eBPF ドライバを使用するように Sysdig エージェントを更新します。 詳細については、 プライベート専用のRHCOSクラスタ上で sysdig-agent ポッドが CrashLoopBackOff 、なぜ ポッドが を参照してください。