build(deps): bump github.com/open-policy-agent/opa from 0.28.0 to 0.52.0 in /services/gateway

[dependabot[bot]]

Bumps github.com/open-policy-agent/opa from 0.28.0 to 0.52.0.

Release notes

Sourced from github.com/open-policy-agent/opa's releases.

v0.52.0

This release contains some enhancements, bugfixes, and a new builtin function.

Allow Adding Labels via Discovery

Previously OPA did not allow any updates to the labels provided in the boot configuration via the discovered (ie. service) config. This was done to avoid breaking the discovery configuration. But there are use cases where labels can serve as a convenient way to pass information that could be used in policies, status updates or decision logs. This change allows additional labels to be configured in the service config which are then made available during runtime.

See the Discovery documentation for more details.

Authored by @​mjungsbluth.

New Built-In Function: crypto.hmac.equal

crypto.hmac.equal provides a convenient way to compare hashes generated by the MD5, SHA-1, SHA-256 and SHA-512 hashing algorithms.

Below is a real world example of how this built-in function can be utilized. Imagine our server is registered as a GitHub webhook which subscribes to certain events on GitHub.com. Now we want to limit requests to those coming from GitHub. One of the ways to do that is to first set up a secret token and validate the information. Once we create the token on GitHub, we'll set up an environment variable that stores this token and makes it available to OPA via the opa.runtime built-in. In the case of GitHub webhooks the validation is done by comparing the hash signature received in the X-Hub-Signature-256 header and calculating a hash using the secret token and payload body. The check_signature rule implements this logic.

package example
import input.attributes.request.http as http_request
allow {
http_request.method == "POST"
input.parsed_path = ["workflows", "github", "webhooks"]
check_signature
}
check_signature {
secret_key := opa.runtime().env.GITHUB_SECRET_KEY
hash_body := crypto.hmac.sha256(http_request.raw_body, secret_key)
expected_signature := concat("", ["sha256=", hash_body])
header_signature = http_request.headers["X-Hub-Signature-256"]
crypto.hmac.equal(header_signature, expected_signature)
}

See the documentation on the new built-in for all the details.

Authored by @​sandokandias.

Extend Authentication Methods Supported by OCI Downloader

... (truncated)

Changelog

Sourced from github.com/open-policy-agent/opa's changelog.

0.52.0

This release contains some enhancements, bugfixes, and a new builtin function.

Allow Adding Labels via Discovery

Previously OPA did not allow any updates to the labels provided in the boot configuration via the discovered (ie. service) config. This was done to avoid breaking the discovery configuration. But there are use cases where labels can serve as a convenient way to pass information that could be used in policies, status updates or decision logs. This change allows additional labels to be configured in the service config which are then made available during runtime.

See the Discovery documentation for more details.

Authored by @​mjungsbluth.

New Built-In Function: crypto.hmac.equal

crypto.hmac.equal provides a convenient way to compare hashes generated by the MD5, SHA-1, SHA-256 and SHA-512 hashing algorithms.

Below is a real world example of how this built-in function can be utilized. Imagine our server is registered as a GitHub webhook which subscribes to certain events on GitHub.com. Now we want to limit requests to those coming from GitHub. One of the ways to do that is to first set up a secret token and validate the information. Once we create the token on GitHub, we'll set up an environment variable that stores this token and makes it available to OPA via the opa.runtime built-in. In the case of GitHub webhooks the validation is done by comparing the hash signature received in the X-Hub-Signature-256 header and calculating a hash using the secret token and payload body. The check_signature rule implements this logic.

package example
import input.attributes.request.http as http_request
allow {
http_request.method == "POST"
input.parsed_path = ["workflows", "github", "webhooks"]
check_signature
}
check_signature {
secret_key := opa.runtime().env.GITHUB_SECRET_KEY
hash_body := crypto.hmac.sha256(http_request.raw_body, secret_key)
expected_signature := concat("", ["sha256=", hash_body])
header_signature = http_request.headers["X-Hub-Signature-256"]
crypto.hmac.equal(header_signature, expected_signature)
}

See the documentation on the new built-in for all the details.

... (truncated)

Commits

• 8d2c137 Prepare v0.52.0 release
• f2c8474 docs: mention ID property of sdk.Options and its benefits (#5876)
• b65c68e Add ability to load bundles from an arbitrary filesystem
• 1ec047c ast: Set result of groundness check on indexer's AllRules func
• b626a2c Use existing auth plugins with OCIDownloader
• 85fbad5 docs: Add Nondeterministic field to func decl
• 3311587 ast: Disallowing partial object rules to have other partial object rule withi...
• f4af919 planner: fix bug in call_dynamic with overlapping ref rules
• 0be7f35 ast: Not allowing multi-value rules to have other rules in their extent
• 8e48167 Clarify use cases for Compile API
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot[bot]]

Superseded by #2063.