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

在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的 namespace ，而所有其他默认为eks.privileged的 namespace 。

我试图这样做。

首先，我从ClusterRole 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)到示例 namespace 中的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

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

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组，并且对eks.restricted绑定(bind)到我的部署正在其下运行的serviceAccount，因此我对eks.restricted的组合访问是同时进行的。由于eks.privileged是非突变的，因此它应该是适用的，并且这样就不能创建POD。但是，事实并非如此。 POD启动正常。

作为进一步的测试，我在SA角色(上面列出)中添加了ojit_code，希望它的功能与我的原始示例相同。事实并非如此，POD可以很好地创建。

试图找出原因。

最佳答案

在AWS上，您的部署使用 namespace replicaset-controller中的ServiceAccount kube-system，因此您需要将其从ClusterRoleBinding eks:podsecuritypolicy:authenticated中删除或删除。

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

关于security - POD安全策略评估顺序(多个角色)，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/61021712/