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 in RED status after ROR install #264

Open
askids opened this Issue Sep 3, 2017 · 12 comments

Comments

Projects
None yet
2 participants
@askids
Copy link

askids commented Sep 3, 2017

i installed ROR plugin readonlyrest-1.16.10_es5.5.1 for Elasticsearch 5.5.1 running on windows 2008 R2. I added the below entries to elasticsearch.yml file and restarted the Elasticsearch service. When I launched the new https ES endpoint in chrome, i was prompted for id/pwd and entering the kibana id/pwd worked. Then I modified the kibana.yml file and uncomment elasticsearch.username and elasticsearch.password and added id/pwd, updated the elasticsearch.url property to use the https endpoint. Restarted Kibana.

But Kibana is showing status in red with error message. Unable to connect to Elasticsearch at https://xxxxxxxx.yyyyyyyyy.com:12200. Its red for plugin:elasticsearch@5.5.1, ui settings, plugin:xpack_main@5.5.1, plugin:searchprofiler@5.5.1, plugin:tilemap@5.5.1, plugin:ml@5.5.1.

Kibana is running on same machine, but different port. Am I missing any steps for updating kibana.yml file?

#
# ReadonlyREST entries
http.type: ssl_netty4
readonlyrest:
    enable: true 
    response_if_req_forbidden: Forbidden by ReadonlyREST ES plugin
    
    ssl:
      enable: true
      # put the keystore in the same dir with elasticsearch.yml 
      keystore_file: "plugins/readonlyrest/mykeystore.jks"
      keystore_pass: Password1
      key_pass: Password1
   
    access_control_rules:

    - name: Kibana Server
      type: allow
      auth_key: kibana:kibana
      verbosity: error

Thanks!

@sscarduzio

This comment has been minimized.

Copy link
Owner

sscarduzio commented Sep 3, 2017

maybe the certificate is not trusted? Try adding to kibana.yml

elasticsearch.ssl.verificationMode: none

And see if it works

@askids

This comment has been minimized.

Copy link

askids commented Sep 4, 2017

Thank you! That worked. Later on I changed the verification mode to full and using openssl generated pem file using -cacerts option and added that to "elasticsearch.ssl.certificateAuthorities" property and that works as well.

As you pointed out, the certificate was not in trusted list, but in the Personal certificate list. So I deleted it and imported the certificate to the Trusted Root Certification Authorities/Certificates. Then I commented out "elasticsearch.ssl.certificateAuthorities" and left the "elasticsearch.ssl.verificationMode" as full, but it went back to Red state. Isn't Kibana supposed to pick it up from Trusted Certificates from host, when this property is not set?

I had couple of other questions.
a) My Kibana site is still running under http only. If I have to make the site https, do you have the detailed steps to set it up for https?
b) Currently since I only have basic authentication setup, its prompting for id/pwd. However, if I want to use certificate for authentication, how do I set it up? Please let me know. Most of the samples that you have provided in the documentation, deals with id/pwd.

Thanks!

@sscarduzio

This comment has been minimized.

Copy link
Owner

sscarduzio commented Sep 4, 2017

AFAIK yes, Kibana should pick the OS global Root CA.

a) Elastic documentation explains how to set up Kibana to accept https:
https://www.elastic.co/guide/en/kibana/current/production.html#enabling-ssl

b) You mean to require kibana web server to only a certain client side SSL cert? I'm not aware this is supported in Kibana.

@askids

This comment has been minimized.

Copy link

askids commented Sep 4, 2017

@sscarduzio Thank you. I was able to configure kibana to use SSL by configuring below properties in kibana.yml.

server.ssl.enabled: true
server.ssl.certificate: mycert.crt
server.ssl.key: mycert.key

When I used the normal key file that had the encrypted key, i was getting error in Kibana.
Error: error:0907B068:PEM routines:PEM_READ_BIO_PRIVATEKEY:bad password read
So unfortunately, i had to write the RSA private key to my key file to get it to work.

Coming to the 2nd question, if client certs are not supported, then I would want to pass the current logged in user information for authentication, without having to prompt for the user id/pwd again from the Kibana URL. How can that be achieved? On Elasticsearch side, using ROR, there is integration for LDAP authentication for the user. Now if we have extend this to Kibana user, is that supported? If yes, what kind of configuration is needed it?

@sscarduzio

This comment has been minimized.

Copy link
Owner

sscarduzio commented Sep 5, 2017

Forwarding the logged in user as a HTTP header is possible with proxy-auth rule, see docs: https://readonlyrest.com/documentation/#Rules--Authentication

This is used when you have an exotic authentication algorithm and you delegate the authentication process to a proxy, and the proxy writes the resolved user name to a header before forwarding the request to Kibana.

BTW, are you a ROR for Kibana plugin user? Because proxy-auth with is not yet supported (but it's a small modification that has been pending for a while).

@askids

This comment has been minimized.

Copy link

askids commented Sep 6, 2017

To your second question, we will be buying ROR pro, which I think makes us eligible for Kibana plugin. But that procurement will take another 6-8 weeks. Till then we are getting other security setup sorted out as we are still in development.

We have CA SSO and kibana will be hosted as an intranet site. So we would want to utilize that and pass on the current user information to Elasticsearch to that it can then use that identity against ldap rules to determine what kind of access current logged in user has. Our Infosec team always pushes for not to use basic authentication to the extent possible.

Also, is there a plan to secure the transport port in near future with ROR?

@sscarduzio

This comment has been minimized.

Copy link
Owner

sscarduzio commented Sep 6, 2017

The only way to skip basic auth is with the Kibana plugin or some proxy.
No there is no plan to encrypt the transport layer at the moment, but I don't exclude this will become necessary with Elasticsearch 6

@askids

This comment has been minimized.

Copy link

askids commented Sep 6, 2017

Ok. Whenever you do, what i would suggest is to enable simple certificate authentication for node-node communication on transport port. Since Java http client is also being actively pushed with v5.x, even on Java side number of use cases needing to use transport port vs REST end point will also start reducing. So as long as nodes can authenticate that connection to transport port is from another valid/authorized node, then that should be sufficient. I think both Shield and Searchguard has similar implementation.

@sscarduzio

This comment has been minimized.

Copy link
Owner

sscarduzio commented Sep 6, 2017

@askids when you say Java client is being actively pushed, what do you refer to?
Also, what are the use cases that need a transport client?

I'm very, very skeptical about any actual needs to use the transport protocol unless you are an ES node.

As I see it, the transport level SSL encryption is just necessary when you really need to tick the box of fully encrypted data in transit when you have very sensitive data at stake.

For the other applications, adopting the transport instead of HTTP will just add problems: prepare to handle issues with proxies, more difficult traffic inspection. And for what? x% performance?

@askids

This comment has been minimized.

Copy link

askids commented Sep 6, 2017

I might have given a wrong picture when I said http client. I meant to say that there is push to use Java "REST client" which was introduced with v5.x. This works on http port. So the need for someone to use the transport port directly from their client should start to come down, going forward. But it might take some time before we reach a stage to say that transport is not being used at all directly from client. We are using both REST APIs from Elasticsearch for querying and NEST client for data push (this is the .NET client from Elasticsearch), which again happens to use the http port.

I completely agree with your statement on anyone actually needing to use transport port directly, unless its a ES node. That is why I had suggested that instead of trying to support all kind of authentication/authorization on the transport port, it might be simpler to just support one type of implementation (certificate based) to ensure encrypted communication between nodes on the transport port and use the certificate to establish the trust between the nodes.

Coming to our usage, we do deal with sensitive data as we are using Elasticsearch primary to provide advanced text search/faceting on client/account data. It's not being used for any log analytics. So currently for us, even though we will start using ROR for the time being, leaving the transport port open for anyone to access looks like a security loophole as there is no protection at all. At least with certificate based protection, we can ensure that connections from unknown hosts are not being accepted.

@sscarduzio

This comment has been minimized.

Copy link
Owner

sscarduzio commented Sep 7, 2017

Since Java http client is also being actively pushed

Apologies @askids, I apparently skipped reading 'http'. We are then thinking exactly the same way about the topic 👍

Incidentally, this was an interesting insight in how different customers have different use cases/requirements. I should really get serious in interviewing customers in preparation for next month's roadmap.

PS: ROR customers are so F* smart. In fact, many features were born from ideas customers randomly cared to share ❤️

@askids

This comment has been minimized.

Copy link

askids commented Sep 7, 2017

I would definitely request putting transport port security into your short term road map 😁. BTW, any thoughts on alternate options to temporarily plug that gap till ROR can officially support it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment