kubernetes Pod Security Admission拒绝丢弃所有非大写字母的权限 ```markdown Pod Security Admission拒绝丢弃所有非大写字母的权限 ```

j0pj023g  于 5个月前  发布在  Kubernetes
关注(0)|答案(9)|浏览(69)

看起来Pod控制器在丢弃能力时接受不同的ALL shell

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: foo
  name: foo
spec:
  containers:
  - image: ubuntu
    command: ["sleep","9999"]
    name: foo
    resources: {}
    securityContext:
      capabilities:
        drop:
          - all
root@foo:/# cat /proc/1/status | grep Cap
CapInh:	0000000000000000
CapPrm:	0000000000000000
CapEff:	0000000000000000
CapBnd:	0000000000000000
CapAmb:	0000000000000000

但是Pod安全准入控制器要求常量为ALL
kubernetes/staging/src/k8s.io/pod-security-admission/policy/check_capabilities_restricted.go
第30行 in a08ee80
| | capabilityAll="ALL" |
kubernetes/staging/src/k8s.io/pod-security-admission/policy/check_capabilities_restricted.go
第94行 in a08ee80
| | ifc==capabilityAll { |
考虑到有很多现有的K8s yaml可以在受限制的配置文件中运行,将准入控制器的比较设置为不区分大小写可能有意义。
/sig security

5jvtdoz2

5jvtdoz21#

这个问题目前正在等待分类。
如果SIG或子项目确定这是一个相关的问题,他们将通过应用triage/accepted标签并提供进一步的指导来接受它。
组织成员可以通过在评论中写入/triage accepted来添加triage/accepted标签。
有关使用PR评论与我互动的说明,请查看here。如果您对我的行为有任何问题或建议,请针对kubernetes/test-infra仓库提出一个问题。

9wbgstp7

9wbgstp73#

Kubernetes项目目前缺乏足够的贡献者来充分应对所有问题。
此机器人根据以下规则对未分类的问题进行分级处理:

  • lifecycle/stale应用后的90天不活动后,将应用lifecycle/stale
  • lifecycle/stale应用后的30天不活动后,将应用lifecycle/rotten
  • lifecycle/rotten应用后的30天不活动后,该问题将被关闭

您可以:

  • 将此问题标记为新鲜的/remove-lifecycle stale
  • 使用/close关闭此问题
  • 提供帮助,请使用Issue Triage

请将反馈发送至sig-contributor-experience@kubernetes/community
/lifecycle stale

0yycz8jy

0yycz8jy4#

Kubernetes项目目前缺乏足够的活跃贡献者来充分应对所有问题。
此机器人根据以下规则对未分类的问题进行分级处理:

  • lifecycle/stale应用后的90天内无活动,将应用lifecycle/stale
  • lifecycle/stale应用后的30天内无活动,将应用lifecycle/rotten
  • lifecycle/rotten应用后的30天内无活动,将关闭该问题

您可以:

  • 使用/remove-lifecycle rotten标记此问题为新鲜
  • 使用/close关闭此问题
  • 提供帮助,使用Issue Triage

请将反馈发送至sig-contributor-experience@kubernetes/community
/lifecycle rotten

zbwhf8kr

zbwhf8kr6#

根据与@tallclair的沟通,我的理解如下:

  • 在实践中,cri-o和containerd似乎对ALL关键字进行不区分大小写的匹配,但这并不保证对其他运行时也有效。
  • 在一个严格的CRI能力规范在SIG-Node中被采纳之前,PSS策略更倾向于坚持使用规范的ALL大小写形式。这样它们将与其他规范保持一致。
  • PSA实现不太可能在CRI能力规范没有相应更改的情况下发生变化。
ruoxqz4g

ruoxqz4g7#

为什么API不能接受所有ALL的情况,然后在与CRI通信时将其转换为大写?
我只是认为我们不需要在这里过于苛求,但可以进行一些轻微的更改,使其更具可扩展性和安全性。

u7up0aaq

u7up0aaq8#

这是一个有趣的想法,也许是一种在不改变CRI规范的情况下达到一致、合规状态的方法。
我认为任何更改确实需要从低级(如pod控制器)开始,并从那里逐渐传播开来。
一旦可以保证CRI会收到“所有”,那么准入控制器和其他验证测试就可以更加宽松。
目前的情况是,有一些验证测试正在接受那些(1)可能会被合规的准入控制器拒绝的资源,当它们应用于集群时,以及(2)尽管不太可能,但实际上可能不会在运行时完全删除所有资源。

rkkpypqq

rkkpypqq9#

为什么API不能接受所有情况的ALL,然后在与CRI通信时将其转换为大写?
允许像那样的混合大小写功能会给Pod安全标准的所有实现(有很多)带来更多的工作。
我们希望引入使用CEL的变异准入策略,允许您设置集群在准入时将值转换为大写。欢迎提供关于MutationAdmissionPolicy实现的帮助。

相关问题