【TECH BLOG】Kubernetes External SecretsからExternal Secrets Operatorに移行した話〜他ツールとの比較・移行戦略・工夫したポイント〜

はじめに

こんにちは、SRE部プラットフォーム基盤SRE部ブロックの織田です。普段は主にZOZOTOWNのリプレイスやインフラを改善、運用しています。

本記事では、Secret管理コンポーネントであるKubernetes External Secrets（以降、KESと表記）の非推奨を受けて、どのような対応を実施したのか紹介します。

なぜSecret管理コンポーネントを利用するのか？

Secret管理コンポーネントとは、KubernetesのSecretを管理する機能を持つソフトウェアのことです。

Kubernetesを運用する上でSecret管理コンポーネントを利用しない場合は、Secret manifestをKubernetesにapplyしSecretを作成することになるかと思います。KubernetesのSecretは、データをbase64エンコードしているだけなので、誰でもbase64デコードができ、データを確認できます。そのため、Secret manifestのような基本的に秘匿情報を含むファイルは、GitHubのようなバージョン管理システムにコミットするべきではありません。

コミットを避ける方法の1つとして、Secret管理コンポーネントの利用が挙げられます。そうすることでAWS Secrets ManagerやAzure Key VaultのようなSecret Management System（以降、SMSと表記）に登録された秘匿情報をKubernetesが取得し、Secretに注入できます。その結果、Secret manifestをバージョン管理システムにコミットせず、安全にデータを扱うことが可能です。

弊チームではこれまでSecret管理コンポーネントとしてKESを使用していました。

Kubernetes External Secrets（KES）について

KESとは？

KubernetesのSecretリソースを管理するオペレーターです。弊チームでは外部のSMSからデータを取得し、取得したデータをKubernetesのSecretへ注入するために利用しています。

KESを使ったKubernetes構成

弊チームではどのような構成でKESを利用していたのか紹介します。下図がKESを採用していたおおよそのKubernetesの構成図です。

KESがExternalSecretの内容をもとにAWS Secrets Managerに登録されているデータを取得し、Secretを作成します。 Application（Deployment,Cronjob,etc.）は、ExternalSecretが作成したSecretを参照したり、volumeとしてマウントします。

このようにSMSから取得したデータをKubernetesで利用することによってSecret manifestをコミットせずに済むため、よりセキュアに扱うことが可能です。

KESの非推奨について

2021/11/03にKESは非推奨化が発表され、現在はアーカイブされています。

KESが非推奨になった背景としては、アクティブなメンテナが存在していなかったため、プロジェクト内の問題を引き起こしている技術的負債が解消されず、メンテナンスされていないことだとKES is deprecated, migrate to ESO!で言及されています。

発表の内容を見るとOSSをメンテナンスすることはモチベーションの維持や管理の面においてとてもハードだと感じるとともに、今まで利用させていただき感謝しかありません。

ただ弊チームのKubernetes Clusterでは、全SecretをKESで生成しているため、なにかしらの対応をとる必要がありました。

移行先の選定

ここからは移行先コンポーネントの選定について具体的に説明します。

優先事項の決定

まずは移行先を決めるにあたって、比較する項目を決め以下の4つを優先事項としました。

Kubernetes manifestやkustomizeの構成に変更が少ないこと
Secret更新時の運用に変更が少ないこと
移行コストが少ないこと
KESで利用している機能、または同等の機能が使えること
ある程度アクティブに活動があるOSSであること

現状、KESに不満はないため、kustomize構成やSecret運用に大きな変更を加えず、移行コストを抑えたいと考えました。

KESで利用している機能は、Secretの更新タイミングをコントロールできるもの（自動更新のOFF）です。自動更新をONにしているとSMSを更新後、Secretも自動更新されてしまうため、リリースタイミングをコントロールしたいと考え、自動更新をOFFにしています。Secretを更新してもPodを再起動しなければ更新後の値を読み取りませんが、タイミング悪くPodが再起動されてしまった場合意図せず読み込んでしまうため、このような対応をしています。

移行先の検討、比較

次に移行先の検討です。アクティブに開発されていそうな以下3つのコンポーネントを検討し、比較しました。

External Secrets Operator（以降、ESOと表記）は、KESを開発していたオーガナイゼーション（External Secrets）が開発しています。JavaScriptで書かれていたKESをGoでリファクタリングしたコンポーネントです。ExternlSecretのapiVersionは変更になっていますが、ExternalSecretがSecretを作成するということは変わっていないため、Kubernetes manifestの変更は少なく済みそうです。KESの非推奨issueでもESOへの移行を勧められているのとKESからESOへの移行ツール（以降、移行ツールと表記）が用意されています。そのため、移行コストについても少なく済みそうだと考えました。

Secets Store CSI Driverは（以降、CSI Driverと表記）、Kubernetes SIGsが開発しています。名前の通り、Container Storage Interface（CSI）を利用し、シークレットやキー、証明書をPodにVolumeとしてマウントします。また、マウントしたものをSecretに同期したり、複数のSecretオブジェクトを1つのVolumeとしてマウントするなど様々な機能があります。Podにシークレットやキー、証明書をVolumeとしてマウントした上でSecretに同期する必要があることを考えると、少なくともKubernetes manifestへのインパクトは大きそうです。

Sealed Secretsは、Bitnamiが開発していて、"全Kubernetes configをGitで管理できるようにする" ことを目的に作成されました。SecretをSealed Secretsに暗号化させ、Kubernetes manifestを生成します。Kubernetesで動作するコントローラのみが復号化でき、原作者でさえもSealedSecretからオリジナルのSecretを取得できません。そのため、Public repositoryにコミットしても安全に保管できると言われています。1

この段階で移行先がほぼ決まっている感じはありますが、候補とした3つを比較しました。

続きはこちら