【ITニュース解説】That Time I Found a Service Account Token in my Log Files

ある日、Go言語で書かれたアプリケーションのログファイルの中に、KubernetesのServiceAccountトークンという非常に重要な情報が記録されているのが発見された。これは、本番環境のシステムセキュリティにおいて重大なリスクとなる可能性を秘めている。なぜなら、このトークンはシステムが自身を証明し、他のサービスと連携するために使用される「鍵」のようなものだからだ。

発見されたトークンはJWT（JSON Web Token）という形式で、WebアプリケーションやAPIなどで広く利用される、署名付きのコンパクトな情報だ。JWTは通常、ヘッダー、ペイロード、署名の三つの部分から構成される。ヘッダーはトークンの署名に使われたアルゴリズムを示し、ペイロードには「クレーム」と呼ばれる、トークンが誰に関するもので、何ができるかといった情報が格納される。そして署名は、トークンが改ざんされていないことを保証する。ペイロードに含まれるクレームの中でも特に重要なのが「audience（オーディエンス）」で、これはトークンがどのシステムやサービスによって受け入れられるべきかを示す。例えば、トークンに特定のURLがaudienceとして記載されていれば、そのURLを持つサービスだけがトークンを有効とみなし、他のサービスは拒否すべきである。このaudienceのチェックがなければ、トークンは意図しない場所で悪用される危険性があるのだ。

今回のケースで発見されたServiceAccountトークンを詳しく調べると、有効期限が1年間と非常に長く、かつ特定のaudienceが指定されていなかった。これは、もしトークンが悪意のある第三者の手に渡ってしまえば、長期間にわたって広範囲のシステムへの不正アクセスに使われる可能性があったことを意味する。

Kubernetesは、コンテナ化されたアプリケーションを大規模に動かすためのプラットフォームである。Kubernetes上で動作するアプリケーションの最小単位はPodと呼ばれるが、PodがKubernetes APIサーバーや他の外部システムと安全に通信するためには、自身が正当な存在であることを示す「ID」が必要だ。このIDがServiceAccountであり、各PodにはServiceAccountが割り当てられる。ServiceAccountトークンは、このServiceAccountの身分証明書として機能し、Pod内にファイルとしてマウントされる。このトークンもまたJWT形式で、PodがKubernetes APIサーバーに対して認証を行う際に使われる。

しかし、以前のKubernetesのバージョンでは、ServiceAccountトークンにはいくつかセキュリティ上の課題があった。一つは、その有効期限がデフォルトで非常に長く設定されており、一度発行されると長期間にわたって有効だったことだ。もう一つは、特定のaudienceがデフォルトで設定されていないことが多く、そのため多くのシステムがそのトークンを受け入れてしまう可能性があった。さらに、使われていないにもかかわらず、ほとんど全てのPodに自動的にマウントされてしまうという問題も存在した。これらの特性により、トークンが一度漏洩すると、その影響範囲は広範かつ長期間に及び、深刻なセキュリティインシデントを引き起こすリスクが高かったのである。

このような機密情報を安全に管理するシステムとして、HashiCorp Vaultがある。VaultはAPIキー、データベースの認証情報、証明書といった様々な秘密情報を厳重に保管し、必要なアプリケーションやユーザーに対してのみ、必要な権限で安全に提供する役割を担う。Vaultが認証を行う方法の一つにKubernetes認証とJWT認証がある。Kubernetes認証では、PodがServiceAccountトークンをVaultに提示し、VaultはKubernetes APIサーバーに問い合わせてそのトークンが有効かつ正当なものかを確認する。一方、JWT認証では、Vault自身がトークンの署名やクレーム、有効期限などを検証するため、Kubernetes APIへの直接的な問い合わせは不要となる。JWT認証はポータビリティが高く、VaultがKubernetesクラスターの外部で動作する場合などにも有効な方法だ。

旧来のServiceAccountトークンの持つ問題点を解決するために導入されたのが「プロジェクテッドトークン」である。プロジェクテッドトークンは、旧来のトークンとは異なり、その場で必要に応じて生成され、有効期限が非常に短い（例えば10分程度）という特徴を持つ。また、audienceを明示的に指定できるため、「このトークンはVaultだけが使うものだ」といった具体的な利用目的を限定できる。さらに、プロジェクテッドトークンは、全てのPodに自動的にマウントされるのではなく、Podの定義で明示的に指定した場合のみマウントされる。これにより、トークンが仮に漏洩したとしても、その悪用される期間や利用可能な範囲が大幅に制限され、セキュリティリスクを大幅に低減できるのだ。例えば、Podの定義にserviceAccountTokenの指定を追加し、expirationSecondsで有効期限を短く設定し、audienceで利用するサービスを明記する。

プロジェクテッドトークンは、VaultのJWT認証メソッドと非常に相性が良い。Vaultはプロジェクテッドトークンに設定された短い有効期限や、厳密なaudience指定を検証することで、より確実で安全な認証を実現できる。これにより、最小限の依存関係で強力なクレーム検証を行うことが可能となり、システム全体のセキュリティレベルを大きく向上させる。

今回のニュース記事で取り上げられたように、ログにServiceAccountトークンが出力されることは、どのようなトークンであっても避けるべき深刻なセキュリティ上の問題である。しかし、もし誤ってログに漏洩してしまったのがプロジェクテッドトークンであった場合、その有効期限は短く、利用可能な範囲も限定されているため、旧来の長期間有効で広範囲に適用可能なトークンに比べて、壊滅的な被害につながる可能性は大幅に低くなる。古いタイプのServiceAccountトークンを使い続けているシステムは、いつ予期せぬセキュリティインシデントに遭遇してもおかしくない状態だと言える。現代のクラウドネイティブ環境におけるセキュリティ基準を満たすためには、プロジェクテッドトークンへの移行は不可欠であり、これによって多くの潜在的なセキュリティリスクを未然に防ぎ、より堅牢なシステム運用を実現できるだろう。