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