【ITニュース解説】Taming the Hydra: Why Your Kubernetes Secrets Management is Broken (And How CyberArk Conjur Fixes It)

現代のITシステム開発では、アプリケーションを小さく分割して独立させるマイクロサービスという考え方が広がり、それらをコンテナという技術でパッケージ化し、Kubernetes（クバネティス）と呼ばれるシステムで自動的に管理するクラウドネイティブな環境が主流になっている。開発者はインフラの設定もコードとして管理（Infrastructure as Code）し、効率的かつ柔軟な開発を進めている。しかし、これらの先進的な環境を構築する中で、多くのエンジニアが頭を悩ませる共通の課題がある。それが「シークレット（機密情報）」の管理だ。

シークレットとは、データベースのパスワード、APIキー、認証情報など、外部サービスや他のシステムと連携するために必要な非常に重要な情報のことを指す。これらの情報が漏洩すると、システム全体のセキュリティが脅かされる可能性があるため、厳重に管理する必要がある。

現在の多くのKubernetes環境では、シークレットの管理に根本的な問題が潜んでいる。Kubernetesには「Secret」という機能があり、これを使って機密情報を保存する仕組みが提供されている。しかし、この機能で作成されたシークレットは、Kubernetesクラスターの情報を保存する分散型データベースであるetcd（エトセディー）に、Base64という形式でエンコードされた状態で保存される。Base64エンコードはデータを別の形式に変換するだけで、暗号化とは異なり、誰でも簡単に元の情報に戻せてしまう。これは、パスワードを紙に書いて、それを単に違う字体で書き直したようなもので、ほとんど意味をなさない。クラスターのAPIにアクセスできる人であれば、誰でもこのシークレットを簡単に取得できてしまうのだ。たとえetcdに保存される際に暗号化が施されていても、アプリケーションが実際にシークレットを使う段階では、依然として平文（暗号化されていない状態）で提供されてしまう。

このような状況は、いくつかの深刻な問題を引き起こす。まず、GitOps（ギットオプス）という、Gitリポジトリをシステムの唯一の真実の情報源とする運用モデルを採用している場合、開発者はシークレットを直接Gitに保存することを避けるために、SOPSやSealed Secretsといったツールを使ってシークレットを暗号化してGitリポジトリに入れることがある。しかし、これでは今度はその「暗号化するための鍵」をどのように管理するかという新たな問題が発生し、根本的な解決にはならない。次に、データベースのパスワードのように一度設定したらあまり変更しない「静的なシークレット」は、一度漏洩するとそれが永遠の脅威になりかねない。また、etcdに保存されたシークレットは、クラスターにアクセスできるすべてのユーザーやシステムに対して公開されてしまうため、どのシークレットに誰がアクセスできるかという細かいアクセス制御ができない。さらに、誰がいつ、どのシークレットにアクセスしたのかという履歴（監査ログ）を正確に追跡することが難しく、セキュリティコンプライアンス（法令順守）の要件を満たすことも困難となる。

このような課題に対し、CyberArk Conjur（サイバーアーク・コンジャー）は全く新しいアプローチを提案している。Conjurは「どこにシークレットを保存するか」ではなく、「必要なアプリケーションに、必要な時に、必要なシークレットだけを安全に提供する方法」に焦点を当てる。Conjurは、Kubernetesクラスターの外に設置される、一元化されたシークレット管理サーバーであり、強力なポリシーに基づいてシークレットへのアクセスを制御する「セキュアな金庫」のような存在だ。

Conjurの哲学は三つの柱に基づいている。一つ目は「アイデンティティベースのアクセス」だ。アプリケーションがシークレットを得るためには、単にパスワードを持っているからではなく、「そのアプリケーションが何者であるか」を明確に証明する必要がある。二つ目は「動的なシークレット」だ。永続的に変わらない鍵を提供するのではなく、短期間だけ有効で、自動的に失効する一時的な鍵をアプリケーションに提供する。これにより、万が一シークレットが漏洩しても、その有効期間が非常に短いため、被害を最小限に抑えられる。三つ目は「ポリシー・アズ・コード」だ。セキュリティポリシーやアクセスルールを、人間が読みやすく、バージョン管理が可能なYAMLファイルとして定義する。これにより、セキュリティ設定もアプリケーションコードと同様に管理し、レビューや自動化が可能になる。

Conjurがどのようにシークレットをアプリケーションに提供するのか、具体的な流れを見てみよう。まず、Kubernetes上でアプリケーションを動かすための最小単位であるPod（ポッド）が起動する。このPodの中には、Conjurの軽量な補助プログラム（サイドカーインジェクターと呼ばれる）が自動的に注入されて一緒に起動する。このサイドカーインジェクターは、シークレットを取得するための特別なパスワードを持たない。その代わり、KubernetesがPodに割り当てる「サービスアカウントトークン」という、Pod自身の固有の識別情報（アイデンティティ）を持っている。

サイドカーインジェクターはこのサービスアカウントトークンをConjurサーバーに提示し、自身のアイデンティティを証明しようとする。Conjurサーバーは、このトークンが本物であることを確認するため、KubernetesクラスターのAPIサーバー自体に問い合わせを行う。「このPodは本当にこの名前空間とサービスアカウントに属しているのか？」と検証するのだ。Podのアイデンティティが検証された後、Conjurは事前にポリシー・アズ・コードとして定義されたルールを確認する。「このPod（特定の名前空間とサービスアカウントを持つ）は、この特定のシークレットを読み取る権限があるか？」というチェックを行う。このチェックがパスすれば、Conjurは要求されたシークレットをPodに直接提供する。この時、シークレットはPod内のコンテナのメモリやファイルシステムに注入され、決してetcdには書き込まれない。

この一連のプロセスにより、アプリケーションは、自分自身のKubernetes上のアイデンティティを使って安全に認証を行い、必要なシークレットを直接Conjurから取得できるようになる。これにより、シークレットを安全に取得するための別のシークレット（いわゆる「ニワトリと卵」の問題）を管理する必要がなくなる。

このConjurのアプローチは、DevOps（開発と運用の連携）とセキュリティの両方にとって大きな変革をもたらす。DevOpsエンジニアにとっては、GitOpsの真の実現が可能となる。シークレットそのものではなく、シークレットへのアクセスを制御するポリシーだけをGitでバージョン管理できるため、機密情報がリポジトリに存在しない安心感がある。また、動的なシークレットの導入により、データベースのパスワードなどが数分ごとに自動的に更新されるため、手動でのシークレット更新作業から解放される。開発者は、実際のシークレットの値を知ることなく、自身のアプリケーションに必要なシークレットをポリシーファイルを通じて定義できるため、セルフサービスで開発を進められるようになる。

セキュリティエンジニアにとっては、ConjurはSOC2コンプライアンス（情報セキュリティに関する国際的な監査基準）対応に大きく貢献する。誰が、どのシークレットに、いつアクセスしたかという詳細で改ざん不可能な監査ログを自動的に生成するため、監査人にとって非常に価値のある情報となる。また、ノードが侵害されても、Conjurが提供するシークレットは寿命が短く、直接etcdに保存されていないため、情報漏洩時の影響範囲を大幅に削減できる。ポリシーによって、ステージング環境のPodが誤って本番環境のシークレットにアクセスしてしまうような事態も確実に防ぐことができる。これは、必要な最小限の権限のみを与える「最小権限の原則」を徹底することに繋がる。

Conjurは他のシークレット管理ソリューションとも異なる。SOPSやSealed Secretsは、Gitリポジトリにシークレットを隠すためのツールであるのに対し、ConjurはそもそもシークレットをGitに入れる必要がないシステムである。External Secret Operators（ESO）のようなツールは、外部のシークレット管理サービスからシークレットを取得してKubernetesのSecretとしてetcdに保存するため、etcdに平文が保存されるという根本的な問題は解決しない。Conjurは、このetcdへの保存を完全に回避する安全な配信メカニズムを持つ。また、AWS Secrets Managerのようなクラウドプロバイダが提供するネイティブなシークレットマネージャーとも競合するのではなく、Conjurはこれらをバックエンドとして利用できる。Conjurは、複数のクラウド環境やオンプレミス環境にまたがる、一貫したアイデンティティベースのアクセス層を提供する統合的なコントロールプレーンとして機能するのだ。

このように、CyberArk Conjurを導入することで、シークレット管理の課題に対する考え方を根本的に変え、より安全で、運用が容易で、自動化されたシークレット管理システムを構築できるようになる。シークレットを隠すことではなく、シークレットへのアクセスを厳密に管理することこそが、現代のセキュリティには不可欠である。