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清单时，受限pod安全策略并没有阻止我创建该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--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”)的‘subject’中的公共名称字段来确定用户名。从那里，基于角色的访问控制(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