Provide headers in input to authorization policy

[tsandall]

Currently the HTTP server does not provide the HTTP headers of incoming requests to the authorization policy. If users want to inspect custom headers to control access to OPA itself, they cannot. We can extend OPA to expose the headers to the policy as a map of string arrays.

[phil-lee-kb]

Hi there @tsandall. I've seen a few questions around how to access the http headers from an OPA policy rego and came upon this thread. I had thought that I might be able to access the incoming http headers via input.headers, or input.request.headers in my own custom policies, but am I right in thinking that the headers are actually only available to the system.authz policy? Whereas if I write my own policy e.g. phil.rego, if I want it to have access to the http headers, the consumer has to provide them as part of the input object? There are other references to an envoy plugin, but I'm presuming that's doing some sort of proxying where it takes the actually http headers and adds them to the input object then forwards onto OPA? Thanks in advance

[anderseknert]

@phil-lee-kb that's correct — you'll need to provide any data required for evaluation as part of the request body. Remember that running as a server is only one of many ways OPA may operate, and having headers included in the input would couple your policy to a single mode of operation (opa run --server). Other evaluation contexts where headers aren't available include (but probably not limited to):

• opa eval
• opa exec
• opa test (although headers could probably be mocked here)
• opa run (REPL)
• opa bench
• Tools like IDEs, editors, the Rego Playground, etc

Having the client add relevant data to the body might be a bit of a burden, but the upside is that your policy isn't coupled to any specific evaluation context, and may run in any of the above.

[phil-lee-kb]

@phil-lee-kb that's correct — you'll need to provide any data required for evaluation as part of the request body. Remember that running as a server is only one of many ways OPA may operate, and having headers included in the input would couple your policy to a single mode of operation (opa run --server). Other evaluation contexts where headers aren't available include (but probably not limited to):

• opa eval
• opa exec
• opa test (although headers could probably be mocked here)
• opa run (REPL)
• opa bench
• Tools like IDEs, editors, the Rego Playground, etc

Having the client add relevant data to the body might be a bit of a burden, but the upside is that your policy isn't coupled to any specific evaluation context, and may run in any of the above.

Thank you @anderseknert 😄 When you put it in that context, it makes perfect sense that the headers aren't available. And also makes for a consistent experience across things like the rego playground and when running OPA itself