search

elastic / kibana

Your window into the Elastic Stack
https://www.elastic.co/products/kibana
Other
19.77k stars 8.17k forks source link

Reporting should work with token based authentication #71866

Open azasypkin opened 4 years ago

azasypkin commented 4 years ago

Currently Reporting plugin remembers HTTP headers of the authenticated user request to generate reports on behalf of that user.

The header that is responsible for the authentication is Authorization. When Kibana is using any of the token based authentication mechanisms (SAML/OpenID Connect/Kerberos/PKI/Token basic auth) Authorization header includes access token. This token is valid for 20m by default with a maximum validity time of 1h and there is no easy way to refresh it during report generation.

That means that if report generation takes time access token may expire and report generation will fail.

The proposed solution is to use dedicated API key instead of remembering Authorization header, but API keys support requires TLS between Kibana and Elasticsearch that we cannot enforce by default for the time being.

elasticmachine commented 4 years ago

Pinging @elastic/kibana-security (Team:Security)

elasticmachine commented 4 years ago

Pinging @elastic/kibana-reporting-services (Team:Reporting Services)

bczifra commented 4 years ago

@azasypkin i don't see the problem explicitly noted here. is it that the token expires before the report generation completes, so the report generation fails?

azasypkin commented 4 years ago

@azasypkin i don't see the problem explicitly noted here. is it that the token expires before the report generation completes, so the report generation fails?

Yeah, sorry, that's correct. I've updated issue description to make it clear.

tsullivan commented 4 years ago

One issue that has come up is that Reporting looks at the roles of the user in the request before it allows a report to be queued.

If token based authentication works the same as API Keys, the list of roles will come up empty. That falls into this bug: https://github.com/elastic/kibana/issues/76210

This token is valid for 20m by default

It's a bit unlikely that anyone would accept a report to take this long to generate. The default timeout time is 2 minutes, and there are 2 retries available by default. The max time allowed by default then is 6 minutes, plus time in between for the job to be re-claimed. And that's only if the report fails twice and then succeeds on the 3rd try.

Users can increase that timeout in kibana.yml, but I really don't think timeouts go that high. There are other options available to make it run faster, like run multiple reports with smaller timerange instead of a single report. Also, setting up API Keys seems to be a perfectly acceptable workaround in this rare of a use case.

I don't think there is a real issue here, but if something does come up then we can triage it at the time, taking into account the use case.

azasypkin commented 4 years ago

One issue that has come up is that Reporting looks at the roles of the user in the request before it allows a report to be queued. If token based authentication works the same as API Keys, the list of roles will come up empty. That falls into this bug: #76210

Nope, tokens are different, you'll be able to retrieve roles when you authenticate with Elasticsearch access tokens, but it doesn't seem to be relevant to this issue anyway. Let me re-open the issue and explain why I think we still need to tackle it as soon as we can:

It's a bit unlikely that anyone would accept a report to take this long to generate. The default timeout time is 2 minutes, and there are 2 retries available by default. The max time allowed by default then is 6 minutes, plus time in between for the job to be re-claimed. And that's only if the report fails twice and then succeeds on the 3rd try.

It doesn't really matter how long it takes to generate report, the only thing that matters here is that there is a high chance that Reporting will reuse access token after it initially "captured" it (e.g. when you make a retry). It's perfectly possible that user wants to generate report when access token is about to expire. By default token is valid for 20m starting from the moment it was created or refreshed, not from the moment when Reporting "captures" it.

This issue with Reporting will become much more apparent when we start using token based authentication by default. Technically Cloud/ESS already started to endorse SSO (SAML) as a default way to log in to Kibana.

Another important reason to change the way you leverage authentication in Reporting is that we really want to stop exposing raw user credentials to plugins via Authorization header, especially for basic authentication since it includes username/password that don't "expire" automatically.

What do you think?

tsullivan commented 4 years ago

Thanks for the explanation @azasypkin . I didn't understand the full picture before.

I see that we have to keep this issue open to come up with some kind of plan on making sure Reporting keeps working when token auth is the default.

elasticmachine commented 3 years ago

Pinging @elastic/kibana-app-services (Team:AppServices)

legrego commented 3 years ago

The proposed solution is to use dedicated API key instead of remembering Authorization header, but API keys support requires TLS between Kibana and Elasticsearch that we cannot enforce by default for the time being.

I believe this is no longer blocked by ES. API Keys can be enabled even if HTTPS is disabled (https://github.com/elastic/elasticsearch/pull/76801). It's worth noting that API Keys can still be disabled within ES, so we will still need to account for this scenario.