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

Kibana is logging basic authorzation header #5329

Closed
jcollie opened this issue Nov 5, 2015 · 7 comments
Closed

Kibana is logging basic authorzation header #5329

jcollie opened this issue Nov 5, 2015 · 7 comments
Labels
bug Fixes for quality problems that affect the customer experience v4.2.1

Comments

@jcollie
Copy link

jcollie commented Nov 5, 2015

I'm reverse proxying Kibana behind nginx so that I can add SSL and basic authorization. Unless told otherwise, nginx will pass the authorzation header to Kibana, which will then log it. This can be avoided by telling nginx not to pass the authorization header (although in nginx there's a quirk in how the authorization header is handled which makes preventing the authorization header from being forwarded unintuitive). However, I think that Kibana should still avoid logging this header in case the person that configures the reverse proxy doesn't know to block that header.

@rashidkpc
Copy link
Contributor

What version? Pretty sure this is fix in 4.2?

// I'm adding the default here because if you add another filter
// using the commandline it will remove authorization. I want users
// to have to explicitly set --logging.filter.authorization=none to
// have it show up int he logs.
filter: _.defaults(config.get('logging.filter'), {
authorization: 'remove'
})

@jcollie
Copy link
Author

jcollie commented Nov 5, 2015

I'm using 4.2

@jcollie
Copy link
Author

jcollie commented Nov 5, 2015

I checked my copy of the code and that block is missing.

@jcollie
Copy link
Author

jcollie commented Nov 5, 2015

Looking at the history, it definitely appears that the patch that you mention did not make it into the 4.2.0 release. Around the time of 4.2.0-beta1 it looks like a 4.2 branch was created so patches applied to master after that didn't automatically make it into 4.2.

@jcollie
Copy link
Author

jcollie commented Nov 5, 2015

Looks like this is addressed in #5036 , unfortunately the patches didn't make it into 4.2.

@epixa epixa added bug Fixes for quality problems that affect the customer experience v4.2.1 and removed feedback_needed labels Nov 5, 2015
@rashidkpc
Copy link
Contributor

Totally correct, doh!

@epixa
Copy link
Contributor

epixa commented Nov 5, 2015

This fix is now backported, so it's ready for 4.2.1.

@epixa epixa closed this as completed Nov 5, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Fixes for quality problems that affect the customer experience v4.2.1
Projects
None yet
Development

No branches or pull requests

3 participants