Запуск 1.15 на AWS EKS.
По умолчанию 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
Наконец, я обновляю кластерролл, чтобы добавить в новый созданный мной 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 -заказ и порядок списка не имеет значения).
Это замечательно. Но то, что я пытаюсь сделать sh, это создать единое пространство имен по умолчанию eks.restricted, в то время как все остальные по умолчанию eks.privileged.
Я попытался сделать это так.
Сначала я удалил eks.restricted из ClusterRole 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
Наконец я создал развертывание, которое нарушает 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 связан с тем, что он привязан к системе: аутентифицированная группа и eks.restricted привязаны к сервису, под которым выполняется мое развертывание. Так как eks.restricted не является мутирующим, то должен применяться тот, который применяется, и поэтому он не должен создавать POD. Но это не то, что происходит. PODы запускаются просто отлично.
В качестве дополнительного теста я добавил eks.privileged к роли SA (приведенной выше), ожидая, что она будет функционировать, как в моем исходном примере. Это не так, POD создают просто отлично.
Попытка выяснить, почему это так.