静态网站开发课程,淘宝店铺装修模板免费下载,北京市建设局网站首页,嵌入式工程师能干多久文章目录 概述1. 内置的scc2. OpenShift如何确定pod的scc2.1 Pod未带SCC标签的情况2.2. Pod带有SCC标签的情况 参考 概述
在OpenShift#xff08;后文简称OCP#xff09;中#xff0c;很早就一个概念#xff1a;Security Context Constraints #xff0c;简称SCC#xf… 文章目录 概述1. 内置的scc2. OpenShift如何确定pod的scc2.1 Pod未带SCC标签的情况2.2. Pod带有SCC标签的情况 参考 概述
在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权限列表不同
restrictedanyuidprivilegedallowHostDirVolumePlugin: falseallowHostDirVolumePlugin: falseallowHostDirVolumePlugin: trueallowHostIPC: falseallowHostIPC: falseallowHostIPC: trueallowHostNetwork: falseallowHostNetwork: falseallowHostNetwork: trueallowHostPID: falseallowHostPID: falseallowHostPID: trueallowHostPorts: falseallowHostPorts: falseallowHostPorts: trueallowPrivilegeEscalation: trueallowPrivilegeEscalation: trueallowPrivilegeEscalation: trueallowPrivilegedContainer: falseallowPrivilegedContainer: falseallowPrivilegedContainer: trueallowedCapabilities: nullallowedCapabilities: [allowedCapabilities: [*]NET_RAWFSETIDSETGIDSETUIDCHOWNSYS_CHROOT]allowedUnsafeSysctls:allowedUnsafeSysctls: [*]apiVersion: security.openshift.io/v1apiVersion: security.openshift.io/v1apiVersion: security.openshift.io/v1defaultAddCapabilities: nulldefaultAddCapabilities: nulldefaultAddCapabilities: nullfsGroup:fsGroup: RunAsAnyfsGroup: RunAsAnygroups: []groups: [system:cluster-admins]groups: [system:cluster-admins, system:nodes, system:masters]kind: SecurityContextConstraintskind: SecurityContextConstraintskind: SecurityContextConstraintsname: restrictedname: anyuidname: privilegedresourceVersion: “3512475209”resourceVersion: “3512475203”resourceVersion: “340”uid: bdb21b4f-dfda-456a-8aa3-7fdcd8ee2f2duid: d35f70ed-47ce-4b22-83d0-b0b2a4bc07f8uid: 1df9ef3c-1fab-4031-a2cd-3d7479069050priority: nullpriority: 10priority: nullreadOnlyRootFilesystem: falsereadOnlyRootFilesystem: falsereadOnlyRootFilesystem: falserequiredDropCapabilities: [KILL, MKNOD, SETUID, SETGID]requiredDropCapabilities: [MKNOD]requiredDropCapabilities: nullrunAsUser:runAsUser: RunAsAnyrunAsUser: RunAsAnyseLinuxContext:seLinuxContext: MustRunAsseLinuxContext: RunAsAnysupplementalGroups: RunAsAnysupplementalGroups: RunAsAnysupplementalGroups: RunAsAnyusers: []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没有明确指定SCCOpenShift会按照以下流程选择一个适用的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/sccrestrictedOpenShift会优先尝试使用该SCC。然而Pod仍需满足以下条件 Pod的ServiceAccount具有绑定到该SCC的权限OpenShift会检查绑定RoleBinding 或 ClusterRoleBinding中是否允许ServiceAccount使用这个指定的SCC。如果绑定验证成功则使用指定的SCC。如果绑定验证失败则该Pod无法创建。
参考
K8S中的Pod安全策略(上)K8S学习篇3 OpenShift如何确定pod的scc
