Minikube：Restricted 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 清单时，受限的 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:

旧版本的 minikube 不附带 pod-security-policy 插件，因此插件启用的策略必须单独应用于集群

我做了什么：

1。在启用 PodSecurityPolicy 准入控制器和 pod-security-policy 插件的情况下启动 minikube。

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

pod-security-policy 插件必须与准入控制器一起启用，以防止在引导期间出现问题。

2。创建authenticated user：

在这方面，Kubernetes 没有代表普通用户帐户的对象。普通用户无法通过 API 调用添加到集群中。

即使无法通过 API 调用添加普通用户，但任何提供由集群的证书颁发机构 (CA) 签名的有效证书的用户都被视为已通过身份验证。在此配置中，Kubernetes 从证书的“主题”中的通用名称字段（例如“/CN=bob”）中确定用户名。从那里，基于角色的访问控制 (RBAC) 子系统将确定用户是否有权对资源执行特定操作。

Here 您可以找到示例如何正确准备 X509 客户端证书并相应地配置 KubeConfig 文件。

最重要的部分是正确定义通用名（CN）和组织字段（O）：

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

主题的通用名称 (CN) 将用作身份验证请求的用户名。组织字段 (O) 将用于指示用户的组成员身份。

---

最后我已经根据标准 minikube 设置创建了您的配置，并且由于 hostPID: true 或 securityContext.privileged: true 而无法重新创建您的问题

考虑：

一个）。验证您的用于身份验证的客户端证书和kubeconfig 文件是否已正确创建/设置，尤其是公用名 (CN) 和组织字段 (O)。

b）。确保在代表不同用户执行请求时在正确的上下文之间切换。

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