-
Notifications
You must be signed in to change notification settings - Fork 360
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
Remote audit log #242
Comments
That's a good idea - however, I do not believe that this should be anything custom. It will be much easier to use e.g. logstash or any other log pipeline to extract this information in a scalable and also much more reliable way. An alternative would be to improve the prometheus integration and provide this information. However, prometheus is not intended for long-term storage. |
That's a fair point. Shouldn't be that hard to pipe the stdout of oathkeeper to fluentbit or logstash. What then happens with the logs is of no interest to oathkeeper. Prometheus could be an alternative to track aggregate metrics like "total number of granted access requests" or "total number of denied access requests". Having the subject in there would likly add too much cardinality which is hard for Prometheus to handle. So it sounds like the way to create an audit log would be to use the logger that is already present. |
Yeah absolutely! I think we should have the same capability for the proxy mode as well :) |
I've been playing around with oathkeeper to secure an API gateway. It has been going pretty well so far!
One thing that I am missing is a kind of audit log that stores the decisions oathkeeper has made.
I am interested in the following attributes of a request:
The messages that are currently written to stdout provide only some of this information. Even if all information would be present, searching through data and extracting it for other uses from a general-purpose logging system typically requires quite some work, e.g. parsing the raw log format.
I would therefore like to see the log being sent to an endpoint as a well-known struct via HTTP.
I could create a minimal implementation but first wanted to check if there's interest in such a feature.
The text was updated successfully, but these errors were encountered: