后端认证鉴权云原生【免费下载链接】opaOpen Policy Agent (OPA) is an open source, general-purpose policy engine.项目地址https://gitcode.com/gh_mirrors/op/opa点击查看免费下载导读not是 Rego 语言中表达**否定negation**的核心关键字用于在策略中声明某个条件不成立。本文以 OPA 官方策略参考中not关键字文档为主体完整梳理其基本用法、传统否定语义的历史缺陷、future.keywords.not引入的改进机制隐式 body 包裹与显式否定 body并结合仓库源码与 策略语言权威指南 展开源码级佐证。读完本文你将掌握not的正确用法、规避负语义陷阱并能写出与and/or组合的精确否定策略。not关键字Rego 中最主要的否定手段在 Rego 中not是表达 否定negation 的主要手段。与 Rego 中其他关键字一样它还能让策略读起来更像英文从而更易维护。最基本的形式是直接否定一个布尔表达式allow if { not input.user.external }上面的规则表达当input.user.external不为真时允许访问。否定表达式的基础语义要正确理解not需要先明确 Rego 中否定negation的整体规则。根据 policy-language.mdOPA 在求值虚拟文档时会尝试绑定规则体中的变量使得规则中的所有表达式都为真。而当你想表达某些状态不应该存在时就必须使用否定。否定在 Rego 中有两个关键约束安全性safety要求出于安全考虑出现在否定表达式中的变量必须同时出现在规则中另一个非否定的等式表达式中。OPA 会重排表达式确保否定表达式在包含相同变量的其他非否定表达式之后求值不满足该安全标准的规则会被编译器拒绝。标量取值场景最简单的否定只涉及标量值或变量等价于取反操作符package negation t if { greeting : hello not greeting goodbye }此外否定还用于检查某个值在集合中不存在not p[foo]。这与表达式p[_] foo取补p[_] ! foo表示对 p 中的任意项如果该项不是 foo 则为真语义完全不同。典型应用如定义一个文档收集未部署在prod站点的应用名称package negation import data.example.apps import data.example.sites prod_servers contains name if { some site in sites site.name prod some server in site.servers name : server.name } apps_in_prod contains name if { some site in sites some app in apps name : app.name some server in app.servers prod_servers[server] } # 收集所有不在 prod 中的应用 apps_not_in_prod contains name if { some app in apps name : app.name not apps_in_prod[name] }传统否定语义的历史问题在未导入future.keywords.not的情况下编译器会把一个被否定的复合表达式如not f(g(input.x))展开成一系列子表达式并在not之前求值__local0__ input.x g(__local0__, __local1__) not f(__local1__)问题在于如果任何一个子表达式失败——例如input.x未定义或g产生了未定义的结果——那么整条规则都会失败而不是让not成功。这与用户的直觉相悖用户的本意是该条件不成立而一个未定义的中间值却导致静默失败而非得到预期的not结果。从实现层面看这是 Rego 编译器对否定表达式进行 AST 展开时的行为。在仓库中关键字相关语义由 ast/ast.go 的IsKeyword/IsKeywordInRegoVersion统一管理并委托给 v1 层的实现而未来关键字future keywords机制则通过 v1/ast/capabilities.go 中的FutureKeywords字段与能力capabilities过滤逻辑控制具体可见 capabilities_test.go 中以not为宣传关键字的测试用例。改进的否定语义future.keywords.notfuture.keywords.not导入修复了 Rego 否定语义中长期存在的问题。官方强烈建议在使用not关键字时始终导入它见 policy-language.md 的提示框。隐式 body 包裹导入future.keywords.not后复合表达式的否定会把整个编译器展开结果包裹在一个隐式 body中not { __local0__ input.x; g(__local0__, __local1__); f(__local1__) }现在如果任意子表达式未定义或失败整个 body 就不可满足unsatisfiable从而not表达式成功——符合该条件不成立的直觉。以下面这条规则为例当input.role未定义或lookup/admin失败时restricted均会成立{ user: cesar }package negation import future.keywords.not # 当 input.role 未定义或 lookup/admin 失败时成立 restricted if { not admin(lookup(input.user)) } groups : { admin: [alice], user: [bob] } lookup(user) : group if { some group, members in groups user in members } admin(group) if group in [admin, sudo]重要在上述策略中移除future.keywords.not导入restricted规则会开始失败——这正是因为lookup()函数以undefined值失败所致。这个例子直观地演示了传统语义与改进语义的差异。显式否定 body该导入还允许not表达式接收一个花括号包裹的 body而不是单个表达式。例如拒绝任何未在 TCP 443 端口上监听的服务器{ servers: [ { name: web1, listener: { port: 80, protocol: tcp } }, { name: web2, listener: { port: 443, protocol: tcp } }, { name: web3, listener: { port: 443, protocol: udp } } ] }package negation import future.keywords.not # 拒绝任何不在 TCP 443 端口上监听的服务器 deny contains $server {server.name} is misconfigured if { some server in input.servers not { # 下列表达式只要有任何一个失败not 即成功 listener : server.listener listener.port 443 listener.protocol tcp } }关于显式否定 body需要牢记三个关键点可满足性判定当 body不可满足时not成功——即不存在任何变量绑定组合能让 body 中的每个表达式同时为真。局部变量作用域在 body 内部声明的变量如上面的listener作用域是局部的在not块外部不可见。禁止赋值赋值只允许出现在显式 body 中。由于绑定永远不会逃逸出否定范围在单表达式形式中赋值not listener : server.listener会在编译期被拒绝rego_compile_error: cannot assign vars inside negated expression与and/or的组合规则not的结合优先级高于and和or关键字因此not a and b只否定a。若要否定整个合取或析取表达式需要分组package negation import future.keywords.not import future.keywords.or p if { not (input.a or input.b) }需要注意使用not (...)或not { ... }分组时除and/or导入外还必须导入future.keywords.not。否则括号会被当作普通的分组表达式解析而普通分组表达式不能包含and或or。关键字机制与版本演进从实现角度理解not的语义演进可以关注仓库中的关键字管理机制ast/ast.go 定义了IsKeyword与IsKeywordInRegoVersion按 Rego 版本判断某个标识符是否为关键字注释还指出在 Rego v1 兼容模式rego.v1或future.keywords导入下future.keywords会并入默认关键字集无需显式导入。v1/ast/capabilities.go 中的Capabilities结构体携带FutureKeywords字段用于按能力capabilities过滤允许的关键字相关测试v1/ast/capabilities_test.go验证了将not宣传为未来关键字时解析器的行为。这意味着如果你在 OPA 服务端配置了限制版本的 capabilities未在当前版本能力集中声明的未来关键字可能无法使用而导入future.keywords.not则是让策略显式声明自己依赖改进语义的正确姿势。实践建议始终导入future.keywords.not只要使用not就显式import future.keywords.not以获得一致、符合直觉的否定语义避免传统展开方式下的静默失败。区分值不存在与不等于not p[foo]键不存在与p[_] ! foo存在但不等于语义不同按需选择。注意安全性约束否定表达式中的变量必须同时出现在规则内其他非否定等式中否则规则会被编译器拒绝。显式否定 body 用于多条件判定需要否定一组联合条件时用not { ... }包裹并注意赋值只能在 body 内部进行。结合 not 关键字官方文档 与 策略语言指南 中的完整示例你可以在自己的 OPA 策略中准确、安全地使用否定逻辑。赞分享后端认证鉴权云原生【免费下载链接】opaOpen Policy Agent (OPA) is an open source, general-purpose policy engine.项目地址https://gitcode.com/gh_mirrors/op/opa点击查看免费下载相关推荐使用 OPA 的 Rego 关键字 not 检测未定义值与实现策略否定使用 OPA 的 Rego 关键字 not 检测未定义值与实现策略否定 not 是 RegoOpen Policy Agent 的策略语言中表达否定与后端认证鉴权云原生Rego 中的 not 关键字Open Policy Agent 否定语义与实战指南Rego 中的 not 关键字Open Policy Agent 否定语义与实战指南 导读 not 是 RegoOpen Policy Agent 的策略语后端认证鉴权云原生OPA Rego 函数定义指南用 if 关键字增量定义 is_sudo 类函数OPA Rego 函数定义指南用 if 关键字增量定义 is_sudo 类函数 本文围绕 OPAOpen Policy AgentRego 语言中 if后端认证鉴权云原生创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
后端认证鉴权云原生【免费下载链接】opaOpen Policy Agent (OPA) is an open source, general-purpose policy engine.项目地址https://gitcode.com/gh_mirrors/op/opa点击查看免费下载导读not是 Rego 语言中表达**否定negation**的核心关键字用于在策略中声明某个条件不成立。本文以 OPA 官方策略参考中not关键字文档为主体完整梳理其基本用法、传统否定语义的历史缺陷、future.keywords.not引入的改进机制隐式 body 包裹与显式否定 body并结合仓库源码与 策略语言权威指南 展开源码级佐证。读完本文你将掌握not的正确用法、规避负语义陷阱并能写出与and/or组合的精确否定策略。not关键字Rego 中最主要的否定手段在 Rego 中not是表达 否定negation 的主要手段。与 Rego 中其他关键字一样它还能让策略读起来更像英文从而更易维护。最基本的形式是直接否定一个布尔表达式allow if { not input.user.external }上面的规则表达当input.user.external不为真时允许访问。否定表达式的基础语义要正确理解not需要先明确 Rego 中否定negation的整体规则。根据 policy-language.mdOPA 在求值虚拟文档时会尝试绑定规则体中的变量使得规则中的所有表达式都为真。而当你想表达某些状态不应该存在时就必须使用否定。否定在 Rego 中有两个关键约束安全性safety要求出于安全考虑出现在否定表达式中的变量必须同时出现在规则中另一个非否定的等式表达式中。OPA 会重排表达式确保否定表达式在包含相同变量的其他非否定表达式之后求值不满足该安全标准的规则会被编译器拒绝。标量取值场景最简单的否定只涉及标量值或变量等价于取反操作符package negation t if { greeting : hello not greeting goodbye }此外否定还用于检查某个值在集合中不存在not p[foo]。这与表达式p[_] foo取补p[_] ! foo表示对 p 中的任意项如果该项不是 foo 则为真语义完全不同。典型应用如定义一个文档收集未部署在prod站点的应用名称package negation import data.example.apps import data.example.sites prod_servers contains name if { some site in sites site.name prod some server in site.servers name : server.name } apps_in_prod contains name if { some site in sites some app in apps name : app.name some server in app.servers prod_servers[server] } # 收集所有不在 prod 中的应用 apps_not_in_prod contains name if { some app in apps name : app.name not apps_in_prod[name] }传统否定语义的历史问题在未导入future.keywords.not的情况下编译器会把一个被否定的复合表达式如not f(g(input.x))展开成一系列子表达式并在not之前求值__local0__ input.x g(__local0__, __local1__) not f(__local1__)问题在于如果任何一个子表达式失败——例如input.x未定义或g产生了未定义的结果——那么整条规则都会失败而不是让not成功。这与用户的直觉相悖用户的本意是该条件不成立而一个未定义的中间值却导致静默失败而非得到预期的not结果。从实现层面看这是 Rego 编译器对否定表达式进行 AST 展开时的行为。在仓库中关键字相关语义由 ast/ast.go 的IsKeyword/IsKeywordInRegoVersion统一管理并委托给 v1 层的实现而未来关键字future keywords机制则通过 v1/ast/capabilities.go 中的FutureKeywords字段与能力capabilities过滤逻辑控制具体可见 capabilities_test.go 中以not为宣传关键字的测试用例。改进的否定语义future.keywords.notfuture.keywords.not导入修复了 Rego 否定语义中长期存在的问题。官方强烈建议在使用not关键字时始终导入它见 policy-language.md 的提示框。隐式 body 包裹导入future.keywords.not后复合表达式的否定会把整个编译器展开结果包裹在一个隐式 body中not { __local0__ input.x; g(__local0__, __local1__); f(__local1__) }现在如果任意子表达式未定义或失败整个 body 就不可满足unsatisfiable从而not表达式成功——符合该条件不成立的直觉。以下面这条规则为例当input.role未定义或lookup/admin失败时restricted均会成立{ user: cesar }package negation import future.keywords.not # 当 input.role 未定义或 lookup/admin 失败时成立 restricted if { not admin(lookup(input.user)) } groups : { admin: [alice], user: [bob] } lookup(user) : group if { some group, members in groups user in members } admin(group) if group in [admin, sudo]重要在上述策略中移除future.keywords.not导入restricted规则会开始失败——这正是因为lookup()函数以undefined值失败所致。这个例子直观地演示了传统语义与改进语义的差异。显式否定 body该导入还允许not表达式接收一个花括号包裹的 body而不是单个表达式。例如拒绝任何未在 TCP 443 端口上监听的服务器{ servers: [ { name: web1, listener: { port: 80, protocol: tcp } }, { name: web2, listener: { port: 443, protocol: tcp } }, { name: web3, listener: { port: 443, protocol: udp } } ] }package negation import future.keywords.not # 拒绝任何不在 TCP 443 端口上监听的服务器 deny contains $server {server.name} is misconfigured if { some server in input.servers not { # 下列表达式只要有任何一个失败not 即成功 listener : server.listener listener.port 443 listener.protocol tcp } }关于显式否定 body需要牢记三个关键点可满足性判定当 body不可满足时not成功——即不存在任何变量绑定组合能让 body 中的每个表达式同时为真。局部变量作用域在 body 内部声明的变量如上面的listener作用域是局部的在not块外部不可见。禁止赋值赋值只允许出现在显式 body 中。由于绑定永远不会逃逸出否定范围在单表达式形式中赋值not listener : server.listener会在编译期被拒绝rego_compile_error: cannot assign vars inside negated expression与and/or的组合规则not的结合优先级高于and和or关键字因此not a and b只否定a。若要否定整个合取或析取表达式需要分组package negation import future.keywords.not import future.keywords.or p if { not (input.a or input.b) }需要注意使用not (...)或not { ... }分组时除and/or导入外还必须导入future.keywords.not。否则括号会被当作普通的分组表达式解析而普通分组表达式不能包含and或or。关键字机制与版本演进从实现角度理解not的语义演进可以关注仓库中的关键字管理机制ast/ast.go 定义了IsKeyword与IsKeywordInRegoVersion按 Rego 版本判断某个标识符是否为关键字注释还指出在 Rego v1 兼容模式rego.v1或future.keywords导入下future.keywords会并入默认关键字集无需显式导入。v1/ast/capabilities.go 中的Capabilities结构体携带FutureKeywords字段用于按能力capabilities过滤允许的关键字相关测试v1/ast/capabilities_test.go验证了将not宣传为未来关键字时解析器的行为。这意味着如果你在 OPA 服务端配置了限制版本的 capabilities未在当前版本能力集中声明的未来关键字可能无法使用而导入future.keywords.not则是让策略显式声明自己依赖改进语义的正确姿势。实践建议始终导入future.keywords.not只要使用not就显式import future.keywords.not以获得一致、符合直觉的否定语义避免传统展开方式下的静默失败。区分值不存在与不等于not p[foo]键不存在与p[_] ! foo存在但不等于语义不同按需选择。注意安全性约束否定表达式中的变量必须同时出现在规则内其他非否定等式中否则规则会被编译器拒绝。显式否定 body 用于多条件判定需要否定一组联合条件时用not { ... }包裹并注意赋值只能在 body 内部进行。结合 not 关键字官方文档 与 策略语言指南 中的完整示例你可以在自己的 OPA 策略中准确、安全地使用否定逻辑。赞分享后端认证鉴权云原生【免费下载链接】opaOpen Policy Agent (OPA) is an open source, general-purpose policy engine.项目地址https://gitcode.com/gh_mirrors/op/opa点击查看免费下载相关推荐使用 OPA 的 Rego 关键字 not 检测未定义值与实现策略否定使用 OPA 的 Rego 关键字 not 检测未定义值与实现策略否定 not 是 RegoOpen Policy Agent 的策略语言中表达否定与后端认证鉴权云原生Rego 中的 not 关键字Open Policy Agent 否定语义与实战指南Rego 中的 not 关键字Open Policy Agent 否定语义与实战指南 导读 not 是 RegoOpen Policy Agent 的策略语后端认证鉴权云原生OPA Rego 函数定义指南用 if 关键字增量定义 is_sudo 类函数OPA Rego 函数定义指南用 if 关键字增量定义 is_sudo 类函数 本文围绕 OPAOpen Policy AgentRego 语言中 if后端认证鉴权云原生创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
