GKE Ingress のトラフィックを保護する

Autopilot Standard

このページでは、Google Kubernetes Engine（GKE）Ingress のトラフィックを保護して最適化する方法について説明します。クライアントとロードバランサ間の SSL 証明書を構成し、ロードバランサとバックエンド アプリケーション間のトラフィックを保護できます。続行する前に、GKE が HTTPS で Ingress を保護する方法を理解しておいてください。

このページは、組織のネットワークを設計し、ネットワーク機器の設置、構成、サポートを行うネットワーク スペシャリストを対象としています。Google Cloud のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE ユーザーのロールとタスクをご覧ください。

クライアントとロードバランサ間のトラフィックを保護して最適化する

クライアントからの HTTPS リクエストを受け入れるには、ロードバランサはクライアントに ID を証明するための証明書を持っている必要があります。さらに、ロードバランサには、HTTPS handshake を完了するための秘密鍵も必要です。HTTP(S) ロードバランサに SSL 証明書を提供する方法については、クライアントとロードバランサ間の TLS を構成するをご覧ください。

Google マネージド証明書を使用する

1 つ以上の Google マネージド SSL 証明書を構成して Ingress と関連付けるには、次の操作を行う必要があります。

• Ingress と同じ Namespace に 1 つ以上の ManagedCertificate オブジェクトを作成します。ロードバランサに最大 15 個の証明書を指定できます。
• networking.gke.io/managed-certificates アノテーションを Ingress に追加して、ManagedCertificate オブジェクトを Ingress に関連付けます。このアノテーションは、ManagedCertificate オブジェクトのカンマ区切りリストです。

注: Ingress で Google マネージド SSL 証明書を使用しても、Ingress トラフィック ルールの構成方法には影響しません。

制限事項

このセクションでは、Google マネージド証明書の制限事項について説明します。セルフマネージド証明書が必要な場合、または Ingress で構成する SSL 証明書がすでにある場合は、クライアントとロードバランサ間の HTTPS（TLS）の設定をご覧ください。

• Google マネージド証明書は、自分で取得して管理する証明書と比べてあまり柔軟性がありません。Google マネージド証明書は、最大 100 個の非ワイルドカード ドメインをサポートします。セルフ マネージド証明書とは異なり、Google マネージド証明書はワイルドカード ドメインをサポートしません。

• Ingress でサポートされている証明書の数と種類は、Google マネージド SSL 証明書の制限に応じて定義されます。

• Google マネージド証明書に対する更新はサポートされていません。詳細については、Google マネージド証明書の手動更新をご覧ください。

• 証明書が認証局によって直接取り消された場合、Google は証明書を自動的にローテーションしません。ManagedCertificate を削除して、新しい証明書を作成する必要があります。

• GKE Ingress は、Certificate Manager で管理される証明書をサポートしていません。Certificate Manager で管理される証明書を使用するには、Gateway API を使用します。

警告: Ingress リソースによって作成されたロードバランサのターゲット プロキシは、最大 15 個の Compute Engine SSL 証明書を参照できます。Ingress アノテーション ingress.gcp.kubernetes.io/pre-shared-cert には、ロードバランサのターゲット プロキシでプロビジョニングされたすべての SSL 証明書 managed-certificates と self-managed が含まれます。

前提条件

• ドメイン名を所有している必要があります。ドメイン名は 63 文字以下にする必要があります。ドメイン名は、任意のドメイン名登録事業者から取得できます。

  注: Google Domains はサービスを終了しました。以前に Google Domains から購入したドメインは、Squarespace が管理するようになりました。ドメインと DNS レコードは、Squarespace のアカウントから管理できます。

• GKE Standard クラスタを使用する場合は、HttpLoadBalancing アドオンを有効にする必要があります。

• Ingress マニフェストには kubernetes.io/ingress.class: "gce" アノテーションを含める必要があります。ingressClassName フィールドはサポートされていません

• Ingress リソースと ManagedCertificate リソースは、同じプロジェクトと Namespace に適用する必要があります。

• 予約済み（静的）外部 IP アドレスを作成します。静的 IP アドレスを予約すると、Ingress を削除した場合でも、その IP アドレスが自身のものであることが保証されます。IP アドレスを予約しないと、アドレスが変わりドメインの DNS レコードを再構成することが必要となることがあります。Google Cloud CLI または Google Cloud コンソールを使用して、予約済み IP アドレスを作成します。

  gcloud

  予約済み IP アドレスを作成するには、次のコマンドを実行します。

  gcloud compute addresses create ADDRESS_NAME --global
  

  ADDRESS_NAME は、作成する予約済み IP アドレスの名前に置き換えます。

  作成した静的 IP アドレスを見つけるには、次のコマンドを実行します。

  gcloud compute addresses describe ADDRESS_NAME --global
  

  出力は次のようになります。

  address: 203.0.113.32
  ...
  

  Console

  予約済み IP アドレスを作成するには、次の手順を行います。

  1. Google Cloud コンソールで [外部 IP アドレス] ページに移動します。

     [外部 IP アドレス] に移動

  2. IP アドレスの名前を指定します（例: example-ip-address）。

  3. IPv4 アドレスまたは IPv6 アドレスのどちらにするかを指定します。

  4. [タイプ] には、[グローバル] オプションを選択します。

  5. [予約] をクリックします。IP アドレスが [外部アドレス] 列に表示されます。

  Config Connector

  注: この手順には Config Connector が必要です。Config Connector をクラスタにインストールするには、インストール手順を実施してください。

  apiVersion: compute.cnrm.cloud.google.com/v1beta1
  kind: ComputeAddress
  metadata:
    name: example-ip-address
  spec:
    location: global

  このマニフェストをデプロイするには、マニフェストを compute-address.yaml というファイル名でマシンにダウンロードしてから、次のコマンドを実行します。

  kubectl apply -f compute-address.yaml
  

Google マネージド証明書の設定

1. ManagedCertificate オブジェクトを作成します。このリソースは、SSL 証明書のドメインを指定します。ワイルドカード ドメインはサポートされません。

   次のマニフェストでは、ManagedCertificate オブジェクトを記述します。マニフェストを managed-cert.yaml として保存します。

   apiVersion: networking.gke.io/v1
   kind: ManagedCertificate
   metadata:
     name: FIRST_CERT_NAME
   spec:
     domains:
       - FIRST_DOMAIN
   ---
   apiVersion: networking.gke.io/v1
   kind: ManagedCertificate
   metadata:
     name: SECOND_CERT_NAME
   spec:
     domains:
       - SECOND_DOMAIN
   

   次のように置き換えます。

   • FIRST_CERT_NAME: 1 つ目の ManagedCertificate オブジェクトの名前。
   • FIRST_DOMAIN: 所有する 1 つ目のドメイン。
   • SECOND_CERT_NAME: 2 番目の ManagedCertificate オブジェクトの名前。
   • SECOND_DOMAIN: 所有する 2 番目のドメイン

   ManagedCertificate オブジェクトの名前は、実際に作成する証明書の名前とは異なります。Ingress で使用する ManagedCertificate オブジェクトの名前を確認しておいてください。

2. マニフェストをクラスタに適用します。

   kubectl apply -f managed-cert.yaml
   

3. 手順に沿って、Deployment と Service を作成し、アプリケーションをインターネットに公開します。

4. この ManagedCertificate オブジェクトを Active にするには、次の例のように、networking.gke.io/managed-certificates アノテーションを使用して Ingress に関連付けます。Ingress に接続するために、ManagedCertificate が Active である必要はありません。

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: my-gmc-ingress
      annotations:
        networking.gke.io/managed-certificates: "FIRST_CERT_NAME,SECOND_CERT_NAME"
    spec:
      rules:
      - host: FIRST_DOMAIN
        http:
          paths:
          - pathType: ImplementationSpecific
            backend:
              service:
                name: my-mc-service
                port:
                  number: 60001
      - host: SECOND_DOMAIN
        http:
          paths:
          - pathType: ImplementationSpecific
            backend:
              service:
                name: my-mc-service
                port:
                  number: 60002
    ```
   
   Replace <code><var>FIRST_DOMAIN</var></code> and
   <code><var>SECOND_DOMAIN</var></code> with your domain names.
   
   This manifest describes an Ingress that lists pre-shared certificate
   resources in an annotation.
   
   Note: It might take several hours for Google Cloud to provision the load
   balancer and the managed certificates, and for the load balancer to begin
   using the new certificates. For more information, see
   [Deploy a Google-managed certificate with load balancer authorization](/certificate-manager/docs/deploy-google-managed-lb-auth#wait_until_the_certificate_has_been_activated).
   

5. Google マネージド証明書のプロビジョニングが完了するまで待ちます。この処理には 60 分ほどかかる場合があります。次のコマンドを使用して、証明書のステータスを確認できます。

   kubectl describe managedcertificate managed-cert
   

   出力は次のようになります。

   Name:         managed-cert
   Namespace:    default
   Labels:       <none>
   Annotations:  <none>
   API Version:  networking.gke.io/v1
   Kind:         ManagedCertificate
   (...)
   Spec:
    Domains:
      FQDN_1
      FQDN_2
   Status:
    CertificateStatus: Active
   (...)
   

   Status.CertificateStatus フィールドの値は、証明書のプロビジョニング状態を示します。Status.CertificateStatus が Active でない場合、証明書はまだプロビジョニングされていません。

6. https:// 接尾辞を使用してドメインにアクセスし、SSL が機能していることを確認します。ブラウザ上に接続が安全であることが示され、証明書の詳細を確認できます。

セルフ マネージド証明書から Google マネージド証明書への移行

セルフ マネージド SSL 証明書から Google マネージド SSL 証明書に Ingress を移行する場合、Google マネージド SSL 証明書が有効になるまではセルフ マネージド SSL 証明書を削除しないでください。Google マネージド SSL 証明書は正常にプロビジョニングされると自動的に有効になります。Google マネージド SSL 証明書が有効になったら、セルフ マネージド SSL 証明書を削除できます。

以下の手順でセルフ マネージド SSL 証明書から Google マネージド SSL 証明書に移行します。

1. 前のセクションの説明に従って、新しい Google マネージド証明書を Ingress に追加します。

2. Google マネージド証明書リソースのステータスが Active になるまで待ちます。次のコマンドを使用して、証明書のステータスを確認します。

   kubectl describe managedcertificate managed-cert
   

3. ステータスが Active になったら、Ingress を更新してセルフマネージド証明書への参照を削除します。

Google マネージド証明書の削除

クラスタから Google マネージド証明書を削除するには、ManagedCertificate オブジェクトを削除するとともに、そのリソースを参照する Ingress アノテーションも削除する必要があります。

1. ManagedCertificate オブジェクトを削除します。

   kubectl delete -f managed-cert.yaml
   

   出力は次のようになります。

   managedcertificate.networking.gke.io "managed-cert" deleted
   

2. Ingress からアノテーションを削除します。

   kubectl annotate ingress managed-cert-ingress networking.gke.io/managed-certificates-
   

   コマンドの最後にマイナス記号（-）が付いていることに注意してください。

3. ロードバランサ用に予約した静的 IP アドレスを解放します。

   Google Cloud CLI、 Google Cloud コンソール、または Config Connector を使用して、予約済み IP アドレスを解放できます。

   gcloud

   次のコマンドを使用して、予約済みの IP アドレスを解放します。

   gcloud compute addresses delete ADDRESS_NAME --global
   

   ADDRESS_NAME は、IP アドレスの名前に置き換えます。

   Console

   予約済みの IP アドレスを解放するには、次の手順を行います。

   1. Google Cloud コンソールで [外部 IP アドレス] ページに移動します。

      [外部 IP アドレス] に移動

   2. 解放する IP アドレスの横にあるチェックボックスをオンにします。

   3. [IP アドレスを解放] をクリックします。

   Config Connector

   注: この手順には Config Connector が必要です。Config Connector をクラスタにインストールするには、インストール手順を実施してください。

   apiVersion: compute.cnrm.cloud.google.com/v1beta1
   kind: ComputeAddress
   metadata:
     name: example-ip-address
   spec:
     location: global

   このマニフェストをデプロイするには、マニフェストを compute-address.yaml というファイル名でマシンにダウンロードしてから、次のコマンドを実行します。

   kubectl delete -f compute-address.yaml
   

証明書と鍵を作成する

事前共有証明書または Kubernetes Secret を使用するには、まず 1 つ以上の証明書と対応する秘密鍵が必要です。各証明書には、所有しているドメイン名と同じ共通名（CN）を設定する必要があります。共通名として適切な値が設定された 2 つの証明書ファイルがすでに存在する場合は、次のセクションまでスキップできます。

1. 1 番目の鍵を作成します。

   openssl genrsa -out test-ingress-1.key 2048
   

2. 1 番目の証明書署名リクエストを作成します。

   openssl req -new -key test-ingress-1.key -out test-ingress-1.csr \
       -subj "/CN=FIRST_DOMAIN"
   

   FIRST_DOMAIN は、所有しているドメイン名（example.com など）に置き換えます。

3. 1 番目の証明書を作成します。

   openssl x509 -req -days 365 -in test-ingress-1.csr -signkey test-ingress-1.key \
       -out test-ingress-1.crt
   

4. 2 番目の鍵を作成します。

   openssl genrsa -out test-ingress-2.key 2048
   

5. 2 番目の証明書署名リクエストを作成します。

   openssl req -new -key test-ingress-2.key -out test-ingress-2.csr \
       -subj "/CN=SECOND_DOMAIN"
   

   SECOND_DOMAIN は、所有している別のドメイン名（examplepetstore.com など）に置き換えます。

6. 2 番目の証明書を作成します。

   openssl x509 -req -days 365 -in test-ingress-2.csr -signkey test-ingress-2.key \
       -out test-ingress-2.crt
   

証明書と鍵の詳細については、SSL 証明書の概要をご覧ください。

これで、2 つの証明書ファイルと 2 つの鍵ファイルの作成が終了しました。

残りのタスクでは、次のプレースホルダを使用して、ドメイン、証明書、鍵を参照します。

• FIRST_CERT_FILE: 最初の証明書ファイルのパス。
• FIRST_KEY_FILE: 最初の証明書に対応する鍵ファイルのパス。
• FIRST_DOMAIN: 所有しているドメイン名。
• FIRST_SECRET_NAME: 最初の証明書と鍵が含まれている Secret の名前。
• SECOND_CERT_FILE: 2 番目の証明書ファイルのパス。
• SECOND_KEY_FILE: 2 番目の証明書に対応する鍵ファイルのパス。
• SECOND_DOMAIN: 所有している 2 番目のドメイン名。
• SECOND_SECRET_NAME: 2 番目の証明書と鍵が含まれている Secret の名前。

注: FIRST、SECOND という単語は順序を示すものではありません。2 つのドメイン、2 つの証明書ファイル、対応する鍵ファイルを追跡しやすくするためのものです。

事前共有証明書を使用する

Google Cloud プロジェクトにアップロードするセルフマネージド SSL 証明書を使用できます。これらは事前共有証明書と呼ばれます。Ingress に 1 つ以上の事前共有証明書を指定できます。

複数の事前共有証明書を使用する手順は次のとおりです。

1. 証明書と鍵のペアごとに、 Google Cloudに公開されている SSL 証明書リソースを作成します。

    gcloud compute ssl-certificates create FIRST_CERT_NAME \
        --certificate=FIRST_CERT_FILE \
        --private-key=FIRST_KEY_FILE
    ```
   
   ```sh
    gcloud compute ssl-certificates create SECOND_CERT_NAME \
        --certificate=SECOND_CERT_FILE \
        --private-key=SECOND_KEY_FILE
    ```
   
   Replace the following:
   

   • FIRST_CERT_NAME、SECOND_CERT_NAME: 1 番目と 2 番目の証明書の名前。
   • FIRST_CERT_FILE、SECOND_CERT_FILE: 1 つ目と 2 つ目の証明書ファイル。
   • FIRST_KEY_FILE、SECOND_KEY_FILE: 1 つ目と 2 つ目の鍵ファイル。

2. Ingress マニフェストに ingress.gcp.kubernetes.io/pre-shared-cert アノテーションを追加します。アノテーションの値は、証明書名のカンマ区切りリストです。また、spec.rules セクションに host フィールドを含めて、サービスのドメインを指定します。

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: my-psc-ingress
      annotations:
        ingress.gcp.kubernetes.io/pre-shared-cert: "FIRST_CERT_NAME,SECOND_CERT_NAME"
    spec:
      rules:
      - host: FIRST_DOMAIN
        http:
          paths:
          - pathType: ImplementationSpecific
            backend:
              service:
                name: my-mc-service
                port:
                  number: 60001
      - host: SECOND_DOMAIN
        http:
          paths:
          - pathType: ImplementationSpecific
            backend:
              service:
                name: my-mc-service
                port:
                  number: 60002
    ```
   
   Replace <code><var>FIRST_DOMAIN</var></code> and
   <code><var>SECOND_DOMAIN</var></code> with your domain names.
   
   This manifest describes an Ingress that lists pre-shared certificate
   resources in an annotation.
   

Kubernetes Secret を使用する

自分で作成した証明書と鍵を HTTP(S) ロードバランサに提供するには、1 つ以上の Kubernetes Secret オブジェクトを作成します。各 Secret には証明書と鍵が格納されます。Secret を Ingress マニフェストの tls フィールドに追加します。ロードバランサは、TLS handshake のドメイン名に基づいて、Server Name Indication（SNI）を使用してクライアントに提示する証明書を決定します。

複数の証明書を使用する手順は次のとおりです。

1. 証明書と鍵のペアごとに Secret を作成します。

    kubectl create secret tls FIRST_SECRET_NAME \
        --cert=FIRST_CERT_FILE \
        --key=FIRST_KEY_FILE
    ```
   
   ```sh
    kubectl create secret tls SECOND_SECRET_NAME \
        --cert=SECOND_CERT_FILE \
        --key=SECOND_KEY_FILE
    ```
   

2. Ingress マニフェストの spec.tls セクションで、作成した Secret を一覧表示します。また、spec.rules セクションに host フィールドを含めて、サービスのドメインを指定します。

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: my-mc-ingress
   spec:
     tls:
     - secretName: FIRST_SECRET_NAME
     - secretName: SECOND_SECRET_NAME
     rules:
     - host: FIRST_DOMAIN
       http:
         paths:
         - pathType: ImplementationSpecific
           backend:
             service:
               name: my-mc-service
               port:
                 number: 60001
     - host: SECOND_DOMAIN
       http:
         paths:
         - pathType: ImplementationSpecific
           backend:
             service:
               name: my-mc-service
               port:
                 number: 60002
   

   FIRST_DOMAIN と SECOND_DOMAIN は、example.com や examplepetstore.com などの所有しているドメイン名に置き換えてください。

Secret の変更内容は一定期間ごとに反映されるので、Secret 内のデータを変更した場合、それらの変更がロードバランサに適用されるまでに最大で 10 分かかります。

GKE クラスタの HTTPS で暗号化された Ingress を保護するには、Ingress の保護の例をご覧ください。

HTTP の無効化

クライアントとロードバランサ間のすべてのトラフィックに HTTPS を使用する場合は、Ingress マニフェストに kubernetes.io/ingress.allow-http アノテーションを追加します。アノテーションの値を "false" に設定します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress-2
  annotations:
    kubernetes.io/ingress.allow-http: "false"
spec:
  tls:
  - secretName: SECRET_NAME
  ...

このマニフェストには、作成した Secret の名前である SECRET_NAME が含まれています。

注: アノテーション networking.gke.io/managed-certificates を使用している場合、アノテーション kubernetes.io/ingress.allow-http: false は使用できません。外部アプリケーション ロードバランサのプログラムが完全に作成された後で初めて、Ingress を更新してアノテーション kubernetes.io/ingress.allow-http: false を追加できます。

注意: マルチクラスタ Ingress では HTTP を無効にできません。

クライアントとロードバランサ間の HTTP/2

クライアントは HTTP/2 を使用してロードバランサにリクエストを送信できます。構成は不要です。

ロードバランサとアプリケーション間のトラフィックを保護して最適化する

ロードバランサとアプリケーション Pod 間の通信に使用されるプロトコルを構成して、エンドツーエンドのセキュリティを確保したり、内部トラフィックのパフォーマンスを最適化したりできます。ロードバランサは、バックエンド接続にデフォルトで暗号化されていない HTTP/1.1 を使用しますが、アプリケーションの特定の要件を満たすために HTTPS または HTTP/2 を有効にできます。

ロードバランサとアプリケーション間の HTTPS

GKE Pod で実行しているアプリケーションが HTTPS リクエストを受信できる場合は、ロードバランサがリクエストをアプリケーションに転送するときに HTTPS を使用するようにロードバランサを構成できます。詳しくは、ロードバランサとアプリケーション間の HTTPS（TLS）をご覧ください。

ロードバランサとアプリケーションの間で使用されるプロトコルを構成するには、cloud.google.com/app-protocols アノテーションを Service マニフェストで使用します。 コンテナ ネイティブのロード バランシングを使用しない場合、このサービス マニフェストに type: NodePort を含める必要があります。コンテナ ネイティブのロード バランシングを使用する場合は、type: ClusterIP を使用します。

次の Service マニフェストでは、2 つのポートを指定しています。そのアノテーションによると、HTTP(S) ロードバランサが Service のポート 80 をターゲットにしているとき、HTTP を使用する必要があります。また、ロードバランサが Service のポート 443 をターゲットにしているとき、HTTPS を使用する必要があります。

Service マニフェストでは、ポートのアノテーションに name 値を含める必要があります。Service ポートを編集するには、targetPort 値ではなく、割り当てられた name を参照します。

注意: 潜在的なダウンタイムを制限するには、この機能を有効にするときに Service のポート名を編集しないでください。Service のポートに名前がない場合は、cloud.google.com/app-protocols: '{"": "HTTPS"}' と同様に、空のポート名をアノテーションのキーとして使用します。初期設定後にポート名またはアノテーションを編集すると、アプリケーションのダウンタイムが発生する可能性があります。

apiVersion: v1
kind: Service
metadata:
  name: my-service-3
  annotations:
    cloud.google.com/app-protocols: '{"my-https-port":"HTTPS","my-http-port":"HTTP"}'
spec:
  type: NodePort
  selector:
    app: metrics
    department: sales
  ports:
  - name: my-https-port
    port: 443
    targetPort: 8443
  - name: my-http-port
    port: 80
    targetPort: 50001

ロードバランサとアプリケーション間で HTTP/2 を使用する

GKE Pod で実行しているアプリケーションが HTTP/2 リクエストを受信できる場合は、ロードバランサがリクエストをアプリケーションに転送するときに HTTP/2 を使用するようにロードバランサを構成できます。

HTTP/2 を有効にするには、Kubernetes Service マニフェストで cloud.google.com/app-protocols アノテーションを使用する必要があります。このアノテーションは、ロードバランサがアプリケーションとの通信に使用するプロトコルを指定します。ロードバランサが正しい HTTP/2 リクエストをバックエンドに送信できるようにするには、バックエンドを SSL で構成する必要があります。

HTTP/2 用に構成された Service マニフェストの例を次に示します。

apiVersion: v1
kind: Service
metadata:
  name: my-http2-service
  annotations:
    cloud.google.com/app-protocols: '{"my-port":"HTTP2"}'
spec:
  type: NodePort
  selector:
    app: my-app
  ports:
  - name: my-port
    protocol: TCP
    port: 443
    targetPort: 8443

次の点にご注意ください。

• cloud.google.com/app-protocols アノテーションは '{"my-port":"HTTP2"}' に設定されています。これにより、ロードバランサは my-port という名前のポートに送信されるトラフィックに HTTP/2 を使用します。
• ポートは 443 に設定され、targetPort 8443 の Pod にトラフィックを転送します。