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

Question

我已经在minikube中启用了podsecuritypolicy。默认情况下，它创建了两个psp-privileged和restricted。

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用户开始，我只能按预期在kubexznamespace中创建和管理pod资源。

但是，当我发布带有securityContext.privileged: true的pod清单时，受限的podsecuritypolicy并没有阻止我创建该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或更高版本时，此功能才有效。

注意旧版本的minikube:

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

我做了什么：

1。在启用PodSecurityPolicy准入控制器和pod安全策略插件的情况下启动minikube。

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

pod安全策略插件必须与准入控制器一起启用，以防止引导过程中出现问题。

2。创建经过身份验证的用户：

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

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

在这里，您可以找到如何正确准备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