Redact custom headers from audit logging

[stephen-crawford]

Is your feature request related to a problem?

Right now you can specify a custom jwt_header in config.yml when dictating JWT settings. This allows you to replace the default Authorization header with an alternative header such as My_header. You then use this custom header to pass your JWT in your requests so instead of Authorization: Bearer 1234567 you provide My_header: Bearer 123456.

Another feature offered by the security plugin is audit logging. Audit logging also has a setting which allows you to redact or remove sensitive Transport and REST headers. One of the sensitive REST headers is the Authorization header that is associated with JWT use. Currently this setting is not able to account for custom headers provided in the JWT configuration. The audit log then shows the JWT used for requests because it logs the request headers not matching Authorization.

Because of this, it is NOT RECOMMENDED to use both custom headers and audit logging.

Changes should be made to support use of audit logs and custom headers.

What alternatives have you considered?
Leaving as is and filing a documentation issue (already done).

[stephen-crawford]

I am just going to add a new category to audit log configuration to let you specify custom headers you want to redact. Passing information around from the HTTPAuthenticators is messy in my opinion and there may be edge cases for redacting custom headers from Audit logs outside of the JWT instance discussed here.

[peternied]

Do you know why do we support changing the header? Its part of the http standard that authorization goes into the authorization header. If this header value is changed many different parts systems will log incorrectly, poorly handle, or even reject requests like this.

Put differently, if someone asked for a feature to allow changing this header value, I'd want a really really compelling reason before I'd consider accepting it.

[stephen-crawford]

Hi @peternied, to be honest, I have no idea. I believe it is meant for people who have forwarding from other services to OpenSearch? I think that is what @davidlago had mentioned in the past... But I agree it is not necessarily the most common use case and seems like something that we probably would not add if suggested now