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

PKI Authentication support for Kibana #6119

Closed
msimos opened this issue Feb 4, 2016 · 13 comments
Closed

PKI Authentication support for Kibana #6119

msimos opened this issue Feb 4, 2016 · 13 comments
Labels
bug Fixes for quality problems that affect the customer experience Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc

Comments

@msimos
Copy link

msimos commented Feb 4, 2016

If I try to use PKI authentication for the kibana4 server user by using this configuration in the kibana.yml:

elasticsearch.url: "https://node01:9200"
elasticsearch.ssl.cert: /home/msimos/kibana-4.3.1-linux-x64/config/my.crt
elasticsearch.ssl.key: /home/msimos/kibana-4.3.1-linux-x64/config/my.key
elasticsearch.ssl.ca: /home/msimos/kibana-4.3.1-linux-x64/config/cacert.pem

On the Elasticsearch side, I have setup PKI authentication for the DN in the certificate. This is my Shield config:

      pki1:
        type: pki
        order: 2
        truststore:
          path: "/home/msimos/elasticsearch-2.1.1/config/node01.jks"
          password: "password"
        files:
          role_mapping: "/home/msimos/Downloads/elasticsearch-2.1.1/config/shield/pki.yml"
shield.http.ssl.client.auth: optional

When I go to http://kibana:5601 I am never prompted for a password. But I do see that the Kibana server successfully authenticates:

[2016-02-04 13:42:03,607][DEBUG][shield.authc.support     ] [node01] the roles [[kibana4_server]], are mapped from the user [pki] for realm [CN=node01.example.com, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=YS/pki]
[2016-02-04 13:42:03,608][DEBUG][shield.audit.logfile     ] [node01] [transport] [access_granted]       origin_type=[rest], origin_address=[192.168.1.81], principal=[node01.example.com], action=[cluster:monitor/nodes/info], request=[NodesInfoRequest]

If I stop Kibana, comment out the ssl.cert and key settings and set a username and password, start Kibana and refresh the browser I am prompted for a username and password. It seems like Kibana is not configured to prompt for a username & password when elasticsearch.username & elasticsearch.password is not set. I tested this on Kibana 4.1.1 and Kibana 4.3.1 and I had the same behavior. This is so that the Kibana server authentications with PKI and you don't need to store any password in kibana.yml and the user gets prompted from the browser to login.

@rashidkpc
Copy link
Contributor

The server authenticating and the user authenticating are two totally different systems. Kibana will only prompt for a username and password if Elasticsearch returns a 401. It looks like in your case a 401 is not being returned. I don't know enough about shield to know if you can configure PKI for certain users and username/password auth for others, but that's what you're trying todo here.

I'd recommend filing a support ticket with Elastic to find out more about configuring Shield

@msimos
Copy link
Author

msimos commented Feb 5, 2016

Hi,

I work in support :) You can ping me on Slack if you want more details. But I already discussed this with @jaymode and one question I have. Is if Kibana always sends what is defined in elasticsearch.ssl.cert in the HTTPS request then it would always authenticate. Does Kibana not send this certificate after the Kibana server user has authenticated? If Kibana always sends the cert then it seems to me you would not get a 401. From the Shield side there isn't anyway to accomplish this.

@rashidkpc
Copy link
Contributor

Gotcha. I see what you're getting at here. Filing as a bug

@rashidkpc rashidkpc added bug Fixes for quality problems that affect the customer experience P2 and removed feedback_needed labels Feb 5, 2016
@skearns64
Copy link

To summarize the issue here:

If PKI authentication is defined for the Kibana serverside user, via

elasticsearch.url: "https://node01:9200"
elasticsearch.ssl.cert: /home/msimos/kibana-4.3.1-linux-x64/config/my.crt
elasticsearch.ssl.key: /home/msimos/kibana-4.3.1-linux-x64/config/my.key
elasticsearch.ssl.ca: /home/msimos/kibana-4.3.1-linux-x64/config/cacert.pem

The PKI information should be used only for requests to ES made by the kibana server user; it should not be used for end-user requests. Today, this PKI information is attached to all requests, which is the issue.

@lukasolson lukasolson self-assigned this Jul 15, 2016
@floragunn
Copy link

any news on that?

@lukasolson
Copy link
Member

@floragunncom No news, other than this is high on our priority list and will be worked on very soon.

@lukasolson lukasolson removed their assignment Nov 4, 2016
@tbragin tbragin added the Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc label Feb 14, 2017
@epixa
Copy link
Contributor

epixa commented Mar 20, 2017

This is fixed in 5.2 onward.

See #7341 if you're interested in PKI support for Kibana end-users.

@nick-george
Copy link

For anyone coming across this thread, this does not appear to be fixed. @skearns64 excellent summary above (#6119 (comment)) still appears to be the behaviour in v6.2.1.

@kobelb
Copy link
Contributor

kobelb commented Apr 16, 2018

@nick-george would you mind elaborating upon your setup and the behavior that you're seeing that leads you to believe this is still broken in 6.2.1?

@nick-george
Copy link

nick-george commented Apr 16, 2018

Hi Brandon,

Apologies for the last message lacking any detail. Below is a post that I made to the Searchguard mailing list recently, including some of the response. While it isn't using X-Pack, I believe the underlying issue is exactly the same. It seems that if Kibana is configured to use PKI to authenticate to Elasticsearch, then all users of Kibana inherit Kibana's permissions, and won't have their own.

Hi,

First, some version info:

  • Search Guard version: 6.2.1-21 with no enterprise modules.
  • Elasticsearch version. 6.2.1
  • JVM version and operating system version. java-1.8.0-openjdk-1.8.0.161-0.b14.el7_4.x86_64. Oracle Linux 7.4 (same as Centos).
  • Kernel version: 4.1.12-112.16.4.el7uek.x86_64

Here's ideally what I'd like to do:

  • Have all Kibana users authenticate with a password (certificate based authentication to Kibana is also acceptible)
  • Have all internal services (e.g Logstash) authenticate to Elasticsearch using certificates, this includes the Kibana Server itself.

Is this possible? The reason I ask is because although I seem to have successfully setup client certificate-based authentication (in addition to password based authentication), when I log into Kibana using password authentication, it seems that the Kibana Server itself does not have the correct permissions to query any indices. Please see the output below.

[2018-04-09T19:53:19,954][INFO ][c.f.s.c.PrivilegesEvaluator] No index-level perm match for User [name=Searchguard Kibana Certificate, roles=[], requestedTenant=null] [IndexType [index=alerts-2018.04.07, type=], IndexType [index=logstash-2018.02.27, type=], [Action [[indices:monitor/stats]]] [RolesChecked [sg_kibana_server]]

I was previously using purely password based authentication, and everything was working well. Once I switched to this hybrid arrangement, that's when the problems started. The sg_kibana_server 'role' has not changed.

I'm a bit confused about what functions are performed and what permissions are needed for the the kibana server vs the end user. I'm also confused as to why the behaviour for certificate-based authentication seems to be different than for password based authentication.

It seems to me that when using purely password based authentication, the Kibana user and the Kibana server each authenticate to ES separately. However, for client certificate based authentication, it seems that the user somehow only gets the Kibana Server's permissions, and none of their own. Why is this?

The documentation at the bottom of this (https://docs.search-guard.com/latest/kibana-plugin-installation) page seems to indicate as much:
"If the certificate is an admin certificate, this means that all actions from all users will be allowed, regardless of other authorization settings. While this may be useful in cases where you need complete admin access, it isn’t always clear what these configuration settings actually do and what their implications are."

Is it possible for you to shed some light on this and suggest a way forward? I'm thinking that it's probably not possible for me to switch the Kibana-Server itself over to using a client certificate.

I got a response from a Searchguard developer, which contained the following information.

The PKI information should be used only for requests to ES made by the kibana server user; it should not be used for end-user requests. Today, this PKI information is attached to all requests, which is the issue.

This means if you set these values, the certificate will be added to all requests, not just to the requests of the kibanaserver as it should be. This can lead to a potential security risk when people use an admin certificate here. That's why we added a safeguard and put it in the docs.

Many thanks,
Nick George

@kobelb
Copy link
Contributor

kobelb commented Apr 18, 2018

Thanks for the clarification @nick-george, I'm looking into this in more depth and I'll let you know what I find.

@kobelb
Copy link
Contributor

kobelb commented May 3, 2018

Hey @nick-george this will be resolved by the #17804. The old behavior was problematic when running Kibana without our X-Pack Security plugin or with the X-Pack Security plugin if the realms order in Elasticsearch has PKI taking precedence to the basic authentication.

@nick-george
Copy link

Many thanks for this Brandon, looking forward to trying it out!

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 Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc
Projects
None yet
Development

No branches or pull requests

9 participants