使用 Open Policy Agent 与 Gatekeeper 在 ingress-nginx 中强制 Ingress pathType 策略【免费下载链接】ingress-nginxIngress NGINX Controller for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/in/ingress-nginx导读本文基于 ingress-nginx 仓库中的 openpolicyagent 示例讲解如何利用 Open Policy AgentOPA及其 Kubernetes 落地实现 Gatekeeper为 Ingress 资源实施基于策略的准入控制默认阻止pathType: ImplementationSpecific的使用并允许特定命名空间豁免。读完本文你将掌握 GatekeeperConstraintTemplateConstraint的两层编写模型、Rego 校验规则的阅读与调参方法、配套测试用例的验证方式以及它与 ingress-nginx 内置strict-validate-path-type校验之间的定位差异从而构建一套适合自己集群的 Ingress 路径类型治理方案。背景为什么 Ingress pathType 需要治理Kubernetes Ingress API 允许用户为每条路径声明 pathType标准定义了三种取值ExactURL 必须与路径完全匹配Prefix按 URL 前缀分段匹配ImplementationSpecific匹配方式完全由 Ingress Controller 自行解释可以包含正则表达式、变量以及当前控制器特有的一切语法特性。前两种类型在官方语义上只应包含少量受限字符而ImplementationSpecific不受此约束。对于 ingress-nginx 来说ImplementationSpecific路径最终会进入 Nginx 的location配置可能包含正则等任意内容——这意味着拥有该权限的用户实际上可以往代理配置里注入任意配置片段。因此部署 Ingress Controller 的集群管理员Ingress Admins必须审慎信任有权使用pathType: ImplementationSpecific的用户并对此建立治理手段。本仓库给出的治理示例正是围绕这一风险展开的使用 Gatekeeper 默认阻止ImplementationSpecific仅放行指定的命名空间示例中的privileged且建议管理员在放行时进一步约束允许的字符集合。方案组成两个 CRD 与一个 Rego 规则示例由三部分组成全部位于 docs/examples/openpolicyagent 目录文件角色说明template.yamlConstraintTemplate用 Rego 定义哪些 pathType 被阻止、哪些命名空间可豁免的校验逻辑并声明约束 CRD 的参数 schemarule.yamlConstraint实例化后的策略指定作用对象Ingress、豁免命名空间列表、被阻止的 pathType 列表tests/测试用例覆盖放行 Exact阻止 ImplementationSpecific豁免命名空间放行三种场景工作机制是Gatekeeper 作为准入 Webhook拦截 Ingress 的创建与更新请求将对象连同策略参数交给 Rego 求值若命中violation请求即被拒绝并返回报错消息。第一步编写 ConstraintTemplate 定义校验逻辑template.yaml 中声明了一个名为k8sblockingresspathtype的ConstraintTemplateapiVersion: templates.gatekeeper.sh/v1。其核心结构如下apiVersion: templates.gatekeeper.sh/v1 kind: ConstraintTemplate metadata: name: k8sblockingresspathtype annotations: metadata.gatekeeper.sh/title: Block a pathType usage description: - Users should not be able to use specific pathTypes spec: crd: spec: names: kind: K8sBlockIngressPathType validation: openAPIV3Schema: type: object properties: blockedTypes: type: array items: type: string namespacesExceptions: type: array items: type: string targets: - target: admission.k8s.gatekeeper.sh rego: | package K8sBlockIngressPathType violation[{msg: msg}] { input.review.kind.kind Ingress ns : input.review.object.metadata.namespace exemptNS : [good | exempts input.parameters.namespacesExceptions[_] ; good exempts ns] not any(exemptNS) pathType : object.get(input.review.object.spec.rules[_].http.paths[_], pathType, ) blockedPath : [blocked | blockedTypes input.parameters.blockedTypes[_] ; blocked blockedTypes pathType] any(blockedPath) msg : sprintf(pathType %v is not allowed in this namespace, [pathType]) }逐段拆解crd.spec.names.kind声明由该模板生成的约束 CRD 类型名为K8sBlockIngressPathType后续通过rule.yaml创建该类型的实例Constraint。validation.openAPIV3Schema为约束实例定义参数 schema本模板要求实例提供两个数组参数——blockedTypes要阻止的 pathType 列表与namespacesExceptions豁免命名空间列表。schema 的存在让 Gatekeeper 能在约束 CRD 层面直接做参数合法性校验。targets[0].rego真正的校验逻辑属于K8sBlockIngressPathType包规则通过violation[{msg: msg}]的推导式表达第 32 行input.review.kind.kind Ingress只处理 Ingress 对象第 33–35 行取对象所在命名空间ns构造exemptNS列表并与namespacesExceptions比对若命中豁免则not any(exemptNS)失败整条规则不产生 violation第 36 行用object.get读取路径的pathType默认空字符串遍历spec.rules[_].http.paths[_]覆盖所有 host 下的所有路径第 37–38 行若pathType命中blockedTypes中的任一值则产生 violation第 39 行sprintf组装拒绝消息例如pathType ImplementationSpecific is not allowed in this namespace。值得注意的细节Rego 中input.review.kind.kind只校验kind Ingress并未校验apiVersion而约束实例的match.kinds会在下一层完成对 API 组的限定。第二步实例化 Constraint 并配置豁免与阻止清单rule.yaml 创建了一个名为implspecificisblocked的约束实例apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sBlockIngressPathType metadata: name: implspecificisblocked spec: match: kinds: - apiGroups: [networking.k8s.io] kinds: [Ingress] parameters: namespacesExceptions: - privileged blockedTypes: - ImplementationSpecificspec.match.kinds限定该策略只作用于networking.k8s.ioAPI 组下的Ingress与模板中kind Ingress的判断形成双层校验spec.parameters与模板 schema 对应——blockedTypes: [ImplementationSpecific]表示默认阻止该 pathTypenamespacesExceptions: [privileged]表示privileged命名空间内的 Ingress 不受限制。调参建议源自原文档当允许使用ImplementationSpecific时管理员应当结合自身需求修改规则例如强制校验路径只包含指定字符集合原文档明确建议 enforce a specific set of characters而不仅是单纯放行。也可以扩展blockedTypes列表来同时治理其他 pathType 的误用。第三步用测试用例验证策略行为仓库为上述策略提供了三份 Ingress 测试样例位于 tests可作为 Gatekeeper 约束测试或手工kubectl apply验证的输入测试文件命名空间pathType预期结果should-allow.yaml默认无Exact放行未命中 blockedTypesshould-deny.yaml默认无ImplementationSpecific拒绝should-allow-ns-except.yamlprivilegedImplementationSpecific放行命中豁免列表三份 YAML 均声明apiVersion: networking.k8s.io/v1、kind: Ingress与指向svc1:8080的后端唯一的变量是命名空间与pathType这正是为了让三种预期结果互斥可对照。例如被阻止场景apiVersion: networking.k8s.io/v1 kind: Ingress metadata: creationTimestamp: null name: simple spec: rules: - host: foo2.com http: paths: - backend: service: name: svc1 port: number: 8080 path: /bar pathType: ImplementationSpecific该 Ingress 未处于豁免命名空间因此会被 Gatekeeper 拒绝错误消息为pathType ImplementationSpecific is not allowed in this namespace。与 ingress-nginx 内置路径校验的关系需要明确区分本文的 OPA 方案与 ingress-nginx 内置的路径校验能力两者定位互补而非替代OPA/Gatekeeper本文方案在 Ingress 对象进入集群时由准入 Webhook拦截属于提交前治理关注点是谁能用哪种 pathType、在哪个命名空间用策略完全可编程、可参数化。ingress-nginx 内置校验在控制器侧生效。控制器支持strict-validate-path-type配置项见 internal/ingress/controller/config/config.go开启后会对Exact/Prefix路径做严格校验同时ValidatePathType会跳过ImplementationSpecific路径的校验见 internal/ingress/inspector/inspector.go因为这类路径允许包含正则等任意字符。从源码看内置校验使用的合法路径正则定义于 internal/ingress/inspector/rules.govalidPathType regexp.MustCompile((?i)^/[[:alnum:]._\-/]*$)即Exact/Prefix路径必须以/开头且仅允许字母数字、.、_、-、/。控制器对该逻辑的调用发生在校验 Ingress 时见 internal/ingress/controller/controller.go并由 internal/ingress/inspector/inspector_test.go 中的用例覆盖例如验证pathType: ImplementationSpecific配合正则路径/foo.不被拒绝。由此可以得到一致的治理结论内置校验有意为ImplementationSpecific留白因为它需要承载正则等高级特性这份信任缺口正是 OPA/Gatekeeper 策略应当补位的地方。两者结合使用时建议在 Gatekeeper 侧管住谁能用在控制器侧开启strict-validate-path-type管住非豁免路径的字符合法性。部署与运行建议由于仓库仅提供策略定义与测试样例实际运行依赖环境中已安装的 Gatekeeper简要流程如下配置层面可参考上文各 YAML部署 Gatekeeper 到集群约束模板与控制器的准入 Webhook 由此组件提供应用 template.yaml 注册ConstraintTemplate等待其生成的K8sBlockIngressPathTypeCRD 就绪应用 rule.yaml 创建约束实例使策略生效以 tests 中的三个 Ingress 为样本验证放行与拒绝行为是否符合预期按需修改namespacesExceptions与blockedTypes并在允许ImplementationSpecific时追加字符集约束。小结本文以 ingress-nginx 仓库的 OPA 示例为主线完成了从风险分析、ConstraintTemplate编写、Constraint实例化到测试验证的完整闭环ImplementationSpecific作为把正则注入 Nginx 配置的通道必须被置于受控范围内Gatekeeper 通过两层 CRD 加一段 Rego 规则即可实现默认阻止、命名空间豁免、参数可调的策略而它与控制器内置的strict-validate-path-type校验各司其职共同构成 Ingress 路径类型治理的双保险。【免费下载链接】ingress-nginxIngress NGINX Controller for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/in/ingress-nginx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 使用 Open Policy Agent 与 Gatekeeper 在 ingress-nginx 中强制 Ingress pathType 策略
使用 Open Policy Agent 与 Gatekeeper 在 ingress-nginx 中强制 Ingress pathType 策略【免费下载链接】ingress-nginxIngress NGINX Controller for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/in/ingress-nginx导读本文基于 ingress-nginx 仓库中的 openpolicyagent 示例讲解如何利用 Open Policy AgentOPA及其 Kubernetes 落地实现 Gatekeeper为 Ingress 资源实施基于策略的准入控制默认阻止pathType: ImplementationSpecific的使用并允许特定命名空间豁免。读完本文你将掌握 GatekeeperConstraintTemplateConstraint的两层编写模型、Rego 校验规则的阅读与调参方法、配套测试用例的验证方式以及它与 ingress-nginx 内置strict-validate-path-type校验之间的定位差异从而构建一套适合自己集群的 Ingress 路径类型治理方案。背景为什么 Ingress pathType 需要治理Kubernetes Ingress API 允许用户为每条路径声明 pathType标准定义了三种取值ExactURL 必须与路径完全匹配Prefix按 URL 前缀分段匹配ImplementationSpecific匹配方式完全由 Ingress Controller 自行解释可以包含正则表达式、变量以及当前控制器特有的一切语法特性。前两种类型在官方语义上只应包含少量受限字符而ImplementationSpecific不受此约束。对于 ingress-nginx 来说ImplementationSpecific路径最终会进入 Nginx 的location配置可能包含正则等任意内容——这意味着拥有该权限的用户实际上可以往代理配置里注入任意配置片段。因此部署 Ingress Controller 的集群管理员Ingress Admins必须审慎信任有权使用pathType: ImplementationSpecific的用户并对此建立治理手段。本仓库给出的治理示例正是围绕这一风险展开的使用 Gatekeeper 默认阻止ImplementationSpecific仅放行指定的命名空间示例中的privileged且建议管理员在放行时进一步约束允许的字符集合。方案组成两个 CRD 与一个 Rego 规则示例由三部分组成全部位于 docs/examples/openpolicyagent 目录文件角色说明template.yamlConstraintTemplate用 Rego 定义哪些 pathType 被阻止、哪些命名空间可豁免的校验逻辑并声明约束 CRD 的参数 schemarule.yamlConstraint实例化后的策略指定作用对象Ingress、豁免命名空间列表、被阻止的 pathType 列表tests/测试用例覆盖放行 Exact阻止 ImplementationSpecific豁免命名空间放行三种场景工作机制是Gatekeeper 作为准入 Webhook拦截 Ingress 的创建与更新请求将对象连同策略参数交给 Rego 求值若命中violation请求即被拒绝并返回报错消息。第一步编写 ConstraintTemplate 定义校验逻辑template.yaml 中声明了一个名为k8sblockingresspathtype的ConstraintTemplateapiVersion: templates.gatekeeper.sh/v1。其核心结构如下apiVersion: templates.gatekeeper.sh/v1 kind: ConstraintTemplate metadata: name: k8sblockingresspathtype annotations: metadata.gatekeeper.sh/title: Block a pathType usage description: - Users should not be able to use specific pathTypes spec: crd: spec: names: kind: K8sBlockIngressPathType validation: openAPIV3Schema: type: object properties: blockedTypes: type: array items: type: string namespacesExceptions: type: array items: type: string targets: - target: admission.k8s.gatekeeper.sh rego: | package K8sBlockIngressPathType violation[{msg: msg}] { input.review.kind.kind Ingress ns : input.review.object.metadata.namespace exemptNS : [good | exempts input.parameters.namespacesExceptions[_] ; good exempts ns] not any(exemptNS) pathType : object.get(input.review.object.spec.rules[_].http.paths[_], pathType, ) blockedPath : [blocked | blockedTypes input.parameters.blockedTypes[_] ; blocked blockedTypes pathType] any(blockedPath) msg : sprintf(pathType %v is not allowed in this namespace, [pathType]) }逐段拆解crd.spec.names.kind声明由该模板生成的约束 CRD 类型名为K8sBlockIngressPathType后续通过rule.yaml创建该类型的实例Constraint。validation.openAPIV3Schema为约束实例定义参数 schema本模板要求实例提供两个数组参数——blockedTypes要阻止的 pathType 列表与namespacesExceptions豁免命名空间列表。schema 的存在让 Gatekeeper 能在约束 CRD 层面直接做参数合法性校验。targets[0].rego真正的校验逻辑属于K8sBlockIngressPathType包规则通过violation[{msg: msg}]的推导式表达第 32 行input.review.kind.kind Ingress只处理 Ingress 对象第 33–35 行取对象所在命名空间ns构造exemptNS列表并与namespacesExceptions比对若命中豁免则not any(exemptNS)失败整条规则不产生 violation第 36 行用object.get读取路径的pathType默认空字符串遍历spec.rules[_].http.paths[_]覆盖所有 host 下的所有路径第 37–38 行若pathType命中blockedTypes中的任一值则产生 violation第 39 行sprintf组装拒绝消息例如pathType ImplementationSpecific is not allowed in this namespace。值得注意的细节Rego 中input.review.kind.kind只校验kind Ingress并未校验apiVersion而约束实例的match.kinds会在下一层完成对 API 组的限定。第二步实例化 Constraint 并配置豁免与阻止清单rule.yaml 创建了一个名为implspecificisblocked的约束实例apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sBlockIngressPathType metadata: name: implspecificisblocked spec: match: kinds: - apiGroups: [networking.k8s.io] kinds: [Ingress] parameters: namespacesExceptions: - privileged blockedTypes: - ImplementationSpecificspec.match.kinds限定该策略只作用于networking.k8s.ioAPI 组下的Ingress与模板中kind Ingress的判断形成双层校验spec.parameters与模板 schema 对应——blockedTypes: [ImplementationSpecific]表示默认阻止该 pathTypenamespacesExceptions: [privileged]表示privileged命名空间内的 Ingress 不受限制。调参建议源自原文档当允许使用ImplementationSpecific时管理员应当结合自身需求修改规则例如强制校验路径只包含指定字符集合原文档明确建议 enforce a specific set of characters而不仅是单纯放行。也可以扩展blockedTypes列表来同时治理其他 pathType 的误用。第三步用测试用例验证策略行为仓库为上述策略提供了三份 Ingress 测试样例位于 tests可作为 Gatekeeper 约束测试或手工kubectl apply验证的输入测试文件命名空间pathType预期结果should-allow.yaml默认无Exact放行未命中 blockedTypesshould-deny.yaml默认无ImplementationSpecific拒绝should-allow-ns-except.yamlprivilegedImplementationSpecific放行命中豁免列表三份 YAML 均声明apiVersion: networking.k8s.io/v1、kind: Ingress与指向svc1:8080的后端唯一的变量是命名空间与pathType这正是为了让三种预期结果互斥可对照。例如被阻止场景apiVersion: networking.k8s.io/v1 kind: Ingress metadata: creationTimestamp: null name: simple spec: rules: - host: foo2.com http: paths: - backend: service: name: svc1 port: number: 8080 path: /bar pathType: ImplementationSpecific该 Ingress 未处于豁免命名空间因此会被 Gatekeeper 拒绝错误消息为pathType ImplementationSpecific is not allowed in this namespace。与 ingress-nginx 内置路径校验的关系需要明确区分本文的 OPA 方案与 ingress-nginx 内置的路径校验能力两者定位互补而非替代OPA/Gatekeeper本文方案在 Ingress 对象进入集群时由准入 Webhook拦截属于提交前治理关注点是谁能用哪种 pathType、在哪个命名空间用策略完全可编程、可参数化。ingress-nginx 内置校验在控制器侧生效。控制器支持strict-validate-path-type配置项见 internal/ingress/controller/config/config.go开启后会对Exact/Prefix路径做严格校验同时ValidatePathType会跳过ImplementationSpecific路径的校验见 internal/ingress/inspector/inspector.go因为这类路径允许包含正则等任意字符。从源码看内置校验使用的合法路径正则定义于 internal/ingress/inspector/rules.govalidPathType regexp.MustCompile((?i)^/[[:alnum:]._\-/]*$)即Exact/Prefix路径必须以/开头且仅允许字母数字、.、_、-、/。控制器对该逻辑的调用发生在校验 Ingress 时见 internal/ingress/controller/controller.go并由 internal/ingress/inspector/inspector_test.go 中的用例覆盖例如验证pathType: ImplementationSpecific配合正则路径/foo.不被拒绝。由此可以得到一致的治理结论内置校验有意为ImplementationSpecific留白因为它需要承载正则等高级特性这份信任缺口正是 OPA/Gatekeeper 策略应当补位的地方。两者结合使用时建议在 Gatekeeper 侧管住谁能用在控制器侧开启strict-validate-path-type管住非豁免路径的字符合法性。部署与运行建议由于仓库仅提供策略定义与测试样例实际运行依赖环境中已安装的 Gatekeeper简要流程如下配置层面可参考上文各 YAML部署 Gatekeeper 到集群约束模板与控制器的准入 Webhook 由此组件提供应用 template.yaml 注册ConstraintTemplate等待其生成的K8sBlockIngressPathTypeCRD 就绪应用 rule.yaml 创建约束实例使策略生效以 tests 中的三个 Ingress 为样本验证放行与拒绝行为是否符合预期按需修改namespacesExceptions与blockedTypes并在允许ImplementationSpecific时追加字符集约束。小结本文以 ingress-nginx 仓库的 OPA 示例为主线完成了从风险分析、ConstraintTemplate编写、Constraint实例化到测试验证的完整闭环ImplementationSpecific作为把正则注入 Nginx 配置的通道必须被置于受控范围内Gatekeeper 通过两层 CRD 加一段 Rego 规则即可实现默认阻止、命名空间豁免、参数可调的策略而它与控制器内置的strict-validate-path-type校验各司其职共同构成 Ingress 路径类型治理的双保险。【免费下载链接】ingress-nginxIngress NGINX Controller for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/in/ingress-nginx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考