k8s scc权限和内置的restricted、anyuid、privileged详解

 更新时间:2025年07月11日 08:50:06   作者:云川之下  
这篇文章主要介绍了k8s scc权限和内置的restricted、anyuid、privileged,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教

概述

在OpenShift(后文简称OCP)中,很早就一个概念:Security Context Constraints ,简称SCC,即安全上下文约束。

K8S的Pod安全策略和OCP中的SCC有一定继承(现有OCP的SCC后有K8S的pod安全策略)。

为了更好地理解K8S的容器安全策略,并且控制篇幅,我们在本篇中先介绍OCP的SCC。

1. 内置的scc

安全上下文约束是OpenShift提供的工具,用于控制平台上允许每个Pod请求的特权。

OpenShift带有8个预定义的安全上下文约束,您可以使用oc get scc命令列出这些约束。

SCCDescription说明
restricted受限拒绝访问所有主机功能,并要求Pod必须与UID和分配给名称空间的SELinux上下文一起运行。这是限制性最强的SCC,默认情况下,它用于经过身份验证的用户换句话说,这是最安全的一种SCC。
nonrootnonroot提供受限SCC的所有功能,但允许用户使用任何非root UID运行。用户必须指定UID,或者必须在容器运行时清单上指定UID。需要具有相同的其他受限制的SCC安全功能的可预测的非根UID的应用程序可以使用此SCC,只要它们在清单中通知了UID。
anyuidanyuid提供了受限SCC的所有功能,但允许用户使用任何UID和任何GID运行。在kubernetes和OpenShift之类的平台上,这等效于允许在容器内部和外部都允许UID 0或root用户。SELinux在这里起到了重要的作用,它增加了一层保护,并且使用seccomp过滤不需要的系统调用。
hostmount-anyuidhostmount-anyuid提供了受限SCC的所有功能,但允许通过Pod进行主机安装和任何UID。这主要由持久性卷回收器使用。警告:此SCC允许主机文件系统作为任何UID(包括UID 0)进行访问。请谨慎授权。与anyuid相同的警告,但在这里它会更进一步,并允许安装主机卷。请注意,描述中提到的卷回收器是受信任的工作负载,也是必不可少的基础架构.
hostnetworkhostnetwork允许使用主机网络和主机端口,但仍要求Pod必须与分配给namepac的UID和SELinux上下文一起运行e在这里,pod/容器将能够直接“查看和使用”主机网络堆栈。非零UID和预分配的SELinux上下文将有助于提供另一层安全性。
node-exporternode-exporter scc is used for the Prometheus node exporterNode-exporter 是为Prometheus设计的,用于从集群中检索指标。它允许访问主机网络,主机PIDS和主机卷,但不能访问主机IPC。也允许anyuid。不能被其他应用程序使用。
hostaccesshostaccess允许访问所有主机名称空间,但仍要求Pod必须与分配给名称空间的UID和SELinux上下文一起运行。警告:此SCC允许主机访问名称空间,文件系统和PIDS。它只能由受信任的Pod使用。谨慎行事。在描述中,主机名称空间是指在pod或容器名称空间之外,或者,我们可以将其称为节点或根Linux名称空间。确实,限制UID并使用SELinux将为保护节点设置一层安全性。但是,它是一个非常宽松的SCC,仅应由绝对必要的受信任工作负载使用。
Privilegedprivileged允许访问所有特权和主机功能,并具有以任何用户,任何组,任何fsGroup和任何SELinux上下文运行的能力。警告:这是最宽松的SCC,仅应用于集群管理。谨慎行事。此scc允许pod /容器控制主机/ worker节点甚至其他容器中的所有内容。这是最特权和最宽松的SCC策略。仅受信任的工作负载应使用此选项,并讨论是否应将其用于生产中是有效的。特权pod可以完全控制主机。

本质是scc权限列表不同:

restrictedanyuidprivileged
allowHostDirVolumePlugin: falseallowHostDirVolumePlugin: falseallowHostDirVolumePlugin: true
allowHostIPC: falseallowHostIPC: falseallowHostIPC: true
allowHostNetwork: falseallowHostNetwork: falseallowHostNetwork: true
allowHostPID: falseallowHostPID: falseallowHostPID: true
allowHostPorts: falseallowHostPorts: falseallowHostPorts: true
allowPrivilegeEscalation: trueallowPrivilegeEscalation: trueallowPrivilegeEscalation: true
allowPrivilegedContainer: falseallowPrivilegedContainer: falseallowPrivilegedContainer: true
allowedCapabilities: nullallowedCapabilities: [allowedCapabilities: [*]
NET_RAW
FSETID
SETGID
SETUID
CHOWN
SYS_CHROOT]
allowedUnsafeSysctls:allowedUnsafeSysctls: [*]
apiVersion: security.openshift.io/v1apiVersion: security.openshift.io/v1apiVersion: security.openshift.io/v1
defaultAddCapabilities: nulldefaultAddCapabilities: nulldefaultAddCapabilities: null
fsGroup:fsGroup: RunAsAnyfsGroup: RunAsAny
groups: []groups: [system:cluster-admins]groups: [system:cluster-admins, system:nodes, system:masters]
kind: SecurityContextConstraintskind: SecurityContextConstraintskind: SecurityContextConstraints
name: restrictedname: anyuidname: privileged
resourceVersion: “3512475209”resourceVersion: “3512475203”resourceVersion: “340”
uid: bdb21b4f-dfda-456a-8aa3-7fdcd8ee2f2duid: d35f70ed-47ce-4b22-83d0-b0b2a4bc07f8uid: 1df9ef3c-1fab-4031-a2cd-3d7479069050
priority: nullpriority: 10priority: null
readOnlyRootFilesystem: falsereadOnlyRootFilesystem: falsereadOnlyRootFilesystem: false
requiredDropCapabilities: [KILL, MKNOD, SETUID, SETGID]requiredDropCapabilities: [MKNOD]requiredDropCapabilities: null
runAsUser:runAsUser: RunAsAnyrunAsUser: RunAsAny
seLinuxContext:seLinuxContext: MustRunAsseLinuxContext: RunAsAny
supplementalGroups: RunAsAnysupplementalGroups: RunAsAnysupplementalGroups: RunAsAny
users: []users: []users: [system:admin, system:serviceaccount:openshift-infra:build-controller]
volumes: [configMap, csi, downwardAPI, emptyDir, ephemeral, persistentVolumeClaim, projected, secret]volumes: [configMap, csi, downwardAPI, emptyDir, ephemeral, persistentVolumeClaim, projected, secret]volumes: [*]

2. OpenShift如何确定pod的scc

  • 如果Pod指定了SCC注解,且ServiceAccount有权限使用该SCC,则优先使用注解指定的SCC。
  • 如果未指定注解,则基于ServiceAccount的绑定权限,从严格到宽松挑选合适的SCC。
  • 无论是否指定注解,最终都需要验证ServiceAccount的绑定权限,这意味着标签并不能完全绕过权限控制。

2.1 Pod未带SCC标签的情况

  • 如果Pod没有明确指定SCC,OpenShift会按照以下流程选择一个适用的SCC:
  • 检查Pod的ServiceAccount,以及该ServiceAccount的角色绑定所允许的SCC列表。

对SCC列表按照权限的严格程度排序:

  • 从最严格的SCC(例如restricted)到最宽松的SCC(例如privileged)。
  • 从排序中选择第一个Pod能满足的SCC作为其适用的SCC。

2.2. Pod带有SCC标签的情况

OpenShift允许通过Pod的openshift.io/scc注解直接指定使用的SCC。

如果Pod通过注解明确指定了一个SCC(如openshift.io/scc=restricted),OpenShift会优先尝试使用该SCC。

然而,Pod仍需满足以下条件:

  • Pod的ServiceAccount具有绑定到该SCC的权限:OpenShift会检查绑定(RoleBinding 或 ClusterRoleBinding)中,是否允许ServiceAccount使用这个指定的SCC。
  • 如果绑定验证成功,则使用指定的SCC。
  • 如果绑定验证失败,则该Pod无法创建。

总结

以上为个人经验,希望能给大家一个参考,也希望大家多多支持脚本之家。

相关文章

  • kubelet为cadvisor添加namespace/pod/container标签示例详解

    kubelet为cadvisor添加namespace/pod/container标签示例详解

    这篇文章主要为大家介绍了kubelet为cadvisor添加namespace/pod/container标签示例详解,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪
    2023-09-09
  • k8s series初级calico使用介绍

    k8s series初级calico使用介绍

    这篇文章主要为大家介绍了k8s series初级calico使用介绍,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪
    2022-06-06
  • K8S之StatefulSet有状态服务详解

    K8S之StatefulSet有状态服务详解

    本文主要介绍了K8S之StatefulSet有状态服务详解,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
    2022-07-07
  • kubelet启动失败的解决方案

    kubelet启动失败的解决方案

    这篇文章主要介绍了kubelet启动失败的解决方案,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教
    2025-10-10
  • kubernetes Volume存储卷configMap学习笔记

    kubernetes Volume存储卷configMap学习笔记

    这篇文章主要为大家介绍了kubernetes Volume存储卷configMap学习笔记,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪
    2022-05-05
  • Kubernetes之Pod的调度实现方式

    Kubernetes之Pod的调度实现方式

    Kubernetes通过定向调度(NodeName/NodeSelector)、亲和性调度(NodeAffinity/PodAffinity/PodAntiAffinity)及污点容忍(Taints/Toleration)实现Pod节点控制,分别用于强制指定节点、优化部署位置和灵活管理节点准入,满足不同场景下的调度需求
    2025-09-09
  • K8S临时存储-本地存储-PV和PVC详解-动态存储(StorageClass)

    K8S临时存储-本地存储-PV和PVC详解-动态存储(StorageClass)

    文章介绍了Kubernetes中容器数据的持久化解决方案,包括hostPath、emptyDir、NFS卷以及PV和PVC,详细说明了这些存储卷的类型、配置方法和使用场景,并提供了创建和绑定存储卷的示例,此外,还讨论了存储卷的回收策略和卷模式,以及如何使用StorageClass进行动态存储配置
    2026-03-03
  • 云原生时代的前端部署最佳实践(含详细代码)

    云原生时代的前端部署最佳实践(含详细代码)

    云原生安全架构应运而生,它通过零信任、自动化防护和全生命周期管理等理念,为企业提供从基础设施到应用层的全方位保护,这篇文章主要介绍了云原生时代的前端部署最佳实践,需要的朋友可以参考下
    2026-04-04
  • K8S加入新的node节点实现方式

    K8S加入新的node节点实现方式

    文章主要介绍了基于kubeadm安装的k8s集群加入新的节点的过程,包括初始化节点、安装Docker和相关组件、配置镜像下载加速器、添加软件源、安装组件、上传和解压镜像、加入新的节点并查看节点状态等步骤
    2026-04-04
  • 关于CentOS7日志文件及journalctl日志查看方法

    关于CentOS7日志文件及journalctl日志查看方法

    这篇文章主要介绍了关于CentOS7日志文件及journalctl日志查看方法,具有很好的参考价值,希望对大家有所帮助。如有错误或未考虑完全的地方,望不吝赐教
    2023-03-03

最新评论