K8sのシークレット管理を劇的に変える！Kloakでワークロードと機密情報を安全に分離しよう

K8s環境におけるシークレット管理に悩んでいませんか？「Kloak」は、Kubernetesのワークロードから機密情報を直接触れさせないようにする、新しいアプローチのシークレットマネージャーです。機密情報をコンテナの環境変数やマウントファイルから分離することで、万が一の漏洩リスクを最小限に抑えます。セキュリティ強化を目指すエンジニアはぜひチェックしてみてください。

どうも、Kloakを開発しているspinning-factoryチームです。KloakはKubernetesコントローラーとして動作します。ワークロード内のシークレットを「kloaked secrets」と呼ばれる無害なプレースホルダーに置き換え、アプリが許可されたホストにリクエストを送る直前のタイミングで、eBPFを使って本物のシークレットを差し戻すという仕組みです。現時点では、OpenSSL 3.0～3.5（静的・動的リンク）やgo-tls（Go 1.25、1.26）を使うアプリで動作します。TLSライブラリ（GnuTLSやBoringSSLなど）のサポート拡大や、他のGoバージョンへの対応もロードマップに入っています。KloakはAGPLのオープンソースなので、コントリビューション大歓迎！HNの皆さんのフィードバックや質問にも喜んで答えるので、ぜひコメントください。

へぇ、Kloakってデンマーク語で「下水道」って意味なんだね。

コントローラーを分割したほうがいいよ。コントロールプレーンとデータプレーンの両方で動いちゃってるからね。でもアイデアは良いと思う。頑張って。

これかなりすごいね。AI制御のワークフローがこういうアウトオブバンドな解決策を喉から手が出るほど求めている今の時期に、まさにぴったりだよ。一点気になるのは、クラウド環境でのサポート状況だね。AKSやEKSとかでも問題なく動くの？

これ最高にかっこいいプロジェクトだね。これがどんな脅威モデルに対抗するものなのか、もう少し詳しく教えてくれる？あと、置き換え処理はHTTPの特定のフィールドだけに行われるのか、それともリクエスト内のマッチする文字列すべてに行われるのかも気になる。非標準的な認証方法をサポートするなら後者のほうがいいかもしれないけど、シークレット用のプレースホルダーがシークレット以外の目的で使われていて、誤って置換されてしまうようなエッジケースもありそうだし。

アプリ側でシークレットを使ってペイロードに署名するモデルもあるよ。AWSは全APIでこれを大々的に使ってるね。

これを実現する方法として、APIプロキシやゲートウェイを使うやり方を聞いたことがあるよ。シークレットをVaultに保存しておいて、プロキシ経由でアプリが通常通りリクエストを送る。シークレットを使わずにリクエストを送っても、プロキシがそれをインターセプトして認証情報を透過的に追加してくれるっていう仕組み。これならAPIレート制限の管理や、API特有の脅威検知なんかも一元管理できるから便利だよね。クラウドプロバイダーのサービス以外でこれをやる方法はよく知らないけど。アーキテクチャの観点で見ると、データ処理に関しては環境全体が同じ信頼レベルにある（つまり内部は無防備）けど、システム外とのやり取りはすべて、シークレット管理を含めたすべてを制御するゲートウェイプロキシを通す、という考え方だね。