Kubernetes は、新しい本番環境のIDメカニズムとして Pod Certificates と Cluster Trust Bundles を導入しました。この機能は現在一般提供されており、TLS および mTLS 用の X.509 証明書の発行をコア Kubernetes に直接統合します。これは、以前の主要なメカニズムであるサービスアカウント JWT を大きく超える進歩です。JWT は使いやすさと幅広い互換性を提供しますが、重要な弱点があります。それは、それらがベアラートークンであるため、侵害された場合に不正アクセスを受けやすいことです。一方、Pod Certificates は、主に X.509 証明書である非対称暗号化に基づいたプルーフ・オブ・ポセッション認証情報（proof-of-possession credentials）を活用します。これにより、認証情報自体を共有するだけでなく、所有権の証明を要求することでセキュリティが強化されます。目標は、Kubernetes ワークロードから X.509 証明書を使用することを JWT と同じくらい簡単にする一方で、高いセキュリティ基準を維持することです。Pod Certificates は柔軟性を考慮して設計されており、プラグ可能なインターフェイスを通じて単一のクラスター内でさまざまな種類の証明書を許可します。これは、サービスアカウント JWT の単一の標準化された形式とは対照的です。将来の Kubernetes バージョンでは、サービス DNS 名および SPIFFE クライアント証明書の組み込み証明書プロバイダーが提供される予定です。アーキテクチャには、証明書を要求するアプリケーション、リクエストを発行しトラストバンドルを管理する Kubelet、およびこれらのリクエストを満たしトラストバンドルを発行する署名コントローラーが含まれます。発行プロセスは時系列で行われ、Pod のスケジューリングから始まり、アプリケーションがキーと証明書にアクセスすることで完了します。自動ローテーションが組み込まれており、アプリケーションはこれらの更新を処理する必要があります。セキュリティチェックは kube-apiserver に統合されており、分離を強制し、侵害されたノードが不当なアクセスを得るのを防ぎます。これらの機能を試すには、ユーザーは Tinycert のようなサードパーティの署名者をインストールする必要があります。Tinycert は、サンプル署名者と、アプリケーションが SPIFFE 証明書をロードするのに役立つライブラリを提供します。