Simple case - the kibana guide to securing kibana with SSL assumes generating CSR 'from' Kibana server and submitting to SSL provider. I need instructions how to use my existing multi-domain certificate to secure Browser-to-Kibana traffic.
Use KIBANA & es util to generate CSR (below assumes generating CSR from Kibana svr):
Hi @Bitdoctor —
I would expect Kibana to use whatever certificate you point it to in kibana.yml. So, if I already had an existing cert and key file, I'd just start at step 4 in those docs you pointed out.
Does this help? Let me know if I missed anything!
Thank you! That did appear to work. The remainder is just something with firewall and/or NAT, because I can get to the server from the 'internal' IP from my workstation; but it times out, if I try to access it using the public/external DNS name, which translates to a public IP that is on the server and accessible via our gateway.
Glad to hear it. Let me know if I can be of more help on the Kibana side.
One final point here, then I'll post a new topic on using local self-signed certs that come with ELK. I want to mention that the so-called "standard paths" like KBN_PATH_CONF and even the ones for Elastic, Logstash, etc. do not seem to be used by default - is that normal? I thought maybe, by installing by DEB package method and setting most of the config info, that those items may get populated? Seems not, and seems a lot of documentation leaves out the fact that these must be manually populated - does that sound right?
KBN_PATH_CONF is an example of an environment variable. They're a dynamic variable construct provided by the operating system to configure running processes.
How they get set really depends on your setup. As you say, they can be set manually via shell commands ( How To Read and Set Environmental and Shell Variables on Linux | DigitalOcean) or they can be loaded automatically by tooling. They can also be configured from a cloud console or Kubernetes configs if you are deploying the stack to AWS for example.
Thanks Andrew. I am aware of how environment variables work overall, and i am using induvidual Azure VMs, not kubernetes or AWS stack, fyi. My problem is that I see lots of mention of these variables, yet I haven't seen official documentation regarding, "Oh, by the way, you have to 'set' these manually " or however they need to get set. I'm fine with using them, but they should document it, such as "for self-managed standalone, you have to set them; for kubernetes, use [whatever method]," etc. Could it be that I missed that part in the documentation?
Hmmm, not sure on this. I'll pass along your feedback internally. Thanks!
@Bitdoctor it looks like that KBN_PATH_CONF variable should be configured by default. No action should be required on your part unless you want to change the default location of the config directory.
Can you explain a little more about what you ran into?
We setup via DEB method, with 1 x Kibana server, 1 x Logstash server and 3 x Elastic nodes; as Ubuntu 20.04 installed on individual Azure VMs.
We noted that, by default, none of the “_PATH” variables appear to get set by default (Elastic, Kibana, etc.) – it could be something we’ve not done that we should have?
In my Dev environment that I first setup, I noted that I did have to manually populate those as well – started at Elastic 5.x, upgraded to 7.x, then to 8.3.
In the Dev setup, I did (do) have all ELK components on one server; but had to jump through typical Linux hoops to figure how to properly ‘export’ variables globally, so that they’d be recognized by all facets of the installed apps and the OS.
There seems to be varying documentation, depending upon method of install (tar/gzip, RPM, DEB), and some degrees of variation also regarding various sub-components and integrations, such as SSL certs, built-in self-signed certs, certs signed by internal CA; fleet server setup & integration; etc.
1 Like
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.