Reporting should work with `server.ssl.clientAuthentication` set to `required`

[azasypkin]

In https://github.com/elastic/kibana/pull/43090 we're introducing server.ssl.clientAuthentication: {required|optional|none} and in https://github.com/elastic/kibana/pull/42606 we're adding PKI authentication provider. The way reporting works currently won't affected by none or optional modes, but to support required mode headless Chrome browser will have to provide a client certificate signed by CA that is trusted by Kibana, but not Elasticsearch. This way Chromium can successfully query Kibana, but won't be able to create an access token with PKI realm.

To solve this we can potentially introduce two new reporting settings: xpack.reporting.capture.browser.*.ssl.cert and xpack.reporting.capture.browser.*.ssl.key and either set these values automatically using the pre-generated self-signed reporting-only certificate distributed with Kibana or allow administrators to provide their own certificate in case it needs to comply with any internal policy they may have.

Some helpful links:

• https://www.chromium.org/administrators/policy-list-3#AutoSelectCertificateForUrls
• https://github.com/GoogleChrome/puppeteer/issues/1319#issuecomment-371503788

[elasticmachine]

Pinging @elastic/kibana-security

[elasticmachine]

Pinging @elastic/kibana-stack-services

[tsullivan]

The way reporting works currently won't affected by none or optional modes

Just to be clear, is this a reference to how we use Puppeteer to launch the Chromium process with ignoreHTTPSErrors: true https://github.com/elastic/kibana/blob/7.x/x-pack/legacy/plugins/reporting/server/browsers/chromium/driver_factory/index.ts#L113 ?

To solve this we can potentially introduce two new reporting settings: xpack.reporting.capture.browser..ssl.cert and xpack.reporting.capture.browser..ssl.key and either set these values automatically using the pre-generated self-signed reporting-only certificate distributed with Kibana

I think that suggestion is good: the automatic aspect would make sense when headless Chromium is talking directly to Kibana.

NOTE: Currently, when there is a proxy in front of Kibana that does not recognize the Kibana SSL certificate, there exists the problem of ignoreHTTPSErrors: true not being sufficient to get Reporting to work, because proxies act like a client, but do not ignore HTTPS errors.

I'm trying to think of how it would impact traffic when there is a proxy in front of Kibana, which Reporting must go through. A proxy can have responsibility in making requests work sometimes, for example: URL rewriting.

Adding xpack.reporting.capture.browser.*.ssl.cert and xpack.reporting.capture.browser.*.ssl.key seems like it would reduce (or solve?) the problem of proxies blocking untrusted HTTPS traffic. It would allow proxies to be configured with the same certificate as Kibana Reporting.

@azasypkin Can you confirm that?

[azasypkin]

Just to be clear, is this a reference to how we use Puppeteer to launch the Chromium process with ignoreHTTPSErrors: true https://github.com/elastic/kibana/blob/7.x/x-pack/legacy/plugins/reporting/server/browsers/chromium/driver_factory/index.ts#L113 ?

That's too, but I was mostly referring to the fact that with server.ssl.clientAuthentication: {none|optional} Kibana server won't require client certificate from Puppeteer that it can't provide currently.

NOTE: Currently, when there is a proxy in front of Kibana that does not recognize the Kibana SSL certificate, there exists the problem of ignoreHTTPSErrors: true not being sufficient to get Reporting to work, because proxies act like a client, but do not ignore HTTPS errors.

It's orthogonal issue, but just curious, can't such proxies just include Kibana server certificate authority into the list of trusted authorities?

Adding xpack.reporting.capture.browser..ssl.cert and xpack.reporting.capture.browser..ssl.key seems like it would reduce (or solve?) the problem of proxies blocking untrusted HTTPS traffic. It would allow proxies to be configured with the same certificate as Kibana Reporting.

Hmm, it looks like we're mixing two types of TLS authentication here, sorry for the confusion! The proposed browser..ssl.cert and browser..ssl.key will be used for client (Puppeteer) TLS authentication to Kibana server (to support case with xpack.security.authc.providers: [pki] + server.ssl.clientAuthentication: required). That means it won't work with TLS terminating proxies since Kibana won't have direct access to the client certificate, but that's another story.

[elasticmachine]

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

[elasticmachine]

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

[ppisljar]

Thank you for contributing to this issue, however, we are closing this issue due to inactivity as part of a backlog grooming effort. If you believe this feature/bug should still be considered, please reopen with a comment.

[azasypkin]

I believe this issue should be fixed, especially since we're going to add PKI support in Elastic Cloud soon.

[tsullivan]

I believe this issue should be fixed, especially since we're going to add PKI support in Elastic Cloud soon.

Hi @azasypkin can we change the labels to the Kibana Security team? App Services has little context on this issue, and as you see we were not able to move forward with this issue in the last 3 years.

[azasypkin]

Hi @azasypkin can we change the labels to the Kibana Security team? App Services has little context on this issue, and as you see we were not able to move forward with this issue in the last 3 years.

The way how reporting is currently implemented in Kibana implies that the fix for this issue will most likely be done within Reporting plugin, so it makes sense to keep Team: App Services label. But I also added Team: Security label to give you the context you're missing, assist with the planning and the fix itself once you're ready pick it up.

Is there any issue with keeping this one open even if it doesn't have a high priority at the moment? Having an open issue for the valid Kibana bug increases discoverability among our users and support team whenever they hit this issue.

[tsullivan]

Ok, the part about this being a specific issue due to the way reporting launches Chromium makes sense. I browsed to the top of the issue and was reminded about this part you wrote as well:

to support required mode headless Chrome browser will have to provide a client certificate signed by CA that is trusted by Kibana

I don't see an issue with keeping this particular issue open as we wait for a go-ahead from the security team.

Thank you for the refresher!