对于您要求的功能，我们已使用 Kubernetes 1.13 将其启用：Amazon Elastic Container Service for Kubernetes (EKS) 现支持 Pod 安全策略。在本篇博文中，我们将从集群管理员和开发人员的角度，审视 PSP 是什么，如何在 Kubernetes 控制平面中启用它们以及如何使用它们。
什么是 Pod 安全策略，我为何要关心？
作为集群管理员，您可能想知道如何在集群中强制执行有关 pod 运行时属性的特定策略。例如，您可能希望阻止开发人员使用未定义用户的容器运行 pod（因此，以 root 身份运行）。您可能在 pod 规范中创建了关于开发人员设置安全上下文的文档，对此开发人员可能遵循……也可能选择不遵循。无论如何，您都需要一种在集群范围内强制执行此类策略的机制。
解决方法是将 Pod 安全策略 (PSP) 作为深度防御策略的一部分。
需要注意的是，pod 的安全上下文定义了各种权限和访问控制设置，例如自主访问控制（比如基于特定用户 ID 访问文件）、功能（比如通过定义 AppArmor 配置文件）、配置 SECCOMP（通过过滤某些系统调用），以及允许您实施强制访问控制（通过 SELinux）。
另一方面，PSP 是集群范围的资源，使您可以作为集群管理员在集群中强制使用安全上下文。PSP 由 API 服务器的准入控制器强制执行。简而言之：如果 pod 规范不符合您在 PSP 中定义的内容，则 API 服务器将拒绝启动它。要使 PSP 正常工作，必须启用相应的 [准入插件](，并且必须授予用户权限。EKS 1.13 集群现在默认启用 PSP 准入插件，因此 EKS 用户无需进行任何操作。
通常，您希望根据最小权限原则定义 PSP：从强制执行的无根容器到只读根文件系统，到对可从主机安装的项目的限制（pod 中的容器在其上运行的 EC2 实例）。
使用
新的 EKS 1.13 集群创建了一个名为 eks.privileged 的默认策略，该策略对可接入系统的 pod 类型没有限制（相当于在禁用 PodSecurityPolicy 控制器的情况下运行集群）。
要查看 EKS 集群中现有的 pod 安全策略，请执行以下操作：
$ kubectl get pspNAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP READONLYROOTFS VOLUMESeks.privileged true * RunAsAny RunAsAny RunAsAny RunAsAny false *
复制代码
现在，描述我们为您定义的默认策略：
$ kubectl describe psp eks.privileged
复制代码
正如您在下面的输出中看到的那样 – 一切正常！ 此策略允许任何类型的 pod 规范：
Name: eks.privileged
Settings: Allow Privileged: true Allow Privilege Escalation: true Default Add Capabilities: <none> Required Drop Capabilities: <none> Allowed Capabilities: * Allowed Volume Types: * Allow Host Network: true Allow Host Ports: 0-65535 Allow Host PID: true Allow Host IPC: true Read Only Root Filesystem: false SELinux Context Strategy: RunAsAny User: <none> Role: <none> Type: <none> Level: <none> Run As User Strategy: RunAsAny Ranges: <none> FSGroup Strategy: RunAsAny Ranges: <none> Supplemental Groups Strategy: RunAsAny Ranges: <none>
复制代码
请注意，任何经过身份验证的用户都可以按照当前配置在此 EKS 集群上创建任何 pod，证明如下：
$ kubectl describe clusterrolebindings eks:podsecuritypolicy:authenticated
复制代码
上述命令输出显示集群角色 eks:podsecuritypolicy:privileged 被分配给任何 system:authenticated 用户：
Name: eks:podsecuritypolicy:authenticatedLabels: eks.amazonaws.com/component=pod-security-policy kubernetes.io/cluster-service=trueAnnotations: kubectl.kubernetes.io/last-applied-configuration: ...
Role: Kind: ClusterRole Name: eks:podsecuritypolicy:privilegedSubjects: Kind Name Namespace ---- ---- --------- Group system:authenticated
复制代码
请注意，如果有多个 PSP 可用，Kubernetes 准入控制器会选择第一个成功验证的策略。策略按其名称的字母顺序排序，不改变 pod 的策略优先于变形策略。
现在让我们创建一个新的 PSP，我们称之为 eks.restrictive。首先，创建一个专用命名空间以及一个服务帐户。我们将对非管理员用户使用此服务帐户：
$ kubectl create ns psp-eks-restrictivenamespace/psp-eks-restrictive created
$ kubectl -n psp-eks-restrictive create sa eks-test-userserviceaccount/eks-test-user created
$ kubectl -n psp-eks-restrictive create rolebinding eks-test-editor \ --clusterrole=edit \ --serviceaccount=psp-eks-restrictive:eks-test-user
rolebinding.rbac.authorization.k8s.io/eks-test-editor created
复制代码
接下来，创建两个别名，以突出显示管理员和非管理员用户之间的区别：
$ alias kubectl-admin='kubectl -n psp-eks-restrictive'$ alias kubectl-dev='kubectl --as=system:serviceaccount:psp-eks-restrictive:eks-test-user -n psp-eks-restrictive'
复制代码
现在，使用集群管理员角色，创建一个不允许使用主机联网创建 pod 的策略：
$ cat > /tmp/eks.restrictive-psp.yaml <<EOFapiVersion: policy/v1beta1kind: PodSecurityPolicymetadata: name: eks.restrictivespec: hostNetwork: false seLinux: rule: RunAsAny supplementalGroups: rule: RunAsAny runAsUser: rule: RunAsAny fsGroup: rule: RunAsAny volumes: - '*'EOF
$ kubectl-admin apply -f /tmp/eks.restrictive-psp.yamlpodsecuritypolicy.policy/eks.restrictive created
复制代码
另外，不要忘记删除默认的（宽容的策略）eks.privileged：
$ kubectl delete psp eks.privileged$ kubectl delete clusterrole eks:podsecuritypolicy:privileged$ kubectl delete clusterrolebindings eks:podsecuritypolicy:authenticated
复制代码
警告
在添加自己的 PSP 之前删除默认 EKS 策略 可能会损害集群。删除默认策略时，除满足新命名空间中安全上下文的 pod 外，无法在集群上创建任何 pod。对于现有集群，请确保在删除默认策略之前，创建涵盖所有正在运行的 pod 和命名空间的多个限制策略
现在，确认已创建策略：
$ kubectl get pspNAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP READONLYROOTFS VOLUMESeks.restrictive false RunAsAny RunAsAny RunAsAny RunAsAny false *
复制代码
最后，作为非特权用户（模拟开发人员），尝试创建违反策略的 pod：
$ kubectl-dev apply -f- <<EOFapiVersion: v1kind: Podmetadata: name: busyboxspec: containers: - name: busybox image: busybox command: [ "sh", "-c", "sleep 1h" ]EOF
复制代码
正如您所预期的那样，您会得到以下结果：
Error from server (Forbidden): error when creating "STDIN": pods "busybox" is forbidden: unable to validate against any pod security policy: []
复制代码
上述操作失败，因为我们尚未授予开发人员适当的权限。换句话说，没有对开发者用户 eks-test-user 进行角色绑定。因此，让我们通过为 pod 安全策略 eks.restrictive 创建角色 psp:unprivileged 对其进行更改：
$ kubectl-admin create role psp:unprivileged \ --verb=use \ --resource=podsecuritypolicy \ --resource-name=eks.restrictive
role.rbac.authorization.k8s.io/psp:unprivileged created
复制代码
现在，创建 rolebinding 以授予 eks-test-user 有关 eks.restrictive 策略的 use 动词。
$ kubectl-admin create rolebinding eks-test-user:psp:unprivileged \ --role=psp:unprivileged \ --serviceaccount=psp-eks-restrictive:eks-test-user
rolebinding.rbac.authorization.k8s.io/eks-test-user:psp:unprivileged created
复制代码
验证 eks-test-user 是否可以使用 eks.restrictive：
$ kubectl-user auth can-i use podsecuritypolicy/eks.restrictiveyes
复制代码
此时，开发人员 eks.restrictive 用户应该能够创建一个 pod：
$ kubectl-user apply -f- <<EOFapiVersion: v1kind: Podmetadata: name: busyboxspec: containers: - name: busybox image: busybox command: [ "sh", "-c", "sleep 1h" ]EOFpod/busybox created
复制代码
好的，有效！ 但是，由于我们在上述 eks.restrictive 中定义的内容，我们应拒绝基于主机联网的 pod 创建：
$ kubectl-user apply -f- <<EOFapiVersion: v1kind: Podmetadata: name: privilegedspec: hostNetwork: true containers: - name: busybox image: busybox command: [ "sh", "-c", "sleep 1h" ]EOF
Error from server (Forbidden): error when creating "STDIN": pods "privileged" is forbidden: unable to validate against any pod security policy: [spec.securityContext.hostNetwork: Invalid value: true: Host network is not allowed to be used]
复制代码
非常好！ 这证实了 PSP eks.restrictive 按预期工作，限制开发人员创建特权 pod。
新增功能
对于使用 Kubernetes 1.13 版的所有新 EKS 集群，PSP 现在可用。对于已从先前版本升级的集群，在升级过程中会自动创建完全允许的 PSP。您的主要任务是定义适合您的环境的合理 PSP，并按上述方法启用它们。从合理的角度看，我的意思是（例如）与生产环境相比，您可以选择在开发/测试环境中减少限制。或者，同样可能的是，不同的项目或团队需要保护级别不同可能，因此 PSP 也不同。
最后一点：作为集群管理员，请务必向开发人员介绍一般的安全上下文，特别是 PSP。将 CI/CD 管道测试 PSP 作为冒烟测试，以及其他与安全相关的主题的一部分，例如通过 RBAC 角色和绑定定义的测试权限。
本文转载自 AWS 技术博客。
原文链接：
https://amazonaws-china.com/cn/blogs/china/using-pod-security-policies-amazon-eks-clusters/
评论