security - POD 安全策略评估顺序(多个角色)

Question

在 AWS EKS 上运行 1.15。

默认情况下，AWS 提供 eks.privileged PSP(记录在这里:https://docs.aws.amazon.com/eks/latest/userguide/pod-security-policy.html)。这分配给所有经过身份验证的用户。

然后我创建了一个更严格的 PSP eks.restricted :

---
# restricted pod security policy

apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
  creationTimestamp: null
  labels:
    kubernetes.io/cluster-service: "true"
    eks.amazonaws.com/component: pod-security-policy
  name: eks.restricted
spec:
  allowPrivilegeEscalation: false
  allowedCapabilities:
  - '*'
  fsGroup:
    rule: RunAsAny
  hostPorts:
  - max: 65535
    min: 0
  runAsUser:
    rule: MustRunAsNonRoot
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  volumes:
  - '*'

以上是非变异PSP。我也修改了默认的 eks.privilged PSP 通过添加以下注释对其进行修改

seccomp.security.alpha.kubernetes.io/allowedProfileNames: docker/default
seccomp.security.alpha.kubernetes.io/defaultProfileName: docker/default

最后，我更新了 clusterrole 以添加到我创建的新 PSP 中:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: eks:podsecuritypolicy:privileged
  labels:
    kubernetes.io/cluster-service: "true"
    eks.amazonaws.com/component: pod-security-policy
rules:
- apiGroups:
  - policy
  resourceNames:
  - eks.privileged
  - eks.restricted
  resources:
  - podsecuritypolicies
  verbs:
  - use

这样做的结果是 eks.restricted成为默认的 PSP，因为它是非变异的( https://v1-15.docs.kubernetes.io/docs/concepts/policy/pod-security-policy/#policy-order 并且列表的顺序无关紧要)。

这太棒了。但是我想要完成的是创建一个默认为 eks.restricted 的命名空间。而所有其他默认为 eks.privileged .

我试图这样做。

首先我删除了 eks.restricted来自集群角色 eks:podsecuritypolicy:privileged因此 eks.privileged 现在是集群范围的默认设置。在我的命名空间中，我创建了一个新角色

---

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  annotations:
  labels:
    eks.amazonaws.com/component: pod-security-policy
    kubernetes.io/cluster-service: "true"
  name: eks:podsecuritypolicy:restricted
rules:
- apiGroups:
  - policy
  resourceNames:
  - eks.restricted
  resources:
  - podsecuritypolicies
  verbs:
  - use

此角色授予 PSP 使用权限 eks.restricted .然后，我将此新角色绑定(bind)到示例命名空间中的 ServiceAccount。

---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: psp-restricted
  namespace: psp-example
roleRef:
  kind: Role
  name: eks:podsecuritypolicy:restricted
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  name: privileged-sa
  namespace: psp-example

最后我创建了一个部署，它违反了 PSP eks.restricted使用此 serviceAccount

apiVersion: apps/v1
kind: Deployment
metadata:
  name: centos-deployment
  namespace: psp-example
  labels:
    app: centos
spec:
  replicas: 3
  selector:
    matchLabels:
      app: centos
  template:
    metadata:
      labels:
        app: centos
    spec:
      serviceAccountName: privileged-sa
      containers:
      - name: centos
        #image: centos:centos7
        image: datinc/permtest:0
        command:
          - '/bin/sleep'
          - '60000'

我的假设是，这将像我在本文开头的初始示例/测试中那样起作用。我的组合访问权限是 eks.privileged由于它绑定(bind)到 system:authenticated group 和 eks.restricted绑定(bind)到我的部署正在运行的 serviceAccount。由于 eks.restricted是非变异的，它应该是适用的，因此它应该无法创建 POD。但事实并非如此。 POD 启动得很好。

作为进一步的测试，我添加了 eks.privileged到 SA 角色(上面列出的)，希望它像我原来的例子一样工作。它没有，POD 创建就好了。

试图弄清楚这是为什么。

Answer 1

在 AWS，您的部署使用 ServiceAccount replicaset-controller在命名空间 kube-system ，因此您需要从 ClusterRoleBinding eks:podsecuritypolicy:authenticated 中删除它或删除它。

请查看这篇文章的详细信息:
https://dev.to/anupamncsu/pod-security-policy-on-eks-mp9