KeycloakからAWS SecretsManagerの認証情報を使ってDBに接続する
AWS RDSの接続情報をSecretsManagerで管理していて、定期的な認証情報のローテーションを行うというのは割とベタ？な構成かと思います。
そんな構成の中にKeycloakをECSに載せて動かしたい場合に、Keycloakは標準ではSecretsManagerから認証情報を取得することはできないので、
AWS Secrets Manager JDBC LibraryをKeycloakに組み込んでSecretsManagerから認証情報を取得できるようにしてみたいと思います。
- 1. Keycloakのコンテナを用意
- 2. AWS Secrets Manager JDBC Libraryと依存jarを用意
- 3. コンテナにjarを配置
- 4. コンテナ起動のためのパラメーター、環境変数の用意
- 5. デプロイしてコンテナを起動する
- まとめ
1. Keycloakのコンテナを用意
今回の方針としてはKeycloakの公式dockerイメージに手を加えてSecretsManagerへ対応をしたいので
とりあえず、公式イメージを指定したDockerfileを用意します。
FROM quay.io/keycloak/keycloak:21.1 # SecretsManagerに対応するために何かをする... ENTRYPOINT /opt/keycloak/bin/kc.sh start-dev
2. AWS Secrets Manager JDBC Libraryと依存jarを用意
AWS Secrets Manager JDBC Libraryと依存するライブラリのjarを用意します。
やり方はいろいろあると思いますが、私はMaven Reoisitoryから直接jarをダウンロードしました。
https://mvnrepository.com/mvnrepository.com
ダウンロードしたjarは以下です。
- aws-secretsmanager-jdbc-1.0.11.jar
- aws-secretsmanager-caching-java-1.0.2.jar
- aws-java-sdk-core-1.12.252.jar
- aws-java-sdk-secretsmanager-1.12.252.jar
- commons-logging-1.2.jar
- ion-java-1.0.2.jar
- jmespath-java-1.12.252.jar
- joda-time-2.8.1.jar
- org.jacoco.agent-0.8.8.jar
3. コンテナにjarを配置
公式ドキュメントに書いてありますが providersディレクトリにjarを入れて keycloakのbuildコマンドを実行すると
そのjarを読み込んでくれるようになるとのこと（超ざっくり解釈ですが...）
Keycloakはコンテナ起動時にbuildコマンドを実行してくれるようなので（もしかするとstart-devの時だけかもですが。。。）
COPYコマンドで2.で用意したjarをprovidersディレクトリに入れておきます。
FROM quay.io/keycloak/keycloak:21.1 # libs以下にjarを入れておく COPY ./libs/* /opt/keycloak/providers/. ENTRYPOINT /opt/keycloak/bin/kc.sh start-dev
4. コンテナ起動のためのパラメーター、環境変数の用意
事前準備は基本的には以上でOKなので、あとはSecretsManagerを参照、AWS Secrets Manager JDBC Library用のJDBCドライバを
使用するための設定をしていきます。
起動時パラメーターの追加
XA transactionはサポートしていないようなので、OFFにしておきます。
FROM quay.io/keycloak/keycloak:21.1 # libs以下にjarを入れておく COPY ./libs/* /opt/keycloak/providers/. # XA Transactionの使用をOFFにする ENTRYPOINT /opt/keycloak/bin/kc.sh start-dev --transaction-xa-enabled=false
providers以外のjarが入っているフォルダに格納しても読み込んでくれた気がします。。。
DB接続情報を環境変数に設定
起動時パラメーターでもよいですが、環境変数に以下を設定します。
| 変数名 | 値 | コメント |
|---|---|---|
| KC_DB | mysql | RDS for MySQLの場合。 未指定だとKC_DB_DRIVERのドライバを参照してくれません。。。 |
| KC_DB_DRIVER | com.amazonaws.secretsmanager.sql.AWSSecretsManagerMySQLDriver | |
| KC_DB_URL | jdbc-secretsmanager:mysql://${RDS_HOST}:3306 | |
| KC_DB_PASSWORD | SecretsManagerのSecretId | |
| KC_DB_USERNAME | SecretsManagerのSecretId |
5. デプロイしてコンテナを起動する
上記の設定を持ってしてコンテナを起動させればおそらくKeycloakがRDSを参照し、
RDSの接続情報としてSecretsManagerの値を使用してくれます。
また、SecretsManagerでローテーションが発生しても追従してくれます。
まとめ
私の場合はKeycloakをまじめに運用という訳ではなく、開発用に用意したかったのでおそらく、
運用を考えると微妙な箇所があるはずですが、providersディレクトリにjarを配置して読み込ませるという流れと、
各パラメーターの設定は変わらないのかなと思います。
Keycloakってパラメーターがふんだんにあってドキュメントもそれなりに充実はしているんですが、 今回みたいな個々のケースでどう設定すべきなのか調べるとあまり出てこないんですよね。
DatabaseSetupでjava.lang.IllegalArgumentException: Unable to load dataset ...と言われる
Spring + DBUnit な構成でユニットテストを実行すると
java.lang.IllegalArgumentException: Unable to load dataset .... とエラーが表示されました。
原因はわかりませんが、タイポもなく、ファイルが存在するのにエラーが起きることはあるようで、
👇の方はファイルを置きなおすことで改善したようです。
wrongwrong163377.hatenablog.com
ここからが本題ですが、私の場合は
手元の開発環境で実行すると成功するが AWS CodeBuild上では上記が再現して失敗するという状態でした。
CodeBuild上では gradle buildを実行し jarを作成するということをしていたのですが、
buildの中で実行されるtestで上記が再現していました。
もちろん必要なファイルやはすべてそろっており構成上は問題ないはずでした。
また、特定のフォルダというより特定のフォルダ以下のファイルがすべて読めないようでした。
つまり、少しでもフォルダの階層をずらすと読めるようになるという。。。
原因の特定はできませんでしたが、フォルダ構成を整理してファイルの場所を変えてあげることで問題なく動作するようになりました。
とりあえず今回は動くようになりましたが、この先テスト用のファイルを追加していった際に再現しない保証はないのでちょっと怖いですねw
手元の環境で再現せずCodeBuild上では再現するということで環境の問題だとは思いますが、 なんなんでしょうか。。。
というか、CodeBuildのdockerイメージ使って試してみればいいのか。
まぁ次動かなくなったら試してみようw
SubversionでNo such revision言われた
コード管理はもっぱらGitですが、ドキュメント（MarkdownとかではなくExcelやWordのようなバイナリ系）類は、Subversionで管理することが多いです。
これについての是非は様々あると思いますw
所謂、Web系ではなくエンタープライズなところだとSubversion使ってるところも多いのではないでしょうか。
それにそういうところだとそれなりに古くから同じSubversionのオンプレのサーバーを使っていたり。。。
うちの会社でも古めなサーバーが動いているのですが、それが原因なのか何なのかチェックアウトをしようとすると「No such revision」といわれるようになりました。
それも、なぜか内のプロジェクトで使っているリポジトリだけという。。。
とりあえず、以下のコマンドを実施すると途中でエラーとなりました。。
svnadmin verify {リポジトリのディレクトリ}
なんとか復旧できないものかとググると同様な症状として以下の記事が引っ掛かりました。
対処としては上記の記事とほぼ同じ形で、リポジトリをコピーしてdb/revs、db/revpropsの最新のリビジョンを削除し
currentを最新の一つ前のリビジョンに書き換えます。
私の場合はなぜかcurrentの中身が空になっていました。。。
当然最新のリビジョンの内容は失われるので復旧した後再度そのリビジョンの内容をコミットする必要があります。
以下のコマンドでリポジトリの復旧を試みます。
svnadmin recover {リポジトリのディレクトリ}
これでエラーとなる場合は、もう駄目なんでしょうかw
私の場合は問題なく復旧できたので以下のコマンドで再度リポジトリの検証を行います。
svnadmin verify {リポジトリのディレクトリ}
問題ないことを確認して復旧完了です。
原因は不明ですが、私の場合は最新のリビジョンのデータを書き込む際に何かしらの問題があったようです。
また再発するかもしれませんが、復旧したのでとりあえずOKです。
別のサーバーに近々移行しようかな
Google Cloud認定のアレが届いた
今年の３月ごろに「 Google Cloud Certified Professional Data Engineer」というのを受験して無事合格したのですが、 その合格通知と一緒に連絡されるノベルティがようやく届きました。
概ね一か月ぐらいかかったようですね。
ノートPCに張り付けたりするステッカー(３枚)、スマホ用グリップ、マグカップの３種類です。
ステッカーはなぜか折り目がついてました。。。
(写真でもわかるかと思いますけど)
実際に張り付けたときに大丈夫なんでしょうかね？
スマホ用のグリップは以下のサイトで紹介しているようなものと同様です。
マグカップは蓋つきで多分２重構造になってるやつです。
底面がコルクっぽい感じになっていたり隙間が多いので使っていくと汚れがたまったりしないか心配ですね。
マグカップはそこそこサイズ感があるので普通に飲み物入れると結構入る気がします。
正直まだ、どれも使っていませんｗ
記念のノベルティなので使う必要はないんですが、使わないともったいないですよね。。。
ステッカーは何かに貼っておこう
