Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make http headers available in the decision-log #6693

Closed
stiidk opened this issue Apr 12, 2024 · 4 comments · Fixed by #6750
Closed

Make http headers available in the decision-log #6693

stiidk opened this issue Apr 12, 2024 · 4 comments · Fixed by #6750
Assignees

Comments

@stiidk
Copy link

stiidk commented Apr 12, 2024

In our OPA/Styra setup, we already uses system.log to mask sensitive input, and enrich the decision-log e.g. by adding the decoded jwt to the input next to the encoded-jwt.

What is the underlying problem you're trying to solve?

We would like to make additional enriching of our decision-log, by adding certain attributes/claims that is available in the http header.

Describe the ideal solution

The ideal solution would be that input.headers was available in the system.log package as it is already in the system.authz package.

Describe a "Good Enough" solution

Some other way just to enable all http headers to be added to decision-log.

Additional Context

As mentioned above we can in the system.authz package create a rule checking for certain http headers:

test_in_headers if {	
	some header_name,_ in input.headers
	lower(header_name) == "test"
}
@ashutosh-narkar
Copy link
Member

Having headers as part of the input to the system.authz policy makes sense as the policy's purpose is to authorize an incoming HTTP request received by OPA. The system.log package works on anything provided in the input. It's not tied to any particular domain. So one way to provide headers to the log policy would be to make the headers part of OPA's input.

@stiidk
Copy link
Author

stiidk commented Apr 15, 2024

Hi @ashutosh-narkar
If it make sense to be able to authorize an incoming HTTP request(including headers), it would - to me at least - also make sense to be able to log the headers, without having teams using OPA provide extra input.

@ashutosh-narkar
Copy link
Member

Ok. Here's a proposal. We'll extend the decision log config to allow users to specify the headers they want to include in the log. It will look something like:

decision_logs:
  request_context:
    http:
      headers: ["x-foo", "x-bar"]

Then the log will look something like:

"request_context": {
    "http": {
       "headers": {
            "x-foo": "baz",
            "x-bar": "faz"
        }
    }
}

WDYT?

@stiidk
Copy link
Author

stiidk commented Apr 16, 2024

Hi. Thanks for the quick feedback. That is a fine solution for us 👍

@ashutosh-narkar ashutosh-narkar self-assigned this Apr 16, 2024
ashutosh-narkar added a commit to ashutosh-narkar/opa that referenced this issue May 16, 2024
It would be useful if users had the ability to enhance the
decision log with info from the incoming HTTP request such as
headers. This change allows users to configure headers whose
values if present in the incoming HTTP request would be
surfaced via the decision log. This can be extended in the
future to include more context from the request.

Fixes: open-policy-agent#6693

Signed-off-by: Ashutosh Narkar <[email protected]>
ashutosh-narkar added a commit to ashutosh-narkar/opa that referenced this issue May 17, 2024
It would be useful if users had the ability to enhance the
decision log with info from the incoming HTTP request such as
headers. This change allows users to configure headers whose
values if present in the incoming HTTP request would be
surfaced via the decision log. This can be extended in the
future to include more context from the request.

Fixes: open-policy-agent#6693

Signed-off-by: Ashutosh Narkar <[email protected]>
ashutosh-narkar added a commit that referenced this issue May 20, 2024
It would be useful if users had the ability to enhance the
decision log with info from the incoming HTTP request such as
headers. This change allows users to configure headers whose
values if present in the incoming HTTP request would be
surfaced via the decision log. This can be extended in the
future to include more context from the request.

Fixes: #6693

Signed-off-by: Ashutosh Narkar <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants