Certificate Managerを使ってみる

2023/09/22に公開されました。
2023/09/22に更新されました。

Certificate Managerを使ってみる


author: kuribo-

はじめに

アプリチームのkuribo-です。

今回はCertificate Managerを検証してみました。

Google管理の証明書

今まではGoogle管理の証明書というとCompute Engine証明書(Googleのドキュメント内でも表記揺れがあるっぽいので正しいかはわからない)が使われてきました。
この証明書は弱点としてLBが作成された後、かつAレコードが正しく引けないと証明書がアクティベートされないという問題点がありました。
何が問題かというと、リソースが作成されているのに証明書がアクティベートされるまで短くても30分程度待たなければいけないため
単純に移行などをすると長時間のダウンタイムが発生してしまうということです。
(1つのLBに対して複数の証明書を有効化できるので、それでダウンタイムなく切り替えはできるはずですが…)

ですが、Certificate Managerを使うことで事前に証明書のアクティベートを行うことができるようになりました。
これにより作成したばかりのLBにCertificate Managerで作成した証明書をアタッチするだけですぐに使えるようになります。
また、ワイルドカード証明書にも対応しているのもとても魅力的です。

Certificate Managerとは

Google管理の証明書を管理するためのサービスです。
今までの証明書はLBに対して作成などしますが、Certificate Managerを使う場合は証明書のみを作成が可能です。
事前に作成しておいた証明書をLB作成時にアタッチするようなイメージになります。

ここでCertificate Managerの仕様をざっくり記載します。
https://cloud.google.com/certificate-manager/docs/overview?hl=ja

  • LBで使えるTLS証明書の管理ができる
    • 対象のLBは以下の3つ
      • グローバル外部アプリケーションロードバランサ(ターゲットHTTPSプロキシ)
      • 従来のアプリケーションロードバランサ(ターゲットHTTPSプロキシ)
      • 外部プロキシネットワークロードバランサ(ターゲットSSLプロキシ)
    • 対象の証明書は以下の2つ
      • Googleマネージド証明書
      • セルフマネージド証明書
  • LB毎にデプロイできる証明書数が100万件
  • 認証方式が2つ
    • ロードバランサ認証
      • 従来の証明書と同じ。全て通信できる状態になってからアクティベートできる。
    • DNS認証
      • 全てのリソースがなく通信できない状態でもアクティベートできる。アクティベート後にLBにアタッチすることでダウンタイムゼロになる。
      • 検証サブドメインのCNAMEレコードをDNS構成に追加する必要がある。
        • CNAMEレコードはターゲットドメインのDNS承認の作成時にCertificate Managerから返される。
  • ワイルドカードドメインが使える
    • ただしDNS認証の場合のみ

以下のようなメリデメが存在しますが、基本メリットしかないです。

  • メリット
    • 事前にアクティベートした状態でLBにアタッチできるためダウンタイムゼロになる。
    • 以前はLBに対して証明書のアタッチは15件までという制限があったが、Certificate Managerの場合は100万件になる。
  • デメリット
    • DNS認証に使うCNAMEを登録する必要がある。
    • 画面からCertificate Managerの設定はできない。
      • Cloud SDKを使うか、Terraformを使う必要がある。(基本的にTerraformで管理しているのでそこまで影響はない)

Certificate Managerの仕組みについては以下のURL参照。(実際に試してみたをみる前に見ておくとわかりやすい)
https://cloud.google.com/certificate-manager/docs/how-it-works?hl=ja

実際に試してみた

Certificate ManagerのDNS認証を作成する

gcloud certificate-manager dns-authorizations create ccm-test-domain --domain="ccm-test.example.com" --project hogehoge

ここでCNAMEが返ってくるのでDNSに登録します。
(ドメイン部分は各自読み替えてください)
ワイルドカード証明書にする場合はここのdomain部分をワイルドカードにしてください。

DNS認証を参照するGoogleマネージド証明書を作成する

gcloud certificate-manager certificates create cert-ccm --domains=ccm-test.example.com dns-authorizations=ccm-test-domain --project hogehoge

先ほど作成したDNS認証に対して証明書を作成。

mapおよびmap-entriesの作成

# cert-mapの作成
gcloud certificate-manager maps create cert-map --project hogehoge

# cert-map-entriesの作成
gcloud certificate-manager maps entries create cert-map-entry-1 \
    --map="cert-map"
    --certificates="cert-ccm"
    --hostname="ccm-test.example.com"
    --project hogehoge

マップを作成してマップエントリーを紐づける。 マップエントリーはGoogleマネージド証明書と紐づく。

LBにマッピング(target-proxyおよびforwarding-ruleの作成)

# target-proxyの作成
gcloud compute target-https-proxies create lb-ccm-test-https-target-proxy --url-map=kuribo-ccm-test-lb --certificate-map="cert-map" --project hogehoge

# forwarding-ruleの作成
gcloud compute forwarding-rules create lb-ccm-test-https-forwarding-rule \
    --load-balancing-scheme=EXTERNAL \
    --network-tier=PREMIUM \
    --global \
    --target-https-proxy=lb-ccm-test-https-target-proxy \
    --ports=443 \
    --project hogehoge

Certmapに関わる部分はここだけなので、LBの残り部分は手動で作成して問題ありません。

Aレコードの登録

作成したLBのIPアドレスを使ってAレコードを登録します。

動作確認

これで作成した証明書が使えることが確認できます。
以下のURLにアクセスすることになります。(取得していないドメインなのでアクセスできませんが)
https://ccm-test.example.com/

つまづきポイント

  • 検証していて気づいたのが、CNAMEが各プロジェクト毎に発行される(プロジェクトを跨げない)ため、各プロジェクト毎にワイルドカード証明書を作成することになる。
    • dev,stg,prdなど環境を分けている場合、1つのワイルドカード証明書で全ての環境を賄うことはできない。
      • なので、ドメインの設計をする時はきちんとサブドメインで環境を分けるように設計する必要がある。
        • 例:fuga-app.dev.example.com(*.dev.example.comのワイルドカード証明書はdevプロジェクトに存在する)

まとめ

今までの証明書はお手軽でしたが、ダウンタイムがどうしても発生してしまうという制約がありました。(工夫すればなんとかなるが…大変。)
Certificate Managerを使うことでそこまで気にせずにダウンタイムなく切り替えができるようになりました。
また、1つのLBに複数のドメインの証明書をアタッチしている場合、15個が限界という制約がありましたがそれらも気にしなくてよくなります。(100万件までアタッチできる)
大量のバックエンドバケットを1つのLBで制御するような作りにしていた場合にとても使いやすくなりました。
ワイルドカード証明書が使えるようになったことで大量の証明書管理が不要になります。(Terraformで大量に作っていたものが消せます。嬉しい!)

おわりに

今回は検証だったためまだTerraformは試していないですが、概ね手動で作成して流れがわかったので次はTerraformで作成してみます。(記事にはしない可能性が高いですが…)
不便だったところが改善されるのはとても良いですね。
今後ももっと便利になっていくと良いです。


GI Cloud は事業の拡大に向けて一緒に夢を追う仲間を募集しています

当社は「クラウドで日本のIT業界を変革し、世の中をもっとハッピーに」をミッションに掲げ、Google Cloudに特化した技術者集団として、お客様にコンサルティングからシステム開発、運用・保守まで一気通貫でサービスを提供しています。

まだ小規模な事業体ですが、スタートアップならではの活気と成長性に加えて、大手総合商社である伊藤忠グループの一員としてやりがいのある案件にもどんどんチャレンジできる環境が整っています。成長意欲の高い仲間と共にスキルを磨きながら、クラウドの力で世の中をもっとハッピーにしたい。そんな我々の想いに共感できる方のエントリーをお待ちしています。

採用ページ

※本記事は、ジーアイクラウド株式会社の見解を述べたものであり、必要な調査・検討は行っているものの必ずしもその正確性や真実性を保証するものではありません。

※リンクを利用する際には、必ず出典がGIC dryaki-blogであることを明記してください。
リンクの利用によりトラブルが発生した場合、リンクを設置した方ご自身の責任で対応してください。
ジーアイクラウド株式会社はユーザーによるリンクの利用につき、如何なる責任を負うものではありません。