You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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"
}
The text was updated successfully, but these errors were encountered:
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.
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.
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:
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 thesystem.log
package as it is already in thesystem.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:The text was updated successfully, but these errors were encountered: