search

fermitools / htvault-config

Configure a Hashicorp Vault server for use with htgettoken
Other
6 stars 2 forks source link

Feature request: log traffic between Vault and token issuer #42

Open DrDaveD opened 11 months ago

DrDaveD commented 11 months ago

The auditlog keeps all the traffic between vault and its client, but we have no similar log for traffic between vault and the token issuer. This makes problems very difficult to debug. The majority of traffic exchanged with the token issuer is with the Puppetlabs vault-plugin-secrets-oauthapp, but there is also traffic through the Hashicorp vault-plugin-auth-jwt and ideally there would be a mechanism for both.

DrDaveD commented 11 months ago

I'm guessing that we would want to base it on the go-hclog package.

DrDaveD commented 10 months ago

Or possibly it could just go through an https proxy that logs all the traffic.

cipherboy commented 3 months ago

Not to go digging into your issues @DrDaveD.... but what do you think about an external audit capability? Currently audit logs exist at the request level because audits are generated by the Core http package.

However, via backend.System(), we could expose an Audit(...) method, which could expose similar capabilities to plugins: they could audit their own (outbound) request/responses or generate non-request audit log messages of their own (perhaps if some non-request-bound operation occurred that warranted audit logging). This would need new types associated with it, to differentiate it from Core messages, but potentially on top, we could build a common HTTP client as well and suggest plugins use that (which would have automatic audit logging).

I think part of the issue with the latter would be scope of audit message obfuscation (hmac) -- we'd probably need new mount tunable options to do so.

This would also be useful upstream for anyone building a KMIP plugin as that speaks a binary wire protocol and thus can't go through the Core router, requiring them to listen on another port. So I could see it being generally useful.

Just a thought!

DrDaveD commented 2 months ago

That sounds like a great idea to me.

I didn't note it here but I have since that time successfully got a test proxy configuration working using mitmproxy. I think the performance of that would not be sufficient for production use and I was thinking of trying to redo it with nginx or varnish, but a builtin framework option would be much better.