We have an ELK stack running on our private corporate network, and I have been tasked with securing it. I am investigating options for rolling out SearchGuard without undue disruption.
We have a nuget package which client applications use for firing log messages into ElasticSearch. This just creates an http request, and fires it at the ElasticSearch REST API.
The choice of auth method will be influenced by what is least disruptive.
Is there a choice of auth such that we could run the “secure” and “insecure” methods in parallel, and then when everyone is using the secure channel, turn the insecure channel off?
Context
-
Search Guard and Elasticsearch version: search-guard-6-6.5.2-23.2; elasticsearch-6.5.2
-
Installed and used enterprise modules, if any
-
JVM version and operating system version: 1.8.0_202
-
Search Guard configuration files
-
Elasticsearch log messages on debug level
-
Other installed Elasticsearch or Kibana plugins, if any: no other plugins
You could, for example, use the anonymous authentication feature for that:
Usually, when a request does not carry any user credentials (basic auth, JWT, Kerberos ticket etc.) Search Guard would reject it. If you enable anonymous auth, Search Guard will assign all unauthenticated requests to a default “anonymous” user. You could then map this anonymous user to a Search Guard role that has sufficient/all permissions that your tools need. That way users/tools would not note any difference.
If everything is switched to secure channels, you can disable anonymous auth again. This can all be done on a running cluster without the need for a restart.
···
On Monday, January 28, 2019 at 10:03:00 AM UTC+1, Mat Martin wrote:
We have an ELK stack running on our private corporate network, and I have been tasked with securing it. I am investigating options for rolling out SearchGuard without undue disruption.
We have a nuget package which client applications use for firing log messages into ElasticSearch. This just creates an http request, and fires it at the ElasticSearch REST API.
The choice of auth method will be influenced by what is least disruptive.
Is there a choice of auth such that we could run the “secure” and “insecure” methods in parallel, and then when everyone is using the secure channel, turn the insecure channel off?
Context
- Search Guard and Elasticsearch version: search-guard-6-6.5.2-23.2; elasticsearch-6.5.2
- Installed and used enterprise modules, if any
- JVM version and operating system version: 1.8.0_202
- Search Guard configuration files
- Elasticsearch log messages on debug level
- Other installed Elasticsearch or Kibana plugins, if any: no other plugins
When you run a totally unsecured ES cluster you can not install Search Guard in a rolling manner without downtime because of inter-node TLS communication.
In other words: For the first inital Search Guard installation you need to take the whole cluster down, for subsequent updates there is no downtime anymore.
···
Am 31.01.2019 um 17:05 schrieb Jochen Kressin <jkressin@floragunn.com>:
You could, for example, use the anonymous authentication feature for that:
Search Guard Documentation 404 | Security for Elasticsearch | Search Guard
Usually, when a request does not carry any user credentials (basic auth, JWT, Kerberos ticket etc.) Search Guard would reject it. If you enable anonymous auth, Search Guard will assign all unauthenticated requests to a default "anonymous" user. You could then map this anonymous user to a Search Guard role that has sufficient/all permissions that your tools need. That way users/tools would not note any difference.
If everything is switched to secure channels, you can disable anonymous auth again. This can all be done on a running cluster without the need for a restart.
On Monday, January 28, 2019 at 10:03:00 AM UTC+1, Mat Martin wrote:
We have an ELK stack running on our private corporate network, and I have been tasked with securing it. I am investigating options for rolling out SearchGuard without undue disruption.
We have a nuget package which client applications use for firing log messages into ElasticSearch. This just creates an http request, and fires it at the ElasticSearch REST API.
The choice of auth method will be influenced by what is least disruptive.
Is there a choice of auth such that we could run the "secure" and "insecure" methods in parallel, and then when everyone is using the secure channel, turn the insecure channel off?
Context
* Search Guard and Elasticsearch version: search-guard-6-6.5.2-23.2; elasticsearch-6.5.2
* Installed and used enterprise modules, if any
* JVM version and operating system version: 1.8.0_202
* Search Guard configuration files
* Elasticsearch log messages on debug level
* Other installed Elasticsearch or Kibana plugins, if any: no other plugins
--
You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com.
To post to this group, send email to search-guard@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/bc2bfe4e-0f46-4d6e-aee6-040b5dccbc50%40googlegroups.com\.
For more options, visit https://groups.google.com/d/optout\.