Terraformを使うということは、インフラをコード管理するということなので、SSL証明書も有効期限が来る前に更新する必要があるということを理解しているはずです。
ですが、理解していないソフトウェアチームがTerraformのコードのあるリポジトリやインフラの管理・運用権限を持っており、開発スケジュールを優先してSSL証明書の更新タイミングを決めない、開発の遅れによって更新タイミングもずるずる後ろにずらされる、ということがあります(信じらせないですが)。
「証明書を更新しなければサービスが止まる！」「コードレビューで承認されていないのだから、更新してはならない！」という衝突を避けるため、SSL証明書の変更を無視するよう、Terraformを書きましょう。
data resourceにlifecycleは使えない
証明書ファイルを登録する形でTerraformのコードを書くこともできますが、証明書ファイルをリポジトリに登録しない形で書きたいこともあるでしょう。
別途登録した証明書をdata resourceで参照する形にすることで、Terraformで使えるようにできます。
であれば、「data resourceでSSL証明書を参照しているのだから、これにlifecycle ignoreを設定すれば」と思うのですが、data resourceにlifecycleは設定できません。もうひと捻りしてみましょう。
Cloud Load Balancingでの設定
証明書を使うところで変更を無視する設定を入れると、うまくいきます。
locals {
certificate = "example-202204"
}
data "google_compute_ssl_certificate" "example_certificate" {
name = local.certificate
}
# snip
resource "google_compute_target_https_proxy" "example_1_proxy" {
name = "example-1-proxy"
url_map = google_compute_url_map.example_1_urlmap.id
ssl_certificates = [ data.google_compute_ssl_certificate.example_certificate.id ]
ssl_policy = google_compute_ssl_policy.example_ssl_policy.id
lifecycle {
ignore_changes = [
ssl_certificates
]
}
}ロードバランサー(example_1_proxy)に設定されているssl_certificatesの変更は無視(ignore)する、と読めます。実際にgcloudコマンドで証明書を変更してからterraform planしてみましたが、変更は検出されませんでした。
注意！data sourceの証明書は消せない
data sourceで参照しているリソースが存在しているかどうかをチェックしているようで、「証明書を更新したのだから…」と古い証明書を消してしまうと、terraform planすらできなくなってしまいます。
これは、順序の問題です。data sourceを変更した後であれば、問題なく古い証明書を削除できます。
ロードバランサーに紐付けてある証明書が更新できれば、有効期限を気にする必要はなくなります。
ですので、data sourceで参照している証明書を変更してプルリクをだしておきましょう。マージされるまで時間がかかっても大丈夫です。
data sourceの変更がとりこまれてから、古い証明書を削除します。
形だけのIaCが招く問題
なんでこんな問題が生じるのかと呆れますが、理解していない人が権限を持っていると、起こり得るのではないでしょうか？世間で騒いでいる以上に、IT業界の人材不足は深刻です。
SSL証明書の自動更新の仕組みはいくつかあるのですが、ドメイン認証の証明書のみ対応など、制限があります。近いうちに解消されるといいのですが…。
コメント