[opa-envoy-plugin] Allowed key in response

[PietervdWerk]

Short description

In most examples using opa the allow key is used, as well as the documentation for the opa-envoy-plugin's Additional Control documentation. However, the plugin specifically looks for the allowed key instead:

if val, ok = decision["allowed"]; !ok {
	return false, fmt.Errorf("unable to determine evaluation result due to missing \"allowed\" key")
}

Expected behavior

The documentation shows a policy using the allow key which is generally used, I expected the plugin to look for the allow key.

Additional context

To make it backwards compatible I propose supporting the 'allow' and 'allowed' key.

[anderseknert]

Hi there @PietervdWerk 👋 Just in the next section there's an explanation for how to compose the output document (i.e. the response): https://www.openpolicyagent.org/docs/latest/envoy-primer/#output-document

To construct that output object using the policies demonstrated in the last section, you can use the following Rego snippet. Notice that we are using partial object rules so that any variables with undefined values simply have no key in the result object.

result["allowed"] := allow
result["headers"] := headers
result["response_headers_to_add"] := response_headers_to_add
result["request_headers_to_remove"] := request_headers_to_remove
result["body"] := body
result["http_status"] := status_code

[PietervdWerk]

Yes I understand, though I would love a way to configure this.

[stale]

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days. Although currently inactive, the issue could still be considered and actively worked on in the future. More details about the use-case this issue attempts to address, the value provided by completing it or possible solutions to resolve it would help to prioritize the issue.

[ashutosh-narkar]

Closing this as the docs cover the required fields in the output document and hence seems not much is needed here.