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

问题描述 投票:1回答:1

在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的名称空间。

我曾尝试这样做。

首先,我从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的使用。然后,我将此新角色绑定到示例名称空间中的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绑定到system:authenticated组,而eks.restricted绑定到我的部署正在其下运行的serviceAccount,因此我的组合访问权是同时访问。由于eks.restricted是非变异的,因此它应该是适用的变异,因此它不能创建POD。但这不是事实。 POD启动正常。

[作为进一步的测试,我在SA角色(上面列出)中添加了eks.privileged,希望它的功能类似于我的原始示例。并非如此,POD可以很好地创建。

试图找出原因。

security kubernetes
1个回答
0
投票

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

请仔细检查本文以了解详细信息:https://dev.to/anupamncsu/pod-security-policy-on-eks-mp9

© www.soinside.com 2019 - 2024. All rights reserved.