Tanzu Kubernetes Grid サービス は、PodSecurityPolicy アドミッション コントローラが有効な状態で Tanzu Kubernetes クラスタをプロビジョニングします。これは、ワークロードをデプロイするためにはポッド セキュリティ ポリシーが必要であることを意味します。クラスタ管理者は、ユーザー アカウントから任意の名前空間に、およびサービス アカウントから kube-system 名前空間にポッドをデプロイできます。その他のすべてのユースケースでは、PodSecurityPolicy オブジェクトに明示的にバインドする必要があります。クラスタには、バインド可能なデフォルトのポッド セキュリティ ポリシーがあります。また、独自のポッド セキュリティ ポリシーをクラスタに作成することもできます。
Kubernetes のポッド セキュリティ ポリシーについて
Kubernetes のポッド セキュリティ ポリシー (PSP) は、ポッドのセキュリティを制御するクラスタレベルのリソースです。PSP を使用すると、デプロイできるポッドのタイプと、それらをデプロイできるアカウントのタイプを制御できます。
PodSecurityPolicy リソースは、デプロイのためにポッドが満たす必要のある必要な一連の条件を定義しています。条件が満たされていない場合は、ポッドをデプロイできません。1 つの PodSecurityPolicy で 1 つのポッド全体を検証する必要があります。ポッドのルールを複数のポリシーに分けて定義することはできません。
Kubernetes では、さまざまな方法でポッド セキュリティ ポリシーを使用できます。一般的なアプローチは、ロールベースのアクセス コントロール (RBAC) オブジェクトを使用するものです。ClusterRole および ClusterRoleBinding は、クラスタ全体に適用されます。Role および RoleBinding は、特定の名前空間に適用されます。RoleBinding を使用すると、ポッドはこのバインドと同じ名前空間内でのみ実行されます。
Kubernetes ポッドの作成には、直接的な方法と間接的な方法の 2 つがあります。ユーザー アカウントを使用してポッドの仕様をデプロイすることにより、ポッドを直接作成します。Deployment や DaemonSet などの上位レベルのリソースを定義することにより、ポッドを間接的に作成します。この場合、基盤となるポッドがサービス アカウントによって作成されます。
PSP を効果的に使用するには、両方のポッド作成ワークフローを考慮する必要があります。ユーザーがポッドを直接作成すると、そのユーザー アカウントにバインドされた PSP によって操作が制御されます。ユーザーがサービス アカウントを使用してポッドを作成する場合、PSP は、ポッドの作成に使用するサービス アカウントにバインドする必要があります。ポッド仕様でサービス アカウントが指定されていない場合は、名前空間のデフォルトのサービス アカウントが使用されます。
詳細については、Kubernetes のドキュメントでポッド セキュリティ ポリシー、RBAC、およびサービス アカウントについて参照してください。
Tanzu Kubernetes クラスタのデフォルトの PodSecurityPolicy
| デフォルトの PSP | 権限 | 説明 | 関連付けられているデフォルトの ClusterRole |
|---|---|---|---|
vmware-system-privileged |
任意のユーザーとして実行 | 許可的な PSP。PSP アドミッション コントローラが有効になっていないクラスタの実行と同等です。 | psp:vmware-system-privileged がこの PSP を使用可能 |
vmware-system-restricted |
非 root として実行 | 制限的な PSP。ポッド コンテナへの特権アクセスを許可せず、root へのエスカレーションをブロックし、いくつかのセキュリティ メカニズムを使用する必要があります。 | psp:vmware-system-restricted がこの PSP を使用可能 |
Tanzu Kubernetes クラスタのデフォルト バインドはない
Tanzu Kubernetes Grid サービス には、Tanzu Kubernetes クラスタのデフォルトの RoleBinding と ClusterRoleBinding はありません。
vSphere 名前空間 に対する編集権限が付与されている vCenter Single Sign-On ユーザーは、その名前空間でデプロイされるすべての Tanzu Kubernetes クラスタで cluster-admin ロールに割り当てられます。認証されたクラスタ管理者は、暗黙的に vmware-system-privileged PSP を使用できます。厳密には ClusterRoleBinding とは異なりますが、実質的には同じです。
クラスタ管理者は、ユーザーがクラスタにデプロイできるポッドのタイプを許可または制限するために、何らかのバインドを定義する必要があります。RoleBinding を使用すると、バインドと同じ名前空間でのみポッドの実行が許可されます。これをシステム グループと組み合わせると、名前空間で実行されているすべてのポッドへのアクセスを許可することができます。クラスタに対して認証を行う管理者以外のユーザーは、authenticated ロールに割り当てられ、デフォルトの PSP にバインドできます。開発者に対する Tanzu Kubernetes クラスタへのアクセス権の付与を参照してください。
Tanzu Kubernetes クラスタでのデフォルトの PodSecurityPolicy の効果
- クラスタ管理者はそれぞれのユーザー アカウントを使用して、任意の名前空間に特権ポッドを直接作成できます。
- クラスタ管理者は、kube-system 名前空間に Deployments、StatefulSets、および DaemonSet（それぞれが特権ポッドを作成）を作成できます。別の名前空間を使用する場合は、Tanzu Kubernetes Guestbook のチュートリアルを参照してください。
- クラスタ管理者は、独自の PSP を（2 つのデフォルトの PSP に加えて）作成して任意のユーザーにバインドすることができます。独自の PSP を定義する場合は、Kubernetes のドキュメントでポリシーの順序について参照してください。
- クラスタ管理者が PSP を認証されたユーザーにバインドするまで、認証されたユーザーは、特権の有無にかかわらずポッドを作成することはできません。Tanzu Kubernetes Guestbook のチュートリアルを参照してください。
