产业气象站@实例演示:如何简化生产中的Pod安全策略?( 二 )


resourceNames:-restricted-psp---apiVersion:rbac.authorization.k8s.io/v1kind:ClusterRoleBindingmetadata:name:restricted-role-bindroleRef:apiGroup:rbac.authorization.k8s.iokind:ClusterRolename:use-restricted-pspsubjects:-apiGroup:rbac.authorization.k8s.iokind:Groupname:system:serviceaccounts$kubectlapply-fclusterrole-use-restricted.yaml我们应用这些更改之后 , 非特权deployment应正常工作 。
但是 , 如果我们需要部署特权Pod , 则不会被现有策略允许:
在这种情况下 , 由于我们创建了ClusterRoleBinding , 所以Pod可以使用PSP , 但是restricted-psp不会验证Pod , 因为它需要privileged、hostNetwork等参数 。
我们已经在前文中看到了restricted-psp策略 。 让我们检查一下default-psp的细节 , 这是由Rancher在启用PSP允许这些特权时创建的:
你可以看到这是一个非常宽松的策略 , 特别是我们允许privileged、hostNetwork、hostPID、hostIPC、hostPorts以及以root身份运行以及其他功能 。
我们只需要明确允许该Pod使用PSP 。 我们通过创建类似于现有restricted-clusterrole的ClusterRole , 但允许使用default-psp资源 , 然后为我们的psp-test命名空间创建RoleBinding来将privileged-saServiceAccount绑定到该ClusterRole:
一会儿之后 , 特权Pod将会被创建 。 然后你会注意到restricted-psp和default-psp现在已经可以直接使用 。 接下来 , 我们来详细介绍一下它们 。
在Rancher上默认的PSP
在Rancher中通过编辑集群设置来启用PSP准入控制 , 并选择其中一个已经定义好的PSP作为默认选项:
产业气象站@实例演示:如何简化生产中的Pod安全策略?
文章图片
Rancher将在集群中创建一对PSP资源:
restricted-psp:如果你选择“受限(restricted)”作为默认的PSPdefault-psp:默认的PSP , 允许创建特权Pod 。除了restricted-psp和default-psp , Rancher还会创建名为restricted-clusterrole的ClusterRole:


推荐阅读