覆盖 scc 中的参数 (SecurityContextConstraints)答案

【问题标题】：Overwrite parameters in scc ( SecurityContextConstraints )覆盖 scc 中的参数 (SecurityContextConstraints)
【发布时间】：2022-01-12 08:52:56
【问题描述】：

我想在我的 openshift v4.6 上启用 seccomp 以使用 RuntimeDefault

  securityContext:
    seccompProfile:
      type: RuntimeDefault

当我运行下面的命令时，我可以看到我已将 allowPrivilegeEscalation 设置为 true

$ oc get scc restricted 

allowPrivilegeEscalation: true
allowPrivilegeContainer: false

在我的部署 yaml 文件中，我尝试将参数定义为 false 安全上下文： allowPrivilegeEscalation: false

但这并没有改变任何东西

我是否必须定义一个自定义 SecurityContextConstraints 来覆盖参数？

【问题讨论】：

也无法理解您的问题：您是否期望受限 scc 中的 allowPrivilegeEscalation 发生更改，因为您在部署中将 allowPrivilegeEscalation 设置为 false？

标签： kubernetes google-cloud-platform openshift kubernetes-pod

【解决方案1】：

我不太明白你的问题。

关于编辑 SCC 或创建新 SCC，请参阅：https://docs.openshift.com/container-platform/4.9/authentication/managing-security-context-constraints.html

是的，您应该始终使用您想要的更改定义一个新的 SCC。强烈警告不要在 OpenShift 中编辑任何默认 SCC。

SCC 控制可以允许进入集群的内容。如果您可用的 SCC 定义了“allowPrivilegeEscalation: true”，那么您可以创建 pod，并将其设置为 true 或 false。如果设置为“false”，那么您只能创建设置为 false 的 pod。

在您的部署配置中，您可以在 podSpec 或 containerSpec 上设置 securityContext。你用的是哪一个？我记得在我的测试中它们之间有不同的行为，但我不记得手头的细节。 tldr - 如果您正在使用一个，请尝试另一个。

更重要的是，您如何确定某事是否发生了变化？同样，在我的测试中，我“oc debug node/ ...”并查看了 crictl inspect 以观察该 securityContext 被更改的效果。

【讨论】：