2.10. 既知の問題

RunAsUser パーミッションが Linux ベースの Pod のセキュリティーコンテキストに設定されている場合、Projected ファイルには、コンテナーユーザー所有権を含む適切なパーミッションが設定されます。ただし、Windows の同等の RunAsUsername パーミッションが Windows Pod に設定されている場合、kubelet は Projected ボリュームのファイルに正しい所有権を設定できなくなります。この問題は、ベストプラクティスに従わない hostPath volume と組み合わせて使用すると悪化する可能性があります。たとえば、Pod に C:\var\lib\kubelet\pods\ フォルダーへのアクセス権限を付与すると、Pod が他の Pod からサービスアカウントトークンにアクセスできるようになります。

デフォルトでは、この例では Windows の Projected ボリュームファイルに示されるように、projected ファイルに以下の所有者が設定されます。

Path   : Microsoft.PowerShell.Core\FileSystem::C:\var\run\secrets\kubernetes.io\serviceaccount\..2021_08_31_22_22_18.318230061\ca.crt
Owner  : BUILTIN\Administrators
Group  : NT AUTHORITY\SYSTEM
Access : NT AUTHORITY\SYSTEM Allow  FullControl
         BUILTIN\Administrators Allow  FullControl
         BUILTIN\Users Allow  ReadAndExecute, Synchronize
Audit  :
Sddl   : O:BAG:SYD:AI(A;ID;FA;;;SY)(A;ID;FA;;;BA)(A;ID;0x1200a9;;;BU)

これは、ContainerAdministrator ロールを持つユーザーなどのすべての管理者ユーザーに対して読み取り、書き込み、実行アクセスがある一方で、管理者以外のユーザーが読み取りおよび実行アクセスを持っていることを示しています。

さらに、Windows Pod がデフォルトの RunAsUser パーミッションセットで Projected ボリュームで作成される場合、Pod は ContainerCreating フェーズで停止します。

これらの問題に対応するため、OpenShift Container Platform は Pod のセキュリティーコンテキストで設定される Projected サービスアカウントボリュームでのファイルパーミッションの処理を Windows の projected ボリュームに反映しないように強制します。Windows Pod のこの動作は、OpenShift Container Platform 4.7 より前のすべての Pod タイプでどのように機能するかについて使用されるファイルパーミッションの処理であることに注意してください。(BZ#1971745)