实例演示：如何简化生产中的Pod安全策略？

在实践教程“用Pod安全策略加强K8S安全性”中，我们演示了如何使用受限PSP策略作为默认策略在Rancher中启用PSP。我们还展示了如何防止特权Pod被允许进入集群。

我们有意省略了关于基于角色的访问控制(RBAC)以及如何将Pod连接到特定PSP的具体细节。因此，本文让我们继续深入研究PSP。

将容器与容器安全策略匹配

您可能已经注意到，PSP模式与任何Kubernetes名称空、服务帐户或Pod都没有关联。事实上，PSP是一个集群范围的资源。那么，我们如何指定哪个Pod应该由哪个PSP来管理呢？下图显示了所有参与组件、资源和准入流程的工作方式。

也许一开始听起来很复杂。现在，让我们详细介绍一下。

部署Pod时，准入控制将根据请求部署的对象应用策略。

Pod本身没有任何关联的策略-服务帐户正在执行部署。在上图中，Jorge使用webapp-sa服务帐户部署了pod。

角色绑定将服务帐户与角色(或集群角色)相关联，角色是指定可以使用PSP的资源。在此图中，webapp-sa与webapp-role相关联，后者为特定的PSP资源提供使用许可证。当Pod部署后，将根据webapp-sapp进行检查。事实上，一个服务帐户可以使用多个PSP，其中一个可以验证Pod就足够了。您可以在官方文件中查看详细信息:

https://kubernetes . io/docs/concepts/policy/pod-security-policy/# policy-order

然后，接纳控制将确定Pod是否满足任何PSP。如果吊舱满足要求，接纳控制将安排吊舱；如果吊舱不符合规定，部署将被阻止。

以上内容可归纳如下:

Pod身份由其服务帐户决定。如果规范中没有声明服务帐户，将使用默认帐户。您需要允许使用声明的角色或集群角色。最后，您需要一个角色绑定，将角色(从而允许访问PSP)与Pod规范中声明的serviceaccount相关联。

让我们用一些例子来说明。

RBAC的真实例子

假设您已经有一个支持PSP的集群，这是使用PSP创建受限PSP的一种常见方法，任何Pod都可以使用。然后，您将添加一个更具体的PSP，该PSP具有绑定到特定服务帐户的其他特权。拥有默认的、安全的和严格的策略有助于集群管理，因为大多数Pod不需要特殊的特权或功能，并且可以默认运行。然后，如果您的一些工作负载需要其他权限，我们可以创建一个自定义的PSP，并将工作负载的特定服务帐户绑定到一个限制较少的PSP。

但是，如何将Pod绑定到特定的PSP，而不是默认的受限PSP？如何使用不自动添加角色绑定的普通库本内特集群来实现这一点？

让我们看一个完整的示例，其中我们定义了一些安全默认值(集群中的任何服务帐户都可以使用的受限PSP)，然后为需要该服务的特定部署向单个服务帐户提供额外的权限。

首先，我们手动创建一个新名称空。它不会由Rancher管理，因此不会自动创建角色绑定。然后，我们尝试在名称空之间部署一个有限的Pod:

资源名称:-restricted-PSP-APiVersion:rbac.authorization.k8s.io/ v1种类:ClusterRoleBinding元数据:name:restricted-role-bind RoleRef:APiGroup:RBAC . authorization . k8s . io种类:ClusterRole name:use-restricted-PS p subjects:-APiGroup:RBAC . authorization . k8s . io种类:Group name:system:service accounts $ ku pectl apply-f cluster role-use-restricted . YAML

无法创建Pod，因为psp-test中没有名称空之间的角色绑定，并且名称空绑定到允许使用任何psp的角色。我们将通过创建集群范围的集群角色和集群角色绑定来解决这个问题，以允许任何服务帐户默认使用有限的PSP。当PSP在以前的文章中被启用时，Rancher创建了一个受限的PSP。

资源名称:-restricted-PSP-APiVersion:rbac.authorization.k8s.io/ v1种类:ClusterRoleBinding元数据:name:restricted-role-bind RoleRef:APiGroup:RBAC . authorization . k8s . io种类:ClusterRole name:use-restricted-PS p subjects:-APiGroup:RBAC . authorization . k8s . io种类:Group name:system:service accounts $ ku pectl apply-f cluster role-use-restricted . YAML

应用这些更改后，非特权部署应该可以正常工作。

但是，如果我们需要部署特权Pod，现有策略将不允许这样做:

$ cat deploy-privileged . YAML ApiVersion:v1种类:ServiceAccount元数据:name: privileged-sa命名空间:psp-test - apiVersion: apps/ v1种类:部署元数据:labels: app: privileged-deploy命名空间:psp-test spec: replicas: 1选择器:Matchlabels:app:privileged-deploy模板:metadata:Labels:app:privileged-deploy spec:containers:-image:alpine Name:alpine stdin:true tty:true security context:privileged:true HostPiD:true HostNetwork:true Serv...事件:类型原因年龄来自消息-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

牧场主将在集群中创建一对PSP资源:

受限psp:如果您选择“受限”作为默认pspdefault-psp:默认PSP，它被允许创建一个特权Pod。

除了受限psp和默认psp之外，Rancher还创建了一个名为受限集群角色的集群角色:

注释:serviceaccount.cluster.cattle.io/pod-security:受限创建时间戳:“”2020-010T08:44:39Z”标签:cattle.io/创建者:normanname:restricted-ClusterRole规则:-API groups:-extendedresourcenames:-restricted-PS resources:-podcsecurity policies verds:-use此Clusterrole允许使用受限-psp策略。那么在哪里可以允许绑定授权使用pod服务帐户呢？

对于属于Rancher名称空的项目，它还会为您设置角色绑定配置:

$ ku bectl-n default get role binding default-default-restricted-clusterrole-binding-o YAML APiVersion:rbac.authorization.k8s.io/ v1 kind:RoleBinding元数据: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-restricted-clusterrole-binding namespace:default...RoleRef:ApiGrouP:RBAC . authorization . k8s . io kind:Clusterrole name:restricted-Clusterrole subjects:-kind:service account name:default namespace:default resource name(default-default-default-restricted-Clusterrole-binding)可能会引起混淆，但它实际上包含:

default-service account name-namespace-restricted-cluster role-binding

如果您创建一个类似于myserviceaccount的新服务帐户，将自动创建一个新的角色绑定:

$ ku pectl create sa my service account service account/my service account created $ ku pectl get role binding NAME AGE-default-default-default-re Strected-cluster role-binding 13 default-my service account-default-restricted-cluster role-binding 4有了这个神奇的功能，您不需要为不需要任何提升权限的安全pod配置RBAC。

在牧场主创建你的PSP

PSP是一个标准的库本内特资源，并且始终是一个Pod安全策略，因此您可以通过库本内特API或库本特尔CLI使用它。

您可以通过在YAML文件中定义它们来创建您自己的自定义PSP，然后使用kubectl在集群中创建资源。检查所有可用控件的正式文档(https://kubernetes . io/docs/concepts/policy/pod-security-policy/)。在YAML定义控制集后，您可以运行:

$ kubectl创建一个自定义psp来创建PSP资源。

牧场主允许您直接从用户界面查看或添加新策略:

PSP非常强大，但也非常复杂。

配置Pod安全策略是一个乏味的过程。在Kubernetes集群中启用PSP后，您要部署的任何Pod都必须得到其中一个PSP的允许。实现强大的安全策略可能很耗时，为每个应用程序的每个部署创建一个策略也是一个负担。如果您的策略非常宽松，那么不要强制实施最低特权访问方法；但是，如果它有很多限制，您可能会破坏您的应用程序，因为Pod无法在Kubernetes中成功运行。

自动生成具有最低访问要求的Pod安全策略的能力将帮助您更轻松地安装PSP。而且，您不能只在生产环境中部署它们，而不验证您的应用程序是否正常工作，手动测试既乏味又低效。如果您可以根据库伯内特工作负载的运行时行为来验证PSP呢？

如何在生产环境中简化PSP的使用？

Kubernetes Pod安全策略顾问(也称为kube-psp-advisor)是Sysdig的开源工具。Kube-psp-advisor从Kubernetes资源(如部署、daemonset、replicaset等)中扫描现有的安全上下文。)作为我们要执行的参考模型，然后自动为整个集群中的所有资源生成Pod安全策略。Kube-psp-advisor通过查看不同的属性来创建推荐的Pod安全策略:

allowprivilegeProgrationAllowedCapabilitiesAllowedHostPathShostipchostNetworkHostPidPrivilegedReadonlRootfilesystemRunasserverLume

查看kube-psp-advisor教程，了解其工作原理的更多详情:

https://sysdig . com/blog/enable-kubernetes-pod-security-policy/

使用安全系统自动生成PSP

sydigsecure kubernetes policy advisor帮助用户创建和验证Pod安全策略。

第一步是建立一个新的PSP仿真环境。您可以在不同的范围内对不同的策略执行各种模拟(例如，Kubernetes命名空)。

Sysdig在您的部署定义中分析Pod规范的要求，并为您的应用程序创建具有最低权限的PSP。这可以控制是否允许特权Pod，并且用户将其作为容器、卷等运行。倪可以微调PSP，并为您将要运行的模拟环境定义名称空:

左边的策略会破坏应用程序，因为nginx部署是一个特权Pod，可以访问主机网络。您必须决定是扩展PSP以允许这种行为，还是选择降低部署权限以适应策略。在任何情况下，您将在应用PSP之前检测到这种情况，这将阻止Pod运行并对应用程序部署造成损害。

结论

如这些例子所示，PSP通过授予或拒绝对特定资源的访问，使您能够很好地控制在库本内特斯运行的容器和容器。这些策略相对容易创建和部署，应该是任何Kubernetes安全策略的有用组成部分。

本文由 在线网速测试 整理编辑，转载请注明出处，原文链接：https://www.wangsu123.cn/news/3491.html。