マネージド TLS 証明書と HTTPS の使用

このページでは、Cloud Run for Anthos での HTTPS 接続をサポートする TLS 証明書を自動的に提供および更新するマネージド TLS 証明書機能を無効化し、再び有効化する方法について説明します。

HTTPS を使用するには

  • コンテナが $PORT でリッスンし続ける必要があります
  • TLS 証明書を提供する方法として、次のいずれかを選択する必要があります。

    • マネージド TLS 証明書を使用する。この場合、TLS 証明書が必要に応じて自動的に作成され、自動的に更新されます。この機能は、サポートされる Google Kubernetes Engine バージョンで利用可能です。このページではこの機能について説明します。
    • 独自の証明書を使用する。この場合、証明書の取得と更新をご自分で行う必要があります。制限事項で説明している特定の状況では、独自の証明書を使用する必要があります。
  • マネージド証明書を使用する場合、マネージド証明書機能を使用するためにカスタム ドメインのマッピングも必要になります。

HTTPS と HTTP の使用

マネージド証明書を使用する場合、デフォルトでは、マネージド証明書を使用するクラスタまたは Cloud Run for Anthos サービスが HTTP と HTTPS の両方のトラフィックに公開されます。HTTPS トラフィックだけに制限する必要がある場合は、HTTPS リダイレクトを有効化すると、すべてのトラフィックが HTTPS のみを使用するようになります。

トラブルシューティング

マネージド TLS 証明書の使用時に問題が発生した場合は、マネージド TLS のトラブルシューティングのページをご覧ください。

制限事項

マネージド TLS 証明書を使用する場合、次の点を考慮する必要があります。

  • Google Cloud 上の Cloud Run for Anthos 限定公開クラスタでは、マネージド TLS 証明書が無効になり、サポートされません。
  • マネージド証明書機能を使用するには、サービスを外部に公開する必要があります。クラスタ ローカルのサービスにしたり、Virtual Private Cloud で公開されるサービスにしたりすることはできません。
  • マネージド証明書機能は、Cloud Run for Anthos のクラスタ設定時に自動的にインストールされ、Istio でのみ動作します。Istio アドオンや他の Istio の構成では機能しません。Istio アドオンを使用する場合は、独自の TLS 証明書を使用する必要があります。
  • この機能は Let's Encrypt を使用しています。登録済みドメインごとの週あたりの TLS 証明書の初期割り当て上限は 50 です。Let's Encrypt のドキュメントの説明に沿って、割り当ての増加を依頼できます。
  • オンプレミスや AWS などの他のプラットフォームで Cloud Run for Anthos クラスタを実行する場合、この機能は無効になります。この機能を使用するには、クラスタが Let's Encrypt にアクセスできることと、Istio Ingress サービス(gke-systemistio-ingress サービス)が公共インターネットに公開されていることを確認する必要があります。
  • マネージド証明書を使用する場合、ドメインをマッピングするときに、マッピング先のサービスの URL と完全に一致するドメイン マッピング名を使用することはできません。たとえば、サービスの URL が test.default.example.com の場合、DomainMapping 名を test.default.example.com に設定することはできません。

始める前に

このページで説明する手順は次のとおりです。

サポートされているクラスタ バージョン

1.17.7-gke.15 以降のバージョンでは、Google Cloud 上の一般公開クラスタに対してデフォルトでマネージド証明書が有効になります

次のクラスタ バージョンでは、マネージド証明書機能がデフォルトで無効になっていますが、マネージド証明書を有効化して使用できます。

  • 1.16.0
  • 1.15.7-gke.23
  • 1.14.10-gke.17
  • 1.14.9-gke.23
  • 1.14.8-gke.33

現在のクラスタ バージョンを確認するには、次の手順を行います。

  1. Google Cloud コンソールで Google Kubernetes Engine ページに移動します。

    Google Kubernetes Engine に移動

  2. クラスタをクリックして詳細ページを開きます。

  3. [マスターのバージョン] の横にあるのが、クラスタ バージョンです。

クラスタ全体でマネージド TLS 証明書と HTTPS を無効にする

ConfigMap config-domainmapping を更新することで、クラスタに関するマネージド TLS を無効にします。

kubectl patch cm config-domainmapping -n knative-serving -p '{"data":{"autoTLS":"Disabled"}}'

特定のドメイン マッピングに対してマネージド TLS と HTTPS を無効にする

必要に応じて、特定のドメイン マッピングに対してマネージド TLS を無効にすることができます。

  1. アノテーション domains.cloudrun.com/disableAutoTLS: "true" を追加します。

    kubectl annotate domainmappings DOMAIN domains.cloudrun.com/disableAutoTLS=true
  2. HTTPS が機能しないことを確認します。

    curl https://DOMAIN

  3. サービスで HTTP が使用されていることを確認します。

    gcloud run domain-mappings describe --domain DOMAIN

    DOMAIN は、独自のドメイン名に置き換えます。(例: example.com

    上記のコマンドで返された url: フィールドを確認します(URL は https ではなく http である必要があります)。

マネージド TLS 証明書と HTTPS を再度有効にする

マネージド TLS を再度有効にするには:

  1. サービスのドメイン マッピングをまだ作成していない場合は、カスタム ドメインのマッピングのページの手順に沿って DNS レコードを更新します。

  2. ConfigMap config-domainmappingを更新して、マネージド TLS 証明書と HTTPS を有効にします。

    kubectl patch cm config-domainmapping -n knative-serving -p '{"data":{"autoTLS":"Enabled"}}'
  3. コマンドが正常に実行された後、数分待ってから、証明書機能が動作していることを次のように確認します。

    kubectl get kcert

    証明書の準備が整うと、次のようなメッセージが表示されます。

    NAME              READY   REASON
    example.com       True

    Kcert の準備が整うまで 20 秒から 2 分かかります。問題が発生した場合は、証明書機能のトラブルシューティングの手順をご覧ください。

成功を確認する

  1. 次のコマンドを実行して、DNS レコードが発行されていることを確認します。

    gcloud run domain-mappings describe --domain DOMAIN

    DOMAIN は、独自のドメイン名に置き換えます。(例: example.com

  2. 上記のコマンドで返された url: フィールドを確認します(URL は http ではなく https である必要があります)。

  3. 上記のコマンドで返された IP アドレス(resourceRecords:rrdata の下)を確認し、コマンド host DOMAIN を実行したときに表示される値と比較します。両方の値が一致している必要があります。

Cloud Run for Anthos で HTTPS リダイレクトを有効にする

マネージド TLS 証明書機能を使用する場合、下位互換性の理由から、クラスタはデフォルトで HTTP と HTTPS の両方のトラフィックに公開されます。すべてのトラフィックに HTTPS のみを使用させるには、次のコマンドを実行することで、既存のドメイン マッピングに対して HTTPS リダイレクトが有効になります。

kubectl annotate domainmappings DOMAIN domains.cloudrun.com/httpsRedirect=Enabled

ここで、DOMAIN はドメイン マッピングの名前です。