Skip to content

fix(deps): update module github.com/open-policy-agent/opa to v1.20.0 (9.4) - #8220

Open
elastic-renovate-prod[bot] wants to merge 1 commit into
9.4from
renovate/9.4-github.com-open-policy-agent-opa-1.x
Open

fix(deps): update module github.com/open-policy-agent/opa to v1.20.0 (9.4)#8220
elastic-renovate-prod[bot] wants to merge 1 commit into
9.4from
renovate/9.4-github.com-open-policy-agent-opa-1.x

Conversation

@elastic-renovate-prod

@elastic-renovate-prod elastic-renovate-prod Bot commented Aug 28, 2026

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
github.com/open-policy-agent/opa v1.19.1v1.20.0 age confidence

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.


Release Notes

open-policy-agent/opa (github.com/open-policy-agent/opa)

v1.20.0

Compare Source

This release contains a mix of new features and bug fixes. Notably:

  • New Rego keywords: and and or, for combining conditions inside a single rule body
  • allow_net now restricts remote JSON Schema $ref fetching from json.match_schema and json.verify_schema
  • Coverage reports can now explain why a range is not covered
  • Much faster partial evaluation for dynamically composed policies
New Rego keywords: and and or (#​7602)

Rego gains two keywords for combining conditions inside a single rule body — a long-standing
request, and one of the larger additions to the language in some time. and and or let control
flow that previously had to be split across helper rules stay where it is read.

Before, a rule body that needed to succeed on one of several conditions meant extracting a rule:

package example

allow if {
	input.method == "GET"
	admin_or_public_owner
}

admin_or_public_owner if input.user.admin

admin_or_public_owner if {
	input.user.owner
	input.resource.public
}

Now:

package example

import future.keywords.and
import future.keywords.or

# the and groups first, so this reads as:

# an admin, or an owner of a public resource
allow if {
	input.method == "GET"
	input.user.admin or input.user.owner and input.resource.public
}

Both keywords are opt-in future keywords:
import future.keywords.and, import future.keywords.or, or import future.keywords for both.

An and/or expression either succeeds or fails; it never produces a value. So you can't assign
one to a variable, pass one to a function, or use one as the head of a comprehension.

Operands can read variables from the rule body around them, but can't create new ones for the rest
of the rule to use — wrap an operand in braces to give it a body of its own, and any variables it
creates stay inside those braces. Only as much is evaluated as needed: if the left side settles the
outcome, the right side is skipped. And when both sides of an or succeed, you still get a single
result; evaluation doesn't split in two.

Further reading:

Try the new keywords in the Rego Playground, or in your
editor with the VS Code extension
or the IntelliJ IDEA plugin — see
Editor and IDE Support for others.

Authored by @​johanfylling

Behavior change: allow_net applies to remote JSON Schema $refs (#​8979)

The allow_net
capability restricts which hosts remote JSON Schema $refs may be fetched from, but it was only
wired up on the compile-time type-checking path. Policies using neither -s schemas nor
# METADATA schemas:
annotations never reached it, and an unset allowlist permitted every host — so
json.match_schema
and json.verify_schema,
which compile schemas at evaluation time, fetched $refs from anywhere. Their schema argument can
come from input, so the host was not necessarily under the policy author's control.

The allowlist now travels with the schema loader and is checked per caller at any nesting depth.
Every redirect hop is checked too, matching http.send, and the inter-query cache key includes the
allowlist so a permissive caller cannot populate the cache for a restrictive one.

Authored by @​sspaink, reported by @​charlesdaniels

Coverage reports explain why a range is not covered (#​8937)

Coverage reports showed that a
range was uncovered, but not why: ranges skipped by rule indexing
or early exit looked identical to dead code.

Not-covered ranges are now tagged with a Kindindex_excluded or early_exit — determined
by re-evaluating with each optimization disabled and diffing the extra coverage data. Both
supplementary passes run by default when --coverage is set; the new --coverage-runs flag on
opa eval and opa test selects which of them to run, and an empty list disables them.

Authored by @​charlieegan3

Runtime, SDK, Tooling
Compiler, Topdown and Rego
Docs, Website, Ecosystem
Miscellaneous

Configuration

📅 Schedule: Branch creation - Between 01:00 AM and 01:59 AM, Monday through Friday ( * 1 * * 1-5 ) (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

@elastic-renovate-prod
elastic-renovate-prod Bot force-pushed the renovate/9.4-github.com-open-policy-agent-opa-1.x branch from a6e3a28 to 14b5aba Compare August 29, 2026 18:50
@elastic-renovate-prod elastic-renovate-prod Bot changed the title fix(deps): update module github.com/open-policy-agent/opa to v1.20.1 (9.4) fix(deps): update module github.com/open-policy-agent/opa to v1.20.0 (9.4) Aug 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants