k8s scc權(quán)限和內(nèi)置的restricted、anyuid、privileged詳解

更新時(shí)間：2025年07月11日 08:50:06 作者：云川之下

這篇文章主要介紹了k8s scc權(quán)限和內(nèi)置的restricted、anyuid、privileged,具有很好的參考價(jià)值,希望對(duì)大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教

概述

在OpenShift（后文簡(jiǎn)稱OCP）中，很早就一個(gè)概念：Security Context Constraints ，簡(jiǎn)稱SCC，即安全上下文約束。

K8S的Pod安全策略和OCP中的SCC有一定繼承（現(xiàn)有OCP的SCC后有K8S的pod安全策略）。

為了更好地理解K8S的容器安全策略，并且控制篇幅，我們?cè)诒酒邢冉榻BOCP的SCC。

1. 內(nèi)置的scc

安全上下文約束是OpenShift提供的工具，用于控制平臺(tái)上允許每個(gè)Pod請(qǐng)求的特權(quán)。

OpenShift帶有8個(gè)預(yù)定義的安全上下文約束，您可以使用oc get scc命令列出這些約束。

SCC	Description	說(shuō)明
restricted	受限拒絕訪問(wèn)所有主機(jī)功能，并要求Pod必須與UID和分配給名稱空間的SELinux上下文一起運(yùn)行。這是限制性最強(qiáng)的SCC，默認(rèn)情況下，它用于經(jīng)過(guò)身份驗(yàn)證的用戶	換句話說(shuō)，這是最安全的一種SCC。
nonroot	nonroot提供受限SCC的所有功能，但允許用戶使用任何非root UID運(yùn)行。用戶必須指定UID，或者必須在容器運(yùn)行時(shí)清單上指定UID。	需要具有相同的其他受限制的SCC安全功能的可預(yù)測(cè)的非根UID的應(yīng)用程序可以使用此SCC，只要它們?cè)谇鍐沃型ㄖ薝ID。
anyuid	anyuid提供了受限SCC的所有功能，但允許用戶使用任何UID和任何GID運(yùn)行。	在kubernetes和OpenShift之類的平臺(tái)上，這等效于允許在容器內(nèi)部和外部都允許UID 0或root用戶。SELinux在這里起到了重要的作用，它增加了一層保護(hù)，并且使用seccomp過(guò)濾不需要的系統(tǒng)調(diào)用。
hostmount-anyuid	hostmount-anyuid提供了受限SCC的所有功能，但允許通過(guò)Pod進(jìn)行主機(jī)安裝和任何UID。這主要由持久性卷回收器使用。警告：此SCC允許主機(jī)文件系統(tǒng)作為任何UID（包括UID 0）進(jìn)行訪問(wèn)。請(qǐng)謹(jǐn)慎授權(quán)。	與anyuid相同的警告，但在這里它會(huì)更進(jìn)一步，并允許安裝主機(jī)卷。請(qǐng)注意，描述中提到的卷回收器是受信任的工作負(fù)載，也是必不可少的基礎(chǔ)架構(gòu).
hostnetwork	hostnetwork允許使用主機(jī)網(wǎng)絡(luò)和主機(jī)端口，但仍要求Pod必須與分配給namepac的UID和SELinux上下文一起運(yùn)行e	在這里，pod/容器將能夠直接“查看和使用”主機(jī)網(wǎng)絡(luò)堆棧。非零UID和預(yù)分配的SELinux上下文將有助于提供另一層安全性。
node-exporter	node-exporter scc is used for the Prometheus node exporter	Node-exporter 是為Prometheus設(shè)計(jì)的，用于從集群中檢索指標(biāo)。它允許訪問(wèn)主機(jī)網(wǎng)絡(luò)，主機(jī)PIDS和主機(jī)卷，但不能訪問(wèn)主機(jī)IPC。也允許anyuid。不能被其他應(yīng)用程序使用。
hostaccess	hostaccess允許訪問(wèn)所有主機(jī)名稱空間，但仍要求Pod必須與分配給名稱空間的UID和SELinux上下文一起運(yùn)行。警告：此SCC允許主機(jī)訪問(wèn)名稱空間，文件系統(tǒng)和PIDS。它只能由受信任的Pod使用。謹(jǐn)慎行事。	在描述中，主機(jī)名稱空間是指在pod或容器名稱空間之外，或者，我們可以將其稱為節(jié)點(diǎn)或根Linux名稱空間。確實(shí)，限制UID并使用SELinux將為保護(hù)節(jié)點(diǎn)設(shè)置一層安全性。但是，它是一個(gè)非常寬松的SCC，僅應(yīng)由絕對(duì)必要的受信任工作負(fù)載使用。
Privileged	privileged允許訪問(wèn)所有特權(quán)和主機(jī)功能，并具有以任何用戶，任何組，任何fsGroup和任何SELinux上下文運(yùn)行的能力。警告：這是最寬松的SCC，僅應(yīng)用于集群管理。謹(jǐn)慎行事。	此scc允許pod /容器控制主機(jī)/ worker節(jié)點(diǎn)甚至其他容器中的所有內(nèi)容。這是最特權(quán)和最寬松的SCC策略。僅受信任的工作負(fù)載應(yīng)使用此選項(xiàng)，并討論是否應(yīng)將其用于生產(chǎn)中是有效的。特權(quán)pod可以完全控制主機(jī)。

本質(zhì)是scc權(quán)限列表不同：

restricted	anyuid	privileged
allowHostDirVolumePlugin: false	allowHostDirVolumePlugin: false	allowHostDirVolumePlugin: true
allowHostIPC: false	allowHostIPC: false	allowHostIPC: true
allowHostNetwork: false	allowHostNetwork: false	allowHostNetwork: true
allowHostPID: false	allowHostPID: false	allowHostPID: true
allowHostPorts: false	allowHostPorts: false	allowHostPorts: true
allowPrivilegeEscalation: true	allowPrivilegeEscalation: true	allowPrivilegeEscalation: true
allowPrivilegedContainer: false	allowPrivilegedContainer: false	allowPrivilegedContainer: true
allowedCapabilities: null	allowedCapabilities: [	allowedCapabilities: [*]
	NET_RAW
	FSETID
	SETGID
	SETUID
	CHOWN
	SYS_CHROOT]
allowedUnsafeSysctls:		allowedUnsafeSysctls: [*]
apiVersion: security.openshift.io/v1	apiVersion: security.openshift.io/v1	apiVersion: security.openshift.io/v1
defaultAddCapabilities: null	defaultAddCapabilities: null	defaultAddCapabilities: null
fsGroup:	fsGroup: RunAsAny	fsGroup: RunAsAny
groups: []	groups: [system:cluster-admins]	groups: [system:cluster-admins, system:nodes, system:masters]
kind: SecurityContextConstraints	kind: SecurityContextConstraints	kind: SecurityContextConstraints
name: restricted	name: anyuid	name: privileged
resourceVersion: “3512475209”	resourceVersion: “3512475203”	resourceVersion: “340”
uid: bdb21b4f-dfda-456a-8aa3-7fdcd8ee2f2d	uid: d35f70ed-47ce-4b22-83d0-b0b2a4bc07f8	uid: 1df9ef3c-1fab-4031-a2cd-3d7479069050
priority: null	priority: 10	priority: null
readOnlyRootFilesystem: false	readOnlyRootFilesystem: false	readOnlyRootFilesystem: false
requiredDropCapabilities: [KILL, MKNOD, SETUID, SETGID]	requiredDropCapabilities: [MKNOD]	requiredDropCapabilities: null
runAsUser:	runAsUser: RunAsAny	runAsUser: RunAsAny
seLinuxContext:	seLinuxContext: MustRunAs	seLinuxContext: RunAsAny
supplementalGroups: RunAsAny	supplementalGroups: RunAsAny	supplementalGroups: 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有權(quán)限使用該SCC，則優(yōu)先使用注解指定的SCC。
如果未指定注解，則基于ServiceAccount的綁定權(quán)限，從嚴(yán)格到寬松挑選合適的SCC。
無(wú)論是否指定注解，最終都需要驗(yàn)證ServiceAccount的綁定權(quán)限，這意味著標(biāo)簽并不能完全繞過(guò)權(quán)限控制。

2.1 Pod未帶SCC標(biāo)簽的情況

如果Pod沒(méi)有明確指定SCC，OpenShift會(huì)按照以下流程選擇一個(gè)適用的SCC：
檢查Pod的ServiceAccount，以及該ServiceAccount的角色綁定所允許的SCC列表。

對(duì)SCC列表按照權(quán)限的嚴(yán)格程度排序：

從最嚴(yán)格的SCC（例如restricted）到最寬松的SCC（例如privileged）。
從排序中選擇第一個(gè)Pod能滿足的SCC作為其適用的SCC。

2.2. Pod帶有SCC標(biāo)簽的情況

OpenShift允許通過(guò)Pod的openshift.io/scc注解直接指定使用的SCC。

如果Pod通過(guò)注解明確指定了一個(gè)SCC（如openshift.io/scc=restricted），OpenShift會(huì)優(yōu)先嘗試使用該SCC。

然而，Pod仍需滿足以下條件：

Pod的ServiceAccount具有綁定到該SCC的權(quán)限：OpenShift會(huì)檢查綁定（RoleBinding 或 ClusterRoleBinding）中，是否允許ServiceAccount使用這個(gè)指定的SCC。
如果綁定驗(yàn)證成功，則使用指定的SCC。
如果綁定驗(yàn)證失敗，則該P(yáng)od無(wú)法創(chuàng)建。