如何解决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
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。