2

我在 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 资源。

但是，当我使用 发布 pod 清单时securityContext.privileged: true，受限的 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
4

1 回答 1

2

我使用 minikube 遵循了 PodsecurityPolicy。 默认情况下，仅在将 Minikube 1.11.1 与 Kubernetes 1.16.x 或更高版本一起使用时才有效。

旧版本 minikube 的注意事项：

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

我做了什么：

1 . 启动 minikube 并启用 PodSecurityPolicy 准入控制器并启用 pod-security-policy 插件。

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

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

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

考虑：

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

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

   f.e. kubectl get pods --context=NewUser-context
于 2020-08-18T10:11:52.880 回答