kubernetes - Minikube:在尝试创建特权容器时，受限 PodSecurityPolicy 不受限制

Question

我在 minikube 中启用了 podsecuritypolicy。默认情况下，它创建了两个 psp - 特权和受限。

NAME         PRIV    CAPS   SELINUX    RUNASUSER          FSGROUP     SUPGROUP    READONLYROOTFS   VOLUMES
privileged   true    *      RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *
restricted   false          RunAsAny   MustRunAsNonRoot   MustRunAs   MustRunAs   false            configMap,emptyDir,projected,secret,downwardAPI,persistentVolumeClaim

我还创建了一个 linux 用户 - kubexz，为此我创建了 ClusterRole 和 RoleBinding 来限制仅管理 kubexz 命名空间上的 pod，并使用受限制的 psp。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: only-edit
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["create", "delete", "deletecollection", "patch", "update", "get", "list", "watch"]
- apiGroups: ["policy"]
  resources: ["podsecuritypolicies"]
  resourceNames: ["restricted"]
  verbs: ["use"]

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: kubexz-rolebinding
  namespace: kubexz
subjects:
   - kind: User
     name: kubexz
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: only-edit

我已经在我的 kubexz 用户 $HOME/.kube 中设置了 kubeconfig 文件。 RBAC 工作正常 - 从 kubexz 用户，我只能按预期在 kubexz 命名空间中创建和管理 pod 资源。
但是当我发布带有 securityContext.privileged: true 的 pod list 时，受限的 podsecuritypolicy 并没有阻止我创建那个 pod。我应该无法创建具有特权容器的 pod。但是 pod 正在创建。不知道我错过了什么

apiVersion: v1
kind: Pod
metadata:
  name: new-pod
spec:
  hostPID: true
  containers:
  - name: justsleep
    image: alpine
    command: ["/bin/sleep", "999999"]
    securityContext:
      privileged: true

Answer 1

我使用 minikube 遵循 PodsecurityPolicy。
默认情况下，仅在将 Minikube 1.11.1 与 Kubernetes 1.16.x 或更高版本一起使用时才有效 .

Note for older versions of minikube:

Older versions of minikube do not ship with the pod-security-policy addon, so the policies that addon enables must be separately applied to the cluster

我做了什么:
1 .在 PodSecurityPolicy 准入 Controller 和 pod-security-policy 插件启用的情况下启动 minikube。

minikube start --extra-config=apiserver.enable-admission-plugins=PodSecurityPolicy --addons=pod-security-policy

The pod-security-policy addon must be enabled along with the admission controller to prevent issues during bootstrap.

2 .创建 authenticated user :

In this regard, Kubernetes does not have objects which represent normal user accounts. Normal users cannot be added to a cluster through an API call.

Even though normal user cannot be added via an API call, but any user that presents a valid certificate signed by the cluster’s certificate authority (CA) is considered authenticated. In this configuration, Kubernetes determines the username from the common name field in the ‘subject’ of the cert (e.g., “/CN=bob”). From there, the role based access control (RBAC) sub-system would determine whether the user is authorized to perform a specific operation on a resource.

Here您可以找到如何正确准备 X509 客户端证书并相应地配置 KubeConfig 文件的示例。
最重要的部分是正确定义 通用名 (CN) 和 组织字段 (O) :

openssl req -new -key DevUser.key -out DevUser.csr -subj "/CN=DevUser/O=development"

The common name (CN) of the subject will be used as username for authentication request. The organization field (O) will be used to indicate group membership of the user.

最后，我根据标准 minikube 设置创建了您的配置，并且由于 hostPID: true 无法重现您的问题或 securityContext.privileged: true要考虑:
)。验证您的 用于身份验证的客户端证书 和 kubeconfig文件已正确创建/设置，尤其是通用名称 (CN) 和组织字段 (O)。
b )。确保在代表不同用户执行请求时在适当的上下文之间切换。

   f.e. kubectl get pods --context=NewUser-context