Guestbook アプリケーションを Tanzu Kubernetes クラスタにデプロイして、サービス アカウントのポッド セキュリティ ポリシー、およびデプロイとサービスの作成について確認します。
Guestbook アプリケーションのデプロイは、Kubernetes を確認する際の一般的な手段です。Tanzu Kubernetes Grid サービス によってプロビジョニングされた Tanzu Kubernetes クラスタにすべてのゲストブック YAML ファイルをデプロイすると、アプリケーション ポッドは正常に作成されません。kubectl describe pod
コマンドを実行すると、次のエラー メッセージが表示されます。
“Error: container has runAsNonRoot and image will run as root”
Guestbook アプリケーションは、deployment
と replicaset
の両方のリソースを使用して特権コンテナをデフォルトの名前空間にデプロイします。Tanzu Kubernetes クラスタでは PodSecurityPolicy コントローラが有効になっているため、クラスタ ユーザーが Guestbook アプリケーション ポッドを作成しようとすると、これらのコントローラのサービス アカウントが PodSecurityPolicy に対してチェックされます。適切な PSP がこれらのサービス アカウントにバインドされていない場合、アプリケーションはデプロイされません。
デフォルトでは、Tanzu Kubernetes 管理者はそれぞれのユーザー アカウントを使用して、任意の名前空間に特権ポッドを直接作成できます。ただし、Guestbook アプリケーションはサービス アカウントを使用して特権コンテナをデプロイします。クラスタ管理者は、kube-system
名前空間に Deployments、StatefulSets、および DaemonSet を作成できます。ただし、Guestbook アプリケーションはこれらのリソースをデフォルトの名前空間にデプロイします。また、管理者以外のユーザーは、適切な PSP やバインドがなければ特権ポッドも権限のないポッドも一切作成できません。
1 つの解決策は、デフォルトの特権 PSP へのバインドを作成して、Guestbook アプリケーションをデプロイできるようにすることです。特権 PodSecurityPolicy により、バインドされているアカウントに対して、root として実行されるポッドと特権コンテナが許可されます。vmware-system-privileged
クラスタ全体に適用される ClusterRoleBinding を作成できますが、それによって必要以上の権限を付与することになり、最小限の権限の原則に違反する可能性があります。より適切な方法は、システム サービス アカウントにデフォルトの名前空間で特権 PodSecurityPolicy の使用を許可するよう RoleBinding を作成することです。詳細については、『ポッド セキュリティ ポリシーのロール バインドの例』を参照してください。