[PR] Update openpolicyagent/opa Docker tag to v1.21.3 [polaris]

["renovate-bot (via GitHub)" <gi...@apache.org>]

renovate-bot opened a new pull request, #5831:
URL: https://github.com/apache/polaris/pull/5831

   This PR contains the following updates:
   
   | Package | Update | Change |
   |---|---|---|
   | [openpolicyagent/opa](https://images.chainguard.dev/directory/image/static/overview) ([source](https://redirect.github.com/open-policy-agent/opa)) | patch | `1.21.1` → `1.21.3` |
   
   ---
   
   ### Release Notes
   
   <details>
   <summary>open-policy-agent/opa (openpolicyagent/opa)</summary>
   
   ### [`v1.21.3`](https://redirect.github.com/open-policy-agent/opa/blob/HEAD/CHANGELOG.md#1213)
   
   [Compare Source](https://redirect.github.com/open-policy-agent/opa/compare/v1.21.2...v1.21.3)
   
   ##### Security Fix: TODO-CVE-XXXX-XXXXX - Bundle signature verification could be side-stepped ([GHSA-g2pf-6v5v-qcc8](https://redirect.github.com/open-policy-agent/opa/security/advisories/GHSA-g2pf-6v5v-qcc8))
   
   An attacker able to alter bundle bytes could supply arbitrary policy and data to an OPA that was [configured](https://www.openpolicyagent.org/docs/configuration#bundles)
   to verify bundle signatures. This could happen if the attacker controls any of:
   
   - OPA bundle/discovery service (including an artifact store it uses)
   - MitM between OPA and bundle/discovery service
   - write access to a file:// bundle path or the bundle persistence directory
   
   Two separate side-steps are fixed:
   
   ##### Issue 1. Signature verification keyed on `keyid` rather than on the `signing` block
   
   OPA only required a `.signatures.json` file when `signing.keyid` was set, so a bundle stripped of its signature was
   accepted if only e.g. `bundles[_].signing` was set instead of `bundles[_].signing.keyid`. Verification now depends on
   the presence of a `signing` block, as documented; `keyid` only selects which key to use.
   
   **Affected:**
   
   - `bundles[_].signing` or `discovery.signing` configured without `keyid`: an empty block, or one with only `scope` or
     `exclude_files`.
   - Embedders (SDK, custom plugins, `v1/loader`, `v1/compile`) calling `bundle.NewVerificationConfig(keys, "", ...)` with
     an empty key id.
   
   **Not affected:**
   
   - Configurations with an explicit `bundles[_].signing.keyid` or `discovery.signing.keyid`.
   - `opa run`/`opa eval`/`opa build` with `--verification-key`, which defaults `--verification-key-id` to `default`.
     Passing `--verification-key-id ""` explicitly was affected.
   - Configurations with top-level `keys` but no `signing` block: not a verification opt-in before or after this fix.
     Unsigned bundles are still accepted, and OPA now logs a warning at startup for bundles in this state.
   
   **Workaround:** on affected versions, set an explicit `keyid` on every bundle that must be signed:
   
   ```yaml
   bundles:
     authz:
       service: acmecorp
       resource: bundle.tar.gz
       signing:
         keyid: my_key # must name an entry under the top-level `keys`
   discovery:
     resource: /discovery.tar.gz
     signing:
       keyid: my_discovery_key
   
   keys:
     my_key:
       algorithm: RS256
       key: |
         -----BEGIN PUBLIC KEY-----
         ...
   ```
   
   Further behaviour changes:
   
   - A `signing` block with no entries under the top-level `keys` is now a startup configuration error, rather than a
     configuration that rejects every signed bundle while accepting unsigned ones.
   - `bundle.NewVerificationConfig` now requires signatures by default. Embedders can opt out with
     `WithSkipBundleVerification(true)` or the new `(*VerificationConfig).WithOptionalSignature()`.
   
   ##### Issue 2. Unsigned *delta* bundle downgrade
   
   *Delta* bundles skipped verification entirely, so an attacker could replace a signed *snapshot* bundle with an unsigned
   *delta* bundle on the same resource. The signed policy stays active while the attacker controls any data inside the
   bundle's roots. *Delta* bundles [not supporting signing](https://www.openpolicyagent.org/docs/management-bundles#current-limitations)
   was documented, but unenforced. OPA now rejects them with `delta bundles do not support signature verification`.
   
   **Affected:**
   
   - Any bundle or discovery configuration with a `signing` block, with or without `keyid`.
   - `opa run`/`opa eval` with `--verification-key`.
   
   **Not affected:**
   
   - Configurations that don't verify signatures: no `signing` block, or `--skip-verify`. Nothing was verified to begin
     with.
   
   **Workaround:** there is no configuration that makes affected versions reject *delta* bundles. Until upgrading, ensure
   the integrity of the bundle bytes themselves: TLS terminated by OPA or a trusted hop, restricted write access to the
   bundle service, artifact store and bundle persistence directory.
   
   Bundle services that must keep serving unsigned *delta* bundles after upgrading can opt out per bundle with the new
   `bundles[_].signing.allow_unsigned_delta_bundles` (or `discovery.signing.allow_unsigned_delta_bundles`) field.
   *Snapshot* bundles must still be signed.
   
   Reported by Brian Willows ([@&#8203;BrianWillows](https://redirect.github.com/BrianWillows), Graith Internet, graith.co.uk), authored by [@&#8203;johanfylling](https://redirect.github.com/johanfylling).
   
   ### [`v1.21.2`](https://redirect.github.com/open-policy-agent/opa/blob/HEAD/CHANGELOG.md#1212)
   
   [Compare Source](https://redirect.github.com/open-policy-agent/opa/compare/v1.21.1...v1.21.2)
   
   This release builds the OPA binary artifacts with the latest version of
   Go (v1.27.2), its standard library, and the golang.org/x/net dependency (v0.60.0).
   
   See these security advisories:
   
   - <https://groups.google.com/g/golang-announce/c/U2fTuyDJznI>
   - <https://groups.google.com/g/golang-announce/c/ZPwCyRUuGBs>
   
   Furthermore, it addresses a mismatch in how encoded slashes were handled
   in the input to a basic authorization policy and the Data API
   ([#&#8203;9323](https://redirect.github.com/open-policy-agent/opa/issues/9323), reported by [@&#8203;abhishekkushwaha4u](https://redirect.github.com/abhishekkushwaha4u), fixed by [@&#8203;sspaink](https://redirect.github.com/sspaink)).
   
   </details>
   
   ---
   
   ### Configuration
   
   📅 **Schedule**: (UTC)
   
   - Branch creation
     - At any time (no schedule defined)
   - Automerge
     - At any time (no schedule defined)
   
   🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
   
   ♻ **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.
   
   ---
   
    - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
   
   ---
   
   This PR was generated by [Mend Renovate](https://mend.io/renovate/). View the [repository job log](https://developer.mend.io/github/apache/polaris).
   <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0NC4xNzEuMiIsInVwZGF0ZWRJblZlciI6IjQ0LjE3MS4yIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJyZW5vdmF0ZS1wb2xhcmlzIl19-->
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Update openpolicyagent/opa Docker tag to v1.21.3 [polaris]

["snazy (via GitHub)" <gi...@apache.org>]

snazy merged PR #5831:
URL: https://github.com/apache/polaris/pull/5831


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org