In a recent blog post I described and mentioned techniques how to implement and install #ELK supplementary monitoring stack to laptop setup array, meaning that the main #LAMP stack is supervised with the help of #ELK & beats combination. In this sense additional banking security such as #tls and #rbac provision are necessary for crisp and smooth look of #ELK working utility, enabling even remote connections out of the box capability – basing, of course, on #openssl standards.
In addition to this, other means consideration may arise, like environmental variables substitution in /etc configuration files, #keystore secure entries saving and #seccomp (secure computing) utilization. It’s worth stating, however, that the aforementioned ones aren’t as as useful and attractive as it may look like. Firstly, the environment variables are in simply terms not working ($HOST not substituted at all) and secondly, in most usable cases they are too sophisticated to normally utilize as a abstracting and alleviating design pattern – imagine $ES_HOST, $ES_HOSTS, $ES_HOST_WITH_SCHEME, $ES_HOSTS_AS_ARRAY, $ES_HOSTS_WITH_SCHEME, $ES_HOSTS_WITH_SCHEME_AS_ARRAY, and alike (others) variables for simple https://<hostname>:9200 substitution in various formats that are used (#json & #yml style) across the (#elk) stack. That’s not possible to call it simplifying solution, far cry from design patter implementation. In this sense, what about #seccomp? Although #beats site advertises it widely, manual (not even #systemd) launch halts immediately failing with segmentation fault principal error. To say at least, open standardization of #openssl and widely used #rbac terms are contributing fairly enough for the security of the stack in the long term.