10.3. Zero Trust Workload Identity Manager のリリースノート
Zero Trust Workload Identity Manager は、Secure Production Identity Framework for Everyone (SPIFFE) と SPIFFE Runtime Environment (SPIRE) を活用して、分散システム向けの包括的な Identity Management ソリューションを提供するものです。
以下のリリースノートは、Zero Trust Workload Identity Manager の開発履歴を記録したものです。
10.3.1. ゼロトラスト Workload Identity マネージャー 1.0.0(一般提供開始) リンクのコピーリンクがクリップボードにコピーされました!
発行日:2025 年 12 月 17 日
今回のリリースでは、企業における準備態勢、セキュリティー、および運用上の柔軟性を高めるための機能が導入されます。これには、クラスター間アイデンティティーのための SPIRE フェデレーション、本番環境における永続化のための PostgreSQL サポート、そしてより厳格な制約と API 検証によるセキュリティー強化が含まれます。
Zero Trust Workload Identity Manager では、次のアドバイザリーが利用可能です。
Zero Trust Workload Identity Manager は、以下のコンポーネントとバージョンをサポートしています。
| コンポーネント | バージョン |
|---|---|
| SPIRE Server | 1.13.3 |
| SPIRE Agent | 1.13.3 |
| SPIRE Controller Manager | 0.6.3 |
| SPIRE OIDC ディスカバリープロバイダー | 1.13.3 |
| SPIFFE CSI ドライバー | 0.2.8 |
10.3.1.1. 新機能および機能拡張 リンクのコピーリンクがクリップボードにコピーされました!
- SPIRE フェデレーションのサポート
Operator は SPIRE フェデレーションをサポートするようになり、異なる信頼ドメインにまたがるワークロードが安全に通信および認証を行えるようになりました。
主な機能:
-
https_spiffe(TLS) またはhttps_web(Web PKI) プロファイルを使用したバンドルエンドポイントの設定。 - ACME プロトコル (例: Let’s Encrypt) による証明書の自動管理。
- フェデレーションエンドポイント向けの OpenShift Container Platform ルートの自動作成。
- 複数のフェデレーション信頼ドメインとの関係を設定できる機能。
-
お客様による対応が必要です:
-
SpireServerカスタムリソース (CR) 内のフェデレーション設定を確認してください。 - フェデレーションされた信頼ドメインへの適切な DNS 解決とネットワーク接続を確保してください。
-
- PostgreSQL データベースのサポート
SPIRE Server は、外部データベースバックエンドとして PostgreSQL をサポートするようになり、エンタープライズグレードのデータ永続性と高可用性を必要とする本番環境へのデプロイメントに対応できるようになりました。
-
サポートされているタイプ:
sqlite3(デフォルト)、postgres、mysql。 お客様による対応が必要です:
- 本番環境においては、SQLite から PostgreSQL への移行を検討することを推奨します。
- データベースの TLS 証明書および認証情報用の Kubernetes Secrets の作成と設定が必要です。
-
サポートされているタイプ:
- 設定可能なエージェントソケットパスと Container Storage Interface (CSI) プラグイン名
SPIRE エージェントのソケットパスと SPIFFE CSI ドライバープラグイン名が設定可能になり、特定のディレクトリー要件を持つ環境や、複数の SPIFFE デプロイメントとの共存環境において、運用上の柔軟性が向上しました。
主な設定ポイント:
-
SpireAgent.spec.socketPath -
SpiffeCSIDriver.spec.agentSocketPath -
SpiffeCSIDriver.spec.pluginName
-
お客様による対応が必要です:
-
SpireAgentCR のsocketPathとSpiffeCSIDriverCR のagentSocketPathの一貫性を確保してください。
-
- ワークロードアテスター検証 API
ワークロード認証のための kubelet アテステーション書検証を設定するための新しい API が導入され、セキュリティーが強化され、さまざまな OpenShift 設定がサポートされるようになりました。
検証の種類:
-
auto(デフォルト): 検証には OpenShift のデフォルト (/etc/kubernetes/kubelet-ca.crt) が使用されます。 -
hostCert: カスタム CA 証明書パスを使用します。 -
skip:TLS 検証をスキップします (本番環境での使用は推奨されません)。
-
- 設定可能な認証局および JSON Web トークンキータイプ
管理者は、SPIRE サーバーの認証局 (CA) および JSON Web トークン (JWT) の署名に使用される暗号鍵の種類を設定できるようになり、組織のセキュリティーポリシーへの準拠を確保できます。
-
サポートされているキータイプ:
rsa-2048(デフォルト)、rsa-4096、ec-p256、ec-p384。 お客様による対応が必要です:
- 組織のセキュリティーポリシーを確認し、必要な鍵の種類を決定する。
-
サポートされているキータイプ:
- カスタムネームスペースのデプロイメント
- Operator および関連するすべてのオペランドは、カスタム名前空間内に展開できるようになり、特定の名前空間ガバナンス要件を持つ組織に柔軟性を提供します。
- プロキシー対応 Operator とオペランド
- Operator およびすべての管理対象オペランドはプロキシー対応となり、設定時にクラスター全体のプロキシー設定を自動的に継承するようになりました。
- 強化された Security Context Constraints
- SPIRE エージェントと SPIFFE CSI ドライバーは、root ユーザーの実行を防止する Security Context Constraints (SCC) を有効にして実行されるようになりましたが、必要なホストレベルの操作のために特権コンテナーモードは引き続き有効になっています。
-
Operator およびすべてのオペランドコンテナーは、
ReadOnlyRootFilesystemがtrueに設定されている状態で設定されています。
- API 検証機能の強化
包括的な共通表現言語 (CEL) 検証がすべてのカスタムリソース定義 (CRD) に統合され、アクセス制御時の設定エラーを防止します。
主な検証事項:
-
すべての OperatorCRD はシングルトンとして強制されます (
clusterという名前である必要があります)。 -
不変フィールド:
trustDomain、clusterName、bundleConfigMap、federation、bundleEndpointprofile、およびすべての永続化設定 (size、accessMode、storageClass) を含むフィールドは、初期作成後には不変になります。
-
すべての OperatorCRD はシングルトンとして強制されます (
お客様による対応が必要です:
- 既存の CR 設定を見直し、新しい検証ルールに準拠していることを確認してください。
- 共通設定の統合
-
標準設定オプション (
ラベル、リソース、アフィニティー、toleration、ノードセレクター) は、共通のCommonConfig構造を介して、すべてのオペランド CR で標準化されるようになりました。
-
標準設定オプション (
- オペランドのログレベルとログフォーマットの設定
今回のリリースでは、プラットフォーム全体のオブザーバビリティーとデバッグ性を向上させるための柔軟なログ記録制御機能が導入されました。
-
SPIRE コンポーネント: ユーザーは、CR 仕様内で
SpireServer、SpireAgent、およびSpireOIDCDiscoveryProviderのログレベル(デバッグ、情報、警告、エラー) とログフォーマット(テキスト、JSON) を個別に設定できるようになりました。デフォルトでは、logLevelは info、logFormatは text に設定されています。 -
Operator: オペレーターのログの詳細度は、klog の
textloggerを使用してOPERATOR_LOG_LEVEL環境変数を介して設定できるようになりました。
-
SPIRE コンポーネント: ユーザーは、CR 仕様内で
- 作成専用モード向けにリファクタリング
-
CREATE_ONLY_MODE環境変数を設定することで、ユーザーはオペレーターによる更新の調整を防止できます。これにより、干渉を受けることなく手動でリソースを変更することが可能になります。このモードが無効になっている場合、Operator は状態の強制を再開し、手動で行われた変更をすべて上書きします。
10.3.1.2. ステータスとオブザーバビリティーの改善 リンクのコピーリンクがクリップボードにコピーされました!
- 強化されたステータスレポート
- メイン CR は、すべてのオペランド CR からステータス情報を集約するようになりました。
- 新しいステータス条件には、アップグレード可能 (安全なアップグレードパスを示す) と進行中 (デプロイメントの進捗状況を詳細に示す) が含まれます。
- Operator メトリクス
- Operator のメトリクスは、適切な RBAC 設定によって保護されつつ、公開されるようになりました。
- OpenShift のモニタリングスタックとの統合がサポートされています。
10.3.1.3. 修正された問題 リンクのコピーリンクがクリップボードにコピーされました!
- SPIRE エージェント向け拡張 Security Context Constraints
今回のアップデート以前は、SPIRE エージェントおよび SPIFFE CSI ドライバーのコンテナーが root ユーザーとして実行されていたため、セキュリティー上の潜在的な問題が生じていました。今回のリリースでは、これらのコンポーネントが root 権限で実行されないように、Security Context Constraints (SCC) が設定されました。必要な機能を実現するには依然として特権コンテナーモードが必要ですが、この変更によりエンドユーザーにとっての潜在的なセキュリティーリスクが軽減されます。
(SPIRE-60)
- SpireServer のアップデートは、オペレーターの再起動なしで反映されるようになりました。
今回のアップデート以前は、オペレーターがオペランド CR 仕様を更新した後、リコンシリエーションをトリガーすることができませんでした。その結果、SpireServer CR リソースに対するユーザーによる更新が StatefulSet に反映されず、リコンシリエーションが失敗して変更が無視され、リソース割り当ての不整合が発生しました。今回のリリースでは、CR 更新後にリコンシリエーションをトリガーする際の、マネージャーとリコンサイラーのキャッシュ間の競合状態が修正されました。その結果、SpireServer CR に対する day2 パッチ操作は確実にリコンシリエーションをトリガーし、オペレーターによる手動再起動なしに更新された値が StatefulSet に適用されるようになります。
(SPIRE-68)
- OpenID Connect 検出プロバイダーの不要なセキュリティーコンテキスト制約を削除しました。
このアップデート以前は、システムは OpenID Connect (OIDC) ディスカバリープロバイダーに対して不要なカスタムセキュリティーコンテキスト制約 (SCC) を作成しており、デプロイメント必要ではなかったにもかかわらず、セキュリティー上の負荷と設定の複雑さを増大させていました。今回のリリースでは、カスタム SCC 作成ロジックが削除されたため、追加のセキュリティー制約なしに OIDC 検出プロバイダーが正常に動作する設定になりました。
- SPIRE コントローラーマネージャーの ConfigMap リコンシリエーションに関する問題を修正しました。
今回のアップデート以前は、Spire コントローラーマネージャーの ConfigMap リコンシリエーションは、以前の実装における未処理のエッジケースが原因で失敗していました。その結果、ユーザーは設定の不整合を経験することになった。今回のリリースで、Spire コントローラーマネージャーの ConfigMap におけるリコンシリエーションの問題が解決されました。その結果、エンドユーザーは Spire コントローラーマネージャーの設定をシームレスに行えるようになりました。
- OIDC ディスカバリープロバイダーが設定変更時に自動的に再起動するようになりました
今回のアップデート以前は、SPIRE OIDC ディスカバリープロバイダーが
configmap の変更後に自動的に再起動せず、認証エラーが継続的に発生していました。今回のリリースでは、CR へのアップデートによって Pod が自動的に再起動されるようになり、configmap の変更が即座に適用されるため、エンドユーザーはシームレスな操作感を享受できます。
- DaemonSet、Deployment、および StatefulSet のアップデートロールバックを修正しました。
今回のアップデート以前は、アップデートロジックの見落としにより、
daemonset、デプロイメント、およびstatefulset が、すべての有効なシナリオにおいて適切に元の形式に戻されていませんでした。その結果、正当なシナリオにおいて、ユーザーデータの損失または不整合が発生した。今回のリリースでは、更新ロジックが修正され、有効なシナリオはすべて元の状態に戻るようになりました。その他のバグ修正内容は以下のとおりです。
- 継続的なリコンシリエーションと不要な更新に関する問題を修正しました。
- ユーザー入力の検証エラーに対する再キュー処理ロジックを削除しました。