This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.2.10. 既知の問題
-
これらの Pod に関連付けられた Projected ボリュームを使用して
RunAsUserName
が SecurityContext に設定された Windows Pod を作成する場合、Projected エンティティーのファイル所有者のパーミッションは無視され、所有者のパーミッションが誤って設定されます。 - Windows ノードについては、Web コンソールで利用可能なファイルシステムのグラフは表示されません。この原因は、ファイルシステムのクエリーの変更にあります。これは、WMCO の今後のリリースで修正されます。(BZ#1930347)
- 現時点で、WMCO で使用される Prometheus windows_exporter は HTTP 経由でメトリクスを収集するため、安全でないと見なされます。信頼できるユーザーのみがエンドポイントからメトリクスを取得できるようにする必要があります。window_exporter 機能では、最近 HTTPS 設定のサポートが追加されましたが、この設定は WMCO については実装されていません。WMCO での HTTPS 設定のサポートは今後のリリースで追加される予定です。
RunAsUser
パーミッションが Linux ベースの Pod のセキュリティーコンテキストに設定されている場合、Projected ファイルには、コンテナーユーザー所有権を含む適切なパーミッションが設定されます。ただし、Windows の同等のRunAsUsername
パーミッションが Windows Pod に設定されている場合、kubelet は Projected ボリュームのファイルに正しい所有権を設定できなくなります。この問題は、ベストプラクティスに従わない hostPath volume と組み合わせて使用すると悪化する可能性があります。たとえば、Pod にC:\var\lib\kubelet\pods\
フォルダーへのアクセス権限を付与すると、Pod が他の Pod からサービスアカウントトークンにアクセスできるようになります。デフォルトでは、この例では Windows の Projected ボリュームファイルに示されるように、projected ファイルに以下の所有者が設定されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow これは、
ContainerAdministrator
ロールを持つユーザーなどのすべての管理者ユーザーに対して読み取り、書き込み、実行アクセスがある一方で、管理者以外のユーザーが読み取りおよび実行アクセスを持っていることを示しています。重要OpenShift Container Platform は、オペレーティングシステムに関係なく、
RunAsUser
セキュリティーコンテキストをすべての Pod に適用します。これは、Windows Pod のRunAsUser
パーミッションがセキュリティーコンテキストに自動的に適用されることを意味します。さらに、Windows Pod がデフォルトの
RunAsUser
パーミッションセットで Projected ボリュームで作成される場合、Pod はContainerCreating
フェーズで停止します。これらの問題に対応するため、OpenShift Container Platform は Pod のセキュリティーコンテキストで設定される Projected サービスアカウントボリュームでのファイルパーミッションの処理を Windows の projected ボリュームに反映しないように強制します。Windows Pod のこの動作は、OpenShift Container Platform 4.7 より前のすべての Pod タイプでどのように機能するかについて使用されるファイルパーミッションの処理であることに注意してください。(BZ#1971745)