【Terraform】Google マネージド証明書の設定でのハマりどころを解決したい！

Google Cloud でロードバランサーを使って HTTPS 通信を行うには、SSL/TLS 証明書が必要です。
本記事では、Terraform を使って Google マネージド証明書を作成し、DNS 認証方式で認証を行う方法を解説します。また、HTTPS ロードバランサーに証明書を適用する際の注意点についても詳しく説明します。

Google マネージド証明書の作成

Google マネージド証明書は Terraform では「google_certificate_manager_certificate」リソースを用いて作成することができます。

注意事項として似たリソースとして「google_compute_managed_ssl_certificate」があります。
「google_compute_managed_ssl_certificate」のほうがより古い方式の証明書であり、コンソールの「Certificate Manager」画面で「従来の証明書」タブに表示される証明書と一致します。

「google_certificate_manager_certificate」のほうが DNS 認証が可能であったり柔軟性が高いため、新たに作成する場合はこちらを用いることが多くなるかと思います。

# Certificate - ワイルドカード証明書（DNS 認証）
resource "google_certificate_manager_certificate" "default" {
  name        = "cert-test"
  description = "Wildcard certificate"
  scope       = "DEFAULT"

  managed {
    domains = "*.myorg.example.com"
    dns_authorizations = [
      google_certificate_manager_dns_authorization.default.id
    ]
  }
}

DNS 認証 のリソース

DNS 認証を行うには「ドメイン名」に対する DNS 認証リソースを作成する必要があります。これは証明書を作成する画面で一緒に作成することができます。

例として、作成した DNS 認証のリソースです。
DNS レコードに登録するべき「DNS レコード名」、「DNS レコードタイプ」、「DNS レコードデータ」があることがわかります。

これは Terraform 上では以下のように作成可能なリソースです。
つまり証明書とは異なる別のリソースとして作成されます。

resource "google_certificate_manager_dns_authorization" "default" {
  name        = "dns-authz-test"
  description = "DNS Authorization"
  domain      = "example.com"
  type        = "PER_PROJECT_RECORD"
}

DNS 認証のリソース一覧を確認するには以下のコマンドを実行することで確認できます。

gcloud certificate-manager dns-authorizations list

DNS 認証リソースを作成すると、次のような値が発行されます。
この値を DNS レコードに CNAME で登録することで認証を行う事ができます。

また、DNS 認証リソースの注意点として、ドキュメントにもあるように「*.myorg.example.com などのワイルドカード証明書用の DNS 認証を作成する場合は、親ドメイン（myorg.example.com など）の DNS 認証を構成します。」とあるように、ワイルドカードの DNS 認証のリソースは親ドメインの値で DNS 認証を作成すれば事足ります。

例えば、「*.myorg.example.com」と「myorg.example.com」で2つの DNS 認証を作ると2つのリソースのレコードに登録するべき値は同じになります。つまり、親ドメインの DNS 認証リソースを1つ作れば十分ということになります。

https_proxy との接続

ロードバランサーに証明書を適用するとき、「google_compute_target_https_proxy」のリソースに対してアタッチを行います。

このリソースには証明書をアタッチする方法はいくつかあり、どんな証明書なのか、どんなロードバランサーに対してかによって指定の方法が異なることに注意が必要です。
以下は Terraform の例です。

# HTTPSプロキシ
resource "google_compute_target_https_proxy" "https" {

  name          = "proxy-test-https"
  url_map       = google_compute_url_map.https.id
  ssl_policy    = google_compute_ssl_policy.ssl_policy.id
  quic_override = "NONE"

  # Certificate Map を参照
  certificate_map = "//certificatemanager.googleapis.com/${google_certificate_manager_certificate_map.default.id}"
}

ssl_certificates

この属性は「google_compute_managed_ssl_certificate」リソースを受け取るように設計されています。今回証明書の作成に用いたリソースは「google_certificate_manager_certificate」であり、別物であることがわかります。
前述のように「google_compute_managed_ssl_certificate」は従来の証明書として扱われるもので、「ロードバランサ認証」のみをサポートするものです。したがって今回の証明書をこの「ssl_certificates」属性で指定するのは正しくありません。

certificate_manager_certificates

この属性は「google_certificate_manager_certificate」タイプの証明書のリソース id を直接指定する属性です。
この属性はロードバランサの方式が INTERNAL_MANAGED である場合に用いられる属性です。
EXTERNAL および EXTERNAL_MANAGED の場合は後述するcertificate_map 属性を用います。
なお ssl_certificates と certificate_manager_certificates 属性は排他です。どちらか一方しか使用できません。

certificate_map

EXTERNAL および EXTERNAL_MANAGED のロードバランサで「google_certificate_manager_certificate」タイプの証明書を用いる場合に指定する属性です。
「google_certificate_manager_certificate_map」リソースの id を指定します。

今回の例のコードは外部からのアクセスがある外部ロードバランサーを想定しているので、「certificate_map」を用いています。

まとめ

本記事では、Google Cloud で HTTPS 通信を実現するための Google マネージド証明書の作成と、DNS 認証方式を用いた認証、そしてロードバランサーへの適用方法について解説しました。

重要なポイント

1. 証明書リソースの選択

   • 新規作成では google_certificate_manager_certificate を使用
   • 従来の google_compute_managed_ssl_certificate は DNS 認証に非対応

2. DNS 認証の仕組み

   • ワイルドカード証明書（*.myorg.example.com）の場合、親ドメイン（myorg.example.com）の DNS 認証リソースを作成すれば十分
   • DNS 認証リソースは証明書とは別のリソースとして管理される
   • CNAME レコードを DNS に登録することで認証が完了

3. ロードバランサーへの証明書適用方法

   • 外部ロードバランサー（EXTERNAL/EXTERNAL_MANAGED）: certificate_map 属性を使用
   • 内部ロードバランサー（INTERNAL_MANAGED）: certificate_manager_certificates 属性を使用
   • 従来の証明書: ssl_certificates 属性を使用
   • これらの属性は排他的なので、証明書のタイプとロードバランサーの種類に応じて正しく選択する必要がある

これらの仕組みを理解することで、Terraform を使った証明書管理の自動化やトラブルシューティングがスムーズに行えるようになります。