1
1

More than 1 year has passed since last update.

external-secrets-operatorのwebhookに使う証明書をcert-managerで賄う時のポイント

Posted at

環境

external-secrets-operator v0.5.0 から v0.5.3 それ以降もかも


前置き

kubernetes-external-secretsが非推奨となって、external-secrets-operator(以下ESO)を使用し始めている人もそろそろ増えてきているのではないでしょうか
そんなESOですが、v0.5がリリースされてvalidationとconversionのwebhookが実装されました

webhookのサーバはESOで用意されたものを起動するのですが、k8sの決まり(だったような)でクライアントがwebhookサーバにアクセスするのにTLS接続が必須とのことです(ちょっとこのへんの知識は怪しい)
それに対応するため、ESOはこれに使う証明書を諸々勝手にやってくれるcertcontrollerというものも用意していてくれて、これも別で起動する流れになっています
よって、ESO v0.5を動作させるのに、本体、webhook、certcontrollerの3つが起動する流れとなっています

で、この辺のwebhookの仕組みというのはもちろんESO以外でもよく使われるもので、そのへんの証明書をどうにかするのにcert-managerというものがよく使われています

私が管理する環境も他で既に必要になっていてこのcert-managerがクラスタにありました
せっかくcert-managerがもうあるんだから証明書管理はそっちに寄せたい…ということで対応をしました
大体の対応方法の流れはESOのgithubのissueでも言及されているのですが

最後までハマって今のとこ前例の記事が見当たらなかった部分を書いておきます

証明書の期限に注意

cert-managerで証明書を作る場合、certificateリソースに設定がなければ90日後を期限にして生成され、その期限の2/3が経過すると更新されます

一方、ESOのwebhookは一定時間ごとにサーバ証明書をチェックしていて

このへんのfunctionやconstを追うと、証明書の期限チェックに現在時刻+90日の時刻を使用していることがわかります
なんで90日も足しているのかはわかりませんが、大きく余裕を持ったんでしょうか

で、既に述べたように、cert-managerはデフォルトで90日が期限の証明書を作るので、90日後で期限チェックすると、証明書は期限切れということになります

なので、そのあたり余裕を持って期限を設定した証明書をcert-managerに作ってもらう必要があります
具体的には、Certificateリソースの spec.durationspec.renewBefore を設定するのですが、詳細はドキュメントを見てください

愚痴

上で紹介したESOのコードの部分で CheckCerts がエラーを返す(つまり証明書のチェックに失敗する)と、直後にcontextをcancel()するだけで、結果何の手がかりも残さずにプロセスが終了します…
これがなんもわからなくてだいぶ苦労しました

なもんで、なぜかESOのwebhookコンテナが定期的に正常終了するんだよな…という場合はこのあたり(証明書周りのミス)を疑ってみてください

この辺りはログが出るように改善されていくとありがたいですね
issue上げてcontributeしていきたい気持ちもあるけど度胸がない

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1