准入控制器代码正在审查中： https ://github.com/kubernetes/kubernetes/pull/24600

此功能直接跳至 ​​Beta，因为它已在 OpenShift 中首次公开。

它将在 kubernetes/kubernetes#24600 中默认禁用。 之后，我们需要更改准入控制器以将 PSP 链接到用户。

注意到https://github.com/kubernetes/kubernetes/pull/20573作为 PSP 下一步的依赖项（主题级别访问）

这是什么状态？ 第一条评论中的描述是最新的吗？

第一条评论中的描述是最新的吗

否（我无权更新）。 我相信所有的 alpha 要求都已经得到满足。 初始类型、api 和测试已合并。 默认情况下不启用准入控制器。

IMO Beta/1.4 的剩余工作是权限的身份验证集成，更新我们想要约束的新字段（seccomp - 进行中，sysctl）以及任何所需的文档/教程。

以及 e2e 测试。

2016 年 7 月 12 日星期二上午 6:23，Paul Weil [email protected]写道：

第一条评论中的描述是最新的吗

否（我无权更新）。 我相信所有的阿尔法
已满足要求。 初始类型、api 和测试已经
合并。 默认情况下不启用准入控制器。

IMO beta/1.4 的剩余工作是权限的身份验证集成，
更新我们想要约束的新字段（seccomp - 进行中，
sysctl)，以及任何所需的文档/教程。

—
您收到此消息是因为您编写了该主题。
直接回复此邮件，在 GitHub 上查看
https://github.com/kubernetes/features/issues/5#issuecomment -232045429，
或使线程静音
https://github.com/notifications/unsubscribe/AHuudqFwephlYk0Y1PS77y0xxA5QW0_-ks5qU5U7gaJpZM4IaU8n
.

与云提供商的互动如何？ 轻松地为每个 pod 分配不同的 IAM 角色会很好，这样他们就可以只访问他们实际需要的云服务子集。 它会在范围内还是被视为 SecurityContext 详细信息？

@therc应该通过 ServiceAccount 完成。

@goltermann我注意到这标有 alpha 但我相信它可能需要基于https://github.com/kubernetes/features/issues/5#issuecomment -217939650 的 beta 标签

@erictune根据@pweil- 评论，beta 听起来是否正确？

@goltermann我认为从技术上讲这将是 1.3 中的测试版，尽管开发正在进行中，但它对 1.4 来说并不新鲜。

是的，测试版是正确的。 我今天早些时候说阿尔法时是不正确的。

太好了，修好了

@pweil- 文档准备好了吗？ 请将文档更新到https://github.com/kubernetes/kubernetes.github.io ，然后添加 PR 编号并在问题描述中选中文档框

@janetkuo文档公关https://github.com/kubernetes/kubernetes.github.io/pull/1150

编辑： https ://github.com/kubernetes/kubernetes.github.io/pull/1206 是正确的 1.4 PR

抄送@kubernetes/feature-reviewers

@pweil- 我想，这个 PR 是真实的 - https://github.com/kubernetes/kubernetes.github.io/pull/1206？

正确的

问题在 90 天不活动后变得陈旧。
使用/remove-lifecycle stale将问题标记为新问题。
陈旧的问题在额外的 30 天不活动后腐烂并最终关闭。

使用/lifecycle frozen注释防止问题自动关闭。

如果这个问题现在可以安全关闭，请使用/close来关闭。

向 sig-testing、kubernetes/test-infra 和/或@fejta发送反馈。
/生命周期陈旧

1.10 中正在进行将 PSP 移至其非扩展 API 组的工作
抄送@php-coder

@erictune文档更新好吗？ 另请参阅 [1.10 功能跟踪电子表格 [(https://docs.google.com/spreadsheets/d/17bZrKTk8dOx5nomLrD1-93uBfajK5JS-v1o-nCLJmzE/edit#gid=0)。 lmk 如果你有任何问题。 我们需要在 3/9 之前审查和合并文档 PR。 谢谢！

@php 编码器 ^

@Bradamant3 @liggitt需要哪些文档更新？

关于 API 组转换相关的更改，我已经提交了： https ://github.com/kubernetes/website/pull/7562 、 https://github.com/kubernetes/examples/pull/206和https:// /github.com/kubernetes/examples/pull/208

我不是 PSP Doc 更新的正确所有者。

2018 年 3 月 2 日星期五上午 11:26，Vyacheslav Semushin <
通知@github.com> 写道：

@Bradamant3 https://github.com/bradamant3 @liggitt
https://github.com/liggitt需要哪些文档更新？

对于与 API 组转换相关的更改，我已提交：
kubernetes/website#7562 https://github.com/kubernetes/website/pull/7562 ,
kubernetes/examples#206 https://github.com/kubernetes/examples/pull/206 ,
和 kubernetes/examples#208
https://github.com/kubernetes/examples/pull/208

—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看
https://github.com/kubernetes/features/issues/5#issuecomment-370026485 ,
或使线程静音
https://github.com/notifications/unsubscribe-auth/AHuudtBCup17Kt91pqJzBRpKWStoXUt-ks5taZzcgaJpZM4IaU8n
.

这就是我们所需要的。 我已将 PR 添加到跟踪电子表格中。 谢谢！

@php-coder @liggitt @tallclair
1.11 有这方面的计划吗？

如果是这样，您能否确保该功能是最新的，并具有相应的：

• 描述
• 里程碑
• 受让人
• 标签：
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

抄送@idvoretskyi

@php-coder 你能用你在这里所做的工作来回应@justaugustus的评论吗？ 除了政策组移动之外，还有其他变化吗？

除了政策组移动之外，还有其他变化吗？

不，我只在这方面工作。

我希望@liggitt有时间会更新描述（因为我没有适当的权限）。

完毕。

@tallclair澄清一下，我们正在跟踪稳定作为 1.11 的目标，对吗？
我已经更新了标签，只是想确定一下。

不，这仍将是测试版。 我不确定 PodSecurityPolicy 是否会稳定（即会被其他东西取代），但其他人可能不同意我的观点。

知道了。 感谢您的更新，@tallclair！

@justaugustus我将从 1.11 里程碑中删除它，因为在当前版本中不会发生重大进展。

1.12 没有计划更新

@tallclair我也许可以在 1.12 中获得 RunAsGroup PSP 旋钮

确认。 不过，这仍将处于测试阶段。 目前，PSP 没有进入 GA 的计划。 在我们取得进展之前，有一些主要的可用性问题需要解决。 （见 https://github.com/kubernetes/kubernetes/issues/60001 和 https://github.com/kubernetes/kubernetes/issues/56174）

/取消分配

/分配@tallclair

你好
之前已跟踪此增强功能，因此我们想检查一下是否有任何计划在 Kubernetes 1.13 中毕业。 此版本的目标是更加“稳定”，并将有一个积极的时间表。 请仅在高度确信它将满足以下截止日期时才包含此增强功能：

• 文档（开放占位符 PR）：11/8
• 代码泥浆：11/9
• 代码冻结开始：11/15
• 文件完成和审查：11/27

请花点时间更新您原始帖子中的里程碑以供将来跟踪和 ping @kacole2如果它需要包含在1.13 增强跟踪表中

谢谢！

1.13 中没有计划更改。

问题在 90 天不活动后变得陈旧。
使用/remove-lifecycle stale将问题标记为新问题。
陈旧的问题在额外的 30 天不活动后腐烂并最终关闭。

如果这个问题现在可以安全关闭，请使用/close来关闭。

向 sig-testing、kubernetes/test-infra 和/或fejta发送反馈。
/生命周期陈旧

/删除-生命周期陈旧

@tallclair您好 - 我是 1.14 增强版的负责人，我正在检查这个问题，以查看 1.14 版本计划进行哪些工作（如果有）。 增强功能冻结是 1 月 29 日，我想提醒所有增强功能都必须有一个 KEP

1.14 没有任何计划。

这成为 GA 的差距是什么？ 我可以考虑几个，但我在描述中看不到任何标准。

在这可以进入 GA 之前，我们需要解决这些问题：

1. 有缺陷的授权模型- PSP 的使用是通过 RBAC 授予的，可以授予用户，也可以授予创建的 pod。 将其授予用户是一种直观的方法，但存在问题（参见解释）。 这种方法也存在一些安全问题。
2. 难以推出- 因为 pod 默认被拒绝，我们无法在不破坏它们的情况下将 PSP 推出到所有集群。 同样，想要启用 PSP 的用户需要确保完全覆盖所有工作负载才能打开它，这使得它难以启用（因此使用率相对较低）。 因为必须显式启用该功能，所以我们没有足够的测试覆盖率（功能矩阵太复杂）。
3. 不一致的 API - 不是一个基本问题，但 PSP API 在 k8s 版本中的长期演变导致了许多不一致，使其难以使用。 特别是，突变与验证混为一谈，当一个 pod 可以访问多个 PSP 时，这可能会导致一些意想不到的结果。

@liggitt和我对如何解决这个问题有一些想法，但是关于这是否属于核心 Kubernetes 有一个悬而未决的问题。 我想在下个月制定路线图，要么是去 GA 的计划，要么是弃用计划。

感谢您分享的信息！

因为 Pod 默认会被拒绝，所以我们无法在不破坏所有集群的情况下将 PSP 部署到所有集群。

我想这不是真的。我们通过创建一个足够开放（甚至全部开放）的 PodSecurityPolicy 来做到这一点，然后逐渐完善它。

@ zhouhaibing089 Kubrenetes 用户可以使用有效的方法，因为他们控制策略。 但是，我们不能将其作为 Kubernetes 默认推出，因为 PodSecurityPolicy 仅打开集群，这意味着管理系统控制的允许所有 PSP 非常困难。

你好@liggitt @tallclair ，我是 1.15 的增强负责人。 此功能是否会在 1.15 中逐步结束 alpha/beta/stable 阶段？ 请让我知道，以便可以正确跟踪它并将其添加到电子表格中。 社区提案需要迁移到 KEP 以包含在 1.15 中。

编码开始后，请在此问题中列出所有相关的 k/k PR，以便正确跟踪它们。

1.15 没有计划更改

@tallclair真的很想在 1.16 中看到这片土地作为 GA。 那可能吗？

@lachie83不，我们不确定是否希望 PodSecurityPolicy 进入 GA。 目前尚不清楚这是一个应该由 Kubernetes 核心解决的用例，我们正在研究核心外的替代方案。 如果您想更详细地讨论它，这是 SIG-Auth 的好话题。

@tallclair像Open Policy Agent 的看门人这样的东西会是一个更好的方法吗？

对，就是这样。 那可能是领先的竞争者，我正在与该团队密切合作，以确保它能够涵盖这些用例。

我一直在等待的一件事是一种可以翻译PodSecurityPolicy --> OPA rego 政策的工具。 从您的角度来看，这将使弃用它们变得容易得多。

@tallclair感谢您的及时回复

@SEJeff同意。 在明确替换功能奇偶校验和迁移路径之前，我们不会弃用 PodSecurityPolicy。

嘿@tallclair ，您提到了 GA 路线图或弃用计划。 似乎我们倾向于后者。

我们是否写了一些东西来帮助那些将 PSP 视为解决方案的人关闭循环？

还没有。 部分犹豫是我们不想说我们会弃用它而支持其他东西，直到有一个明确的替代品。 尽管我对 Gatekeeper 感到兴奋，但它还没有我们需要替换 PSP 的功能（或稳定性）。 另一种可能性是我们可以将 PSP 从树中移出，并将其作为准入 webhook 带到 GA（这两个选项并不相互排斥）。 不过，我们还没有正式制定路线图。

重量级

嗨@tallclair看起来 1.16 也没有发生任何事情，所以我会保持不变。

嘿， @tallclair——这里是 1.17 增强领先——看起来这在 1.17 中保持不变。 如果情况发生变化，请不要犹豫，戳我，我可以将其添加到跟踪表中 👍

是否有更多关于 PSP 未来明确路径的讨论？

对，就是这样。 那可能是领先的竞争者，我正在与该团队密切合作，以确保它能够涵盖这些用例。

@tallclair - 我们已经在 Kyverno 实施了大多数 PSP 检查。 你能帮忙看看吗？ 很想讨论想法和细节。

https://github.com/nirmata/kyverno/blob/master/samples/README.md

Gatekeeper 项目也一直在研究 PSP 后的世界会是什么样子。 我们最初的方法是将 PSP 资源分解为单独的约束。 我们想知道社区对这种方法的看法。 也许现在是重新想象这些政策如何构成的好时机？ 新用户和现有 PSP 用户的迁移也很重要。

抄送@maxsmythe @sozercan @tsandall

我对将策略分解为单独的约束有些担心，即我需要创建更多的约束对象。 如果我认为需要针对不同的工作负载克隆或更改它们，我担心它会变得非常复杂。

我认为最好的方法是以用户为中心的方法。 如果我们能得到关于 PSP 使用方式的真实反馈，然后看看在这些替代插件下类似的设置会是什么样子，那么这将有助于塑造设计。

@tallclair我们追求的用例之一与基于命名空间的多租户有关。 目的是使用策略来实施限制并确保正确配置命名空间。

在这可以进入 GA 之前，我们需要解决这些问题：

1. 有缺陷的授权模型- PSP 的使用是通过 RBAC 授予的，可以授予用户，也可以授予创建的 pod。 将其授予用户是一种直观的方法，但存在问题（参见解释）。 这种方法也存在一些安全问题。

@tallclair ，我想知道上述问题-您能否详细说明这种方法存在问题和/或存在安全问题？

有人可以了解更多信息，请确认此推文：

https://twitter.com/TechJournalist/status/1197658440040165377

如果这是真的，那么今天使用 PSP 来限制 linux 功能的人们应该怎么做呢？

大家好，
这是一个非常有趣的讨论，我们目前正在寻找在 Kubernetes 集群中保护 Pod 创建的解决方案。

我们查看了 OPA Gatekeeper 和 PodSecurityPolicies，以及在 OPA 约束中重新实现 PSP 的努力。
我们通过这种比较发现的基本问题是我们正在处理两个相反的模型。

• OPA Gatekeeper 遵循默认开放模型，在该模型中，一切都被允许，管理员禁止某些有约束的事情。
• PSP 遵循默认关闭的模型，在该模型中，一切都被禁止，管理员允许某些事情与策略。

从安全的角度来看，我认为 PSP 模型更好，尽管由于所有工作负载都必须符合它，因此更难将其引入现有集群。

您打算如何在 PSP 和约束框架之间弥合这种架构上的根本差距？

/cc @ritazh我很想听听您对此的看法，因为您一直致力于将 PSP 功能移植到 OPA。

不同的方法肯定会使迁移更加复杂。 我们正在探索使过渡更加顺畅的不同方法。

在一个完美的世界里，我同意默认拒绝所有是更安全的方法。 然而，这是使 PSP 难以使用和推出的原因之一。 在实践中，我认为逐步降低权限更可行，正如老话所说“最好的安全是你使用的安全”。

附带说明一下，我们还在讨论如何选择退出/排除/获取约束例外（例如保护 kube-system 命名空间）。 根据其工作原理，您可以通过锁定所有内容然后授予例外来实现默认拒绝方法。 我不确定这是否是我们想要设计的用例......

@tallclair您希望在 1.18 中在这方面取得任何进展吗？ 我是该版本的增强影子，想知道我们是否应该对此进行跟踪。

1.18 没有计划更改

问题在 90 天不活动后变得陈旧。
使用/remove-lifecycle stale将问题标记为新问题。
陈旧的问题在额外的 30 天不活动后腐烂并最终关闭。

如果这个问题现在可以安全关闭，请使用/close来关闭。

向 sig-testing、kubernetes/test-infra 和/或fejta发送反馈。
/生命周期陈旧

/删除-生命周期陈旧

@tallclair嗨，蒂姆。 1.19 有这方面的计划吗？

没有 v1.19 的计划，尽管我希望在 v1.20 时间范围内看到一些变化。

刚刚偶然发现带有 Open Policy Agent 的 Kubernetes Pod 安全策略。 @tallclair你能分享是什么阻碍了我们以及需要帮助的地方，也很乐意做出贡献。

你能分享是什么阻碍了我们

基本上我们只需要对前进的道路做出决定。 目前，我认为 PSP 不应该以目前的形式进入 GA 是一致的，但我们还没有确定替代品。 我们讨论过的选项：

1. 不可替代 - 建议从带有准入 webhook 的第三方选项中进行选择。 最近发布的Pod 安全标准文档试图通过推广等效功能来使这一过程更加顺畅。
2. 替代内置控件
   
   
   
   1. @deads2k已提议上游化 openshifts SecurityContextConstraints
   
   
   2. 我提出了一个最低限度的可配置特性，它只强制执行上面链接的标准策略（并在需要更多可配置性时推荐第三方解决方案）
   
   
3. 修复 pod 安全策略 - 尽管某些问题对于设计来说已经足够核心，但它需要是非向后兼容的，此时它也可能是 (2) 中的新替代方案

我是否正确阅读了https://github.com/kubernetes/kubernetes/pull/90603 ，因为 pod 安全标准已发布，因此没有计划替换 API 服务器中的 PSP，并且任何替换都需要作为外部系统实施？

见https://github.com/kubernetes/enhancements/issues/5#issuecomment -637066475

1.22 中当前 beta 版本的弃用时间表与是否提供标准 pod 安全配置文件的树内实现无关。 那还没有确定。

谢谢@liggitt确认没有设置任何内容。 最初认为在有替代品可用之前不会弃用任何东西。 不清楚是否以某种方式做出了决定。

弃用时间表并非特定于 PSP，而是作为https://github.com/kubernetes/enhancements/tree/master/keps/sig-architecture/1635-prevent-permabeta的一部分添加的

如果我没看错的话，那么推动弃用的原因是没有任何 API 应该在同一个 beta 版本中超过 9 个月，所以 PSP 需要得到提升或弃用，因为不会有任何新的 beta 或 GA 的 psp即使尚未决定更换它，它也需要走上弃用的轨道吗？

如果我没看错，那么推动弃用的是任何 API 都不应该在同一个 beta 版本中超过 9 个月

确切地。 所有内置 API 的所有未来 beta 版本在首次引入时都将附带一个预烘焙的弃用和删除目标

嗨@tallclair

增强功能导致这里。 1.20 有这方面的计划吗？

谢谢，
克尔斯滕

没有 v1.20 的计划。

对于我们这些需要运行高安全性集群的人来说，这种情况非常令人沮丧。 我们的选择是：

1. 坐等 PSP 被弃用。
2. 将工作负载运行时安全实施外包给供应商 (Styra)，因为 OPA 没有记录如何使用 Rego 运行完全限制性的 PSP 替换。

所以，我的公司已经实施了完全锁定的 PSP。 它们不容易实现，调试它们是一件苦差事，但它们功能强大，而且确实有效。 我们甚至发布了一篇博文，详细介绍了如何以这种方式使用它们，以及如何在异常发生时处理它们。

IMO，PSP beta 应该按原样合并到主线 kubernetes 核心中。 我的理由是：

1. 虽然 PSP 有缺陷，但它们可以运行，并且已经运行了 10 个版本。
2. Kubernetes 作为一个项目应该关心工作负载运行时的安全性。 容器逃逸太容易了。 PSP 是为数不多的使攻击者更难做到这一点的工具之一。
3. 完美是完成的敌人。 按原样合并 PSP，并将“更好”的实现推向 policy/v2。
4. 最后，也是最重要的一点，它允许 OSS 开发人员运行更高安全性的集群，而不仅仅是能够负担得起 Styra 等供应商的公司。

@zapman449你能澄清一下“完全限制性的 PSP 替换”是什么意思吗？

希望Gatekeeper PSP 库可以更轻松地执行类似于 PSP 使用的规则。 我绝对对您看到的任何功能差距感兴趣。

@zapman449你会碰巧有那个博文的链接吗？

@christianhuening https://developer.squareup.com/blog/kubernetes-pod-security-policies

@maxsmythe我还没有了解 Gatekeeper PSP 正在做什么，将进行审查。

然而，我的意思是：

1. 完全控制 NET_BIND_SERVICE、SYS_ADMIN 等流程功能
2. 将 UID/GID/FSGroups 限制为非零值
3. 可以挂载的主机路径的显式列表
4. 明确列出允许的卷安装类型
5. Block Privileged，块权限提升
6. 阻止对主机级进程间通信原语的访问
7. 阻止访问主机网络
8. 限制允许哪些主机端口
9. 强制 readOnlyRootFilesystem
10. SELinux 的连接点

这些是今天与 PSP 一起提供的。

如果我们要一份愿望清单，我希望：

1. 来自容器的 SysCall 的智能默认值。 大多数容器需要的总 linux 系统调用列表中只有一小部分。 让我将大多数容器限制在该列表中，然后允许我明确允许对某些服务帐户拥有的某些 pod 进行某些调用，或者将全权委托给特定的服务帐户。
2. 让我多做点梦，我会想出点什么来的。 ;-)

@zapman449 - 如果您还没有看到，我们在上次 sig-auth 会议上讨论了 PSP 的未来 (https://docs.google.com/document/d/1woLGRoONE3EBVx-wTb4pvp4CI7tmLZ6lS26VTbosLKM/view#heading=h.hsgtsqg83z5u )。 如果您能够做到，我们将在 12 月 9 日的会议上继续讨论，但如果没有将提案发送到邮件列表，我们也不会做出任何最终决定。

我们在这里的意图绝对不是让任何人高高在上。 我们知道 PSP 解决了 Kubernetes 的重要安全需求，这些讨论的目的是找出未来满足这些需求的最佳方式是什么。