共计 9219 个字符，预计需要花费 24 分钟才能阅读完成。
如何简化生产中的 Pod 安全策略，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
Pod 安全策略对于强化 K8S 集群安全至关重要。本文将延续之前的文章继续深入介绍 Pod 安全策略。
首先，简单介绍了如何将 Pod 与 Pod 安全策略相关联，并使用 RBAC 来展示具体步骤。然后介绍如何在 Rancher 中启用默认的 PSP 和创建自定义 PSP。最后将使用一种工具来简化生产中 Pod 安全策略的使用，极大提升生产力，赶紧戳文咯~
我们有意省略了有关基于角色的访问控制（RBAC）以及如何将 Pod 与特定 PSP 连接的具体细节。那下面让我们继续深入研究 PSP。
将 Pod 与 Pod 安全策略匹配
你可能已经注意到，PSP 模式没有与任何 Kubernetes 命名空间、Service Account 或 Pod 相关联。实际上，PSP 是集群范围的资源。那么，我们如何指定哪些 Pod 应该由哪些 PSP 来管理呢？下图显示了所有参与组件、资源以及准入流程的工作方式。
也许一开始听起来很复杂。现在，我们来详细介绍一下。
部署 Pod 时，准入控制将根据请求 deployment 的对象来应用策略。
Pod 本身没有任何关联的策略——执行该 Deployment 的是 service account。在上图中，Jorge 使用 webapp-sa service account 部署了 pod。
RoleBinding 将 service account 与 Roles（或 ClusterRoles）相关联，Role 是指定可以使用 PSP 的资源。在该图中，webapp-sa 与 webapp-role 关联，后者为特定的 PSP 资源提供使用许可。部署 Pod 时，将根据 webapp-sa PSP 对 Pod 进行检查。实际上，一个 service account 可以使用多个 PSP，并且其中一个可以验证 Pod 就足够了。你可以在官方文档中查看详细信息：
https://kubernetes.io/docs/concepts/policy/pod-security-policy/#policy-order
然后，准入控制将决定 Pod 是否符合其中任何一个 PSP。如果 Pod 符合要求，准入控制将调度 Pod；如果 Pod 不符合规定，则会阻止部署。
以上内容可以总结为以下几点：
Pod 身份由其 service account 确定
如果规范中未声明任何 service account，则将使用默认账户
你需要允许使用声明 Role 或 ClusterRole
最后，需要有一个 RoleBinding，它将 Role（从而允许访问使用 PSP）与 Pod 规范中声明的 Servcie Account 相关联。
让我们用一些例子来说明。
RBAC 的真实示例
假设你已经有一个启用了 PSP 的集群，这是采用 PSP 创建限制性 PSP 的常用方法，该 PSP 可以被任意 Pod 使用。然后你将添加更为特定的 PSP，该 PSP 有绑定到特定 service account 的其他特权。拥有默认、安全且严格的策略有助于集群的管理，因为大多数 Pod 不需要特殊的特权或功能，并且在默认情况下即可运行。然后，如果你的某些工作负载需要其他特权，我们可以创建一个自定义 PSP 并将该工作负载的特定 service account 绑定到限制较少的 PSP。
但是，如何将 Pod 绑定到特定的 PSP 而不是默认的受限 PSP？以及如何使用不自动添加 RoleBindings 的普通 Kubernetes 集群来做到这一点？
让我们看一个完整的示例，在该示例中，我们定义一些安全的默认值（集群中任何 service account 都可以使用的受限 PSP），然后为需要该服务的特定 deployment 向单个 service account 提供其他特权。
首先，我们手动创建一个新的命名空间。它不会由 Rancher 管理，所以不会自动创建 RoleBindings。然后我们在该命名空间中尝试部署一个受限的 Pod：
$ kubectl create ns psp-test
$ cat deploy-not-privileged.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: not-privileged-deploy
name: not-privileged-deploy
spec:
replicas: 1
selector:
matchLabels:
app: not-privileged-deploy
template:
metadata:
labels:
app: not-privileged-deploy
spec:
containers:
- image: alpine
name: alpine
stdin: true
tty: true
securityContext:
runAsUser: 1000
runAsGroup: 1000
$ kubectl -n psp-test apply -f deploy-not-privileged.yaml
$ kubectl -n psp-test describe rs
Warning FailedCreate 4s (x12 over 15s) replicaset-controller Error creating: pods not-privileged-deploy-684696d5b5- is forbidden: unable to validate against any pod security policy: []由于命名空间 psp-test 中没有 RoleBinding，且该命名空间绑定到允许使用任何 PSP 的角色，因此无法创建 pod。我们将通过创建集群范围的 ClusterRole 和 ClusterRoleBinding 来解决此问题，以允许任何 Service Account 默认使用受限的 PSP。之前的文章中启用 PSP 时，Rancher 创建了受限 PSP。
resourceNames:
- restricted-psp
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: restricted-role-bind
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: use-restricted-psp
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:serviceaccounts
$ kubectl apply -f clusterrole-use-restricted.yaml我们应用这些更改之后，非特权 deployment 应正常工作。
但是，如果我们需要部署特权 Pod，则不会被现有策略允许：
$ cat deploy-privileged.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: privileged-sa
namespace: psp-test
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: privileged-deploy
name: privileged-deploy
namespace: psp-test
spec:
replicas: 1
selector:
matchLabels:
app: privileged-deploy
template:
metadata:
labels:
app: privileged-deploy
spec:
containers:
- image: alpine
name: alpine
stdin: true
tty: true
securityContext:
privileged: true
hostPID: true
hostNetwork: true
serviceAccountName: privileged-sa
$ kubectl -n psp-test apply -f deploy-privileged.yaml
$ kubectl -n psp-test describe rs privileged-deploy-7569b9969d
Name: privileged-deploy-7569b9969d
Namespace: default
Selector: app=privileged-deploy,pod-template-hash=7569b9969d
Labels: app=privileged-deploy
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedCreate 4s (x14 over 45s) replicaset-controller Error creating: pods privileged-deploy-7569b9969d- is forbidden: unable to validate against any pod security policy: [spec.securityContext.hostNetwork: Invalid value: true: Host network is not allowed to be used spec.securityContext.hostPID: Invalid value: true: Host PID is not allowed to be used spec.containers[0].securityContext.privileged: Invalid value: true: Privileged containers are not allowed]在这种情况下，由于我们创建了 ClusterRoleBinding，所以 Pod 可以使用 PSP，但是 restricted-psp 不会验证 Pod，因为它需要 privileged、hostNetwork 等参数。
我们已经在前文中看到了 restricted-psp 策略。让我们检查一下 default-psp 的细节，这是由 Rancher 在启用 PSP 允许这些特权时创建的：
$ kubectl get psp default-psp -o yaml
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
annotations:
seccomp.security.alpha.kubernetes.io/allowedProfileNames: *
creationTimestamp: 2020-03-10T08:45:08Z
name: default-psp
resourceVersion: 144774
selfLink: /apis/policy/v1beta1/podsecuritypolicies/default-psp
uid: 1f83b803-bbee-483c-8f66-bfa65feaef56
spec:
allowPrivilegeEscalation: true
allowedCapabilities:
- *
fsGroup:
rule: RunAsAny
hostIPC: true
hostNetwork: true
hostPID: true
hostPorts:
- max: 65535
min: 0
privileged: true
runAsUser:
rule: RunAsAny
seLinux:
rule: RunAsAny
supplementalGroups:
rule: RunAsAny
volumes:
- *你可以看到这是一个非常宽松的策略，特别是我们允许 privileged、hostNetwork、hostPID、hostIPC、hostPorts 以及以 root 身份运行以及其他功能。
我们只需要明确允许该 Pod 使用 PSP。我们通过创建类似于现有 restricted-clusterrole 的 ClusterRole，但允许使用 default-psp 资源，然后为我们的 psp-test 命名空间创建 RoleBinding 来将 privileged-sa ServiceAccount 绑定到该 ClusterRole：
$ cat clusterrole-use-privileged.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: use-privileged-psp
rules:
- apiGroups: [policy]
resources: [podsecuritypolicies]
verbs: [use]
resourceNames:
- default-psp
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: privileged-role-bind
namespace: psp-test
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: use-privileged-psp
subjects:
- kind: ServiceAccount
name: privileged-sa
$ kubectl -n psp-test apply -f clusterrole-use-privileged.yaml一会儿之后，特权 Pod 将会被创建。然后你会注意到 restricted-psp 和 default-psp 现在已经可以直接使用。接下来，我们来详细介绍一下它们。
在 Rancher 上默认的 PSP
在 Rancher 中通过编辑集群设置来启用 PSP 准入控制，并选择其中一个已经定义好的 PSP 作为默认选项：
Rancher 将在集群中创建一对 PSP 资源：
restricted-psp：如果你选择“受限（restricted）”作为默认的 PSP
default-psp：默认的 PSP，允许创建特权 Pod。
除了 restricted-psp 和 default-psp，Rancher 还会创建名为 restricted-clusterrole 的 ClusterRole：
annotations:
serviceaccount.cluster.cattle.io/pod-security: restricted
creationTimestamp: 2020-03-10T08:44:39Z
labels:
cattle.io/creator: norman
name: restricted-clusterrole
rules:
- apiGroups:
- extensions
resourceNames:
- restricted-psp
resources:
- podsecuritypolicies
verbs:
- use此 ClusterRole 允许使用 restricted-psp 策略。那么 Binding 在何处才可以允许授权使用 pod ServiceAccount 呢？
对于属于 Rancher 中项目的命名空间，它还在其中为你设置 RoleBinding 配置：
$ kubectl -n default get rolebinding default-default-default-restricted-clusterrole-binding -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
annotations:
podsecuritypolicy.rbac.user.cattle.io/psptpb-role-binding: true
serviceaccount.cluster.cattle.io/pod-security: restricted
labels:
cattle.io/creator: norman
name: default-default-default-restricted-clusterrole-binding
namespace: default
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: restricted-clusterrole
subjects:
- kind: ServiceAccount
name: default
namespace: default资源名称（default-default-default-restricted-clusterrole-binding）可能会令人感到困惑，实际上它的构成为：
default-serviceaccountname-namespace-restricted-clusterrole-binding
并且如果你创建一个类似 myserviceaccount 的新的 service account，那么将会自动创建一个新的角色绑定：
$ kubectl create sa myserviceaccount
serviceaccount/myserviceaccount created
$ kubectl get rolebinding
NAME AGE
default-default-default-restricted-clusterrole-binding 13m
default-myserviceaccount-default-restricted-clusterrole-binding 4s借助这种神奇的功能，你无需为不需要任何提升特权的安全 pod 配置 RBAC。
在 Rancher 中创建你的 PSP
PSP 是一个标准的 Kubernetes 资源，全程是 Pod 安全策略，所以你可以通过 Kubernetes API 或 kubectl CLI 来使用它。
你可以通过在 YAML 文件中定义它们来创建你的自定义 PSP，然后使用 kubectl 在集群中创建资源。查看官方文档即可了解所有可用控件（https://kubernetes.io/docs/concepts/policy/pod-security-policy/）。在 YAML 中定义了控件集之后，你可以运行：
$ kubectl create psp my-custom-psp以创建 PSP 资源。
使用 Rancher，你可以从 UI 中直接查看或添加新的策略：
PSP 十分强大，但也十分复杂
配置 Pod 安全策略是一个十分乏味的过程。你在 Kubernetes 集群中启用 PSP 之后，你想要部署的任意 Pod 都必须经由其中一个 PSP 允许。实施强大的安全策略可能十分耗时，而且为每个应用程序的每个 deployment 生成一个策略也是一种负担。如果你的策略十分宽松，那么不强制执行最小特权访问方法；然而，如果它存在很多限制，你可能会破坏你的应用程序，因为 Pod 无法在 Kubernetes 中成功运行。
能够以最少的访问要求集自动生成 Pod 安全策略，将帮助你更轻松地安装 PSP。并且你不能只在生产环境中部署它们，而不验证你的应用程序是否可以正常工作，而且进行手动测试既繁琐又效率低下。如果你可以针对 Kubernetes 工作负载的运行时行为验证 PSP 呢？
如何简化生产环境中 PSP 的使用？
Kubernetes Pod 安全策略 Advisor（又名 kube-psp-advisor）是一个 Sysdig 的开源工具。kube-psp-advisor 会从 Kubernetes 资源（如 deployment、daemonset、replicaset 等）中扫描现有的安全上下文，将其作为我们想要执行的 reference 模型，然后在整个集群中为所有资源自动生成 Pod 安全策略。kube-psp-advisor 通过查看不同的属性以创建推荐的 Pod 安全策略：
allowPrivilegeEscalation
allowedCapabilities
allowedHostPaths
hostIPC
hostNetwork
hostPID
Privileged
readOnlyRootFilesystem
runAsUser
Volume
查看 kube-psp-advisor 教程，以获取有关其工作原理的更多详细信息：
https://sysdig.com/blog/enable-kubernetes-pod-security-policy/
使用 Sysdig Secure 自动生成 PSP
Sysdig Secure Kubernetes Policy Advisor 可以帮助用户创建和验证 Pod 安全策略。
第一步是设置新的 PSP 模拟环境。你可以针对不同范围内的不同策略（例如 Kubernetes 命名空间）进行多种模拟。
Sysdig 在你的 Deployment 定义中分析 Pod 规范的要求，并为你的应用程序创建权限最小的 PSP。这可以控制是否允许特权 Pod，用户将其作为容器、volume 等运行。Ni 可以微调 PSP 并针对你将要运行的模拟环境定义命名空间：
左侧的策略会破坏应用程序，因为 nginx Deployment 是特权 Pod，并且具有主机网络访问权限。你必须决定是扩大 PSP 以允许这种行为，还是选择减少 Deployment 的特权以适应该策略。无论如何，你在应用 PSP 之前都会检测到此情况，这会阻止 Pod 运行并在应用程序部署上造成破坏。通过授予或拒绝对特定资源的访问，PSP 使你可以对在 Kubernetes 中运行的 Pod 和容器进行精细控制。这些策略相对来说容易创建和部署，并且应该是任何 Kubernetes 安全策略的有用组件。
关于如何简化生产中的 Pod 安全策略问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注丸趣 TV 行业资讯频道了解更多相关知识。
