Minikube：受限制的PodSecurityPolicy在尝试创建特权容器时不受限制

问题描述

我在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。我应该不能用特权容器创建一个容器。但是吊舱正在创建。不知道我在想什么

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

解决方法

我使用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导致无法重新创建您的问题

要考虑：

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

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

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