I have been playing with this tool since last three days and below are my understandings and experiences:
Complex to install and understand
Complex to assign role/actions/groups
Documentation not that much easy to have an understanding in one or two read
I think any software which is hard to understand or install won’t be a success as users will refrain to use due to complexity unless there is huge community involvement to drive the change like kubernetes having. As a comparison to ReadOnlyREST plugin, I have found SearchGaurd plugin has a learning curve.
More emphasis would be on making some sample use-cases and include those in the documentation as a readily available sample for new users like:
How to install without jumping out from one link to another link
Generating TLS certs (already in place but requires a bit of understanding at first place)
Creating new users
Assigning roles/permissions/actions to those users
Adding them to specific groups
So that it would be easy to relate the real use-case. All above are (or might be) available but not at one place. It needs to be consolidated to make it easy.
Above views are based on my understanding and experience with the tool as I am struggling to get it done. And, once I will (and if) be successful to achieve what I have planned then would love to contribute so that others won’t spend time in figuring out how to do it rightly.
I hope my views make some sense. Please correct me if I am mistaken or there is already some sample configurations available then please redirect me so that I would learn and implement.
Thanks very much for your input. I think that you are hitting the nail on the head for a couple of points, but I would also like to know about one or two issues in more detail, so we can improve on the user experience.
The first part of my answer will be a bit philosophical but I would like to outline the reasoning behind our decisions regarding how Search Guard should work.
Yes, you are totally right that Search Guard has a learning curve. While some are indeed rooted in missing one-page use cases / setup instructions, others are due to our general “security first” approach. For example:
“As a comparison to ReadOnlyREST plugin, I have found SearchGaurd plugin has a learning curve.”
RoR does not provide any encryption on the transport layer, only on REST layer. This makes it very convenient when installing and configuring RoR, since you do not need to deal with tansport TLS certificates at all.
But - it also means that while you think your cluster is secure, in fact, it is not: Since the traffic on transport layer is unencrypted, anyone can access your cluster without any permission checks, and also access all data in it. For example by simply connecting with a transport client. Search Guard requires you to set up TLS certificates at least on transport layer, otherwise it won’t start. Yes, this means you need to learn about TLS, but it also makes sure you end up with a secure cluster. And that is our goal - providing real security for Elasticsearch.
We also strongly believe that there is no “one-click security”. Security is a complex topic and always will be. If you want to implement security for any product or infrastructure layer, you have to know what you are doing and you need to familiarize yourself with security technologies and protocols. Otherwise, security holes are nearly guaranteed.
In short our philosophy is: If we need to choose between user experience and security, we will always choose security because that is what we promise.
Ok, so back to some more concrete questions and issues
* Complex to install and understand
Can you outline where you think the installation is complex? The installation is done by the regular Elasticsearch plugin command, so please help me to understand how we can make installation easier.
* Complex to assign role/actions/groups
Can you outline what you mean by complex? You have a user and it’s backend roles. Depending on what authentication tool you use, the user and the backend roles might come from LDAP, Active Directory, Kerberos, JWT etc. You then map this user to one or more Search Guard roles in the roles mapping. Please help me to understand where exactly this process is confusing and how we can make it more clear / easier for users.
* Documentation not that much easy to have an understanding in one or two read
This is very true, and we are already working on specific one-two page use case setup instructions.
* Generating TLS certs (already in place but requires a bit of understanding at first place)
Yes, TLS requires an understanding about certificates, CAs and certificate chains. But as outlined above, I do not think you can have security without this understanding. For generating certificates, we have an offline tool and also provide an online service with detailed setup instructions. Search Guard 6 also comes with demo certificates and a demo installer which sets up TLS automatically for you. Please help me to understand what other tools or instructions we should make available to ease the TLS setup. Do you have anything specific in mind here?
* Creating new users
This again depends on what authentication technology you use. Creating new users in LDAP is different from JWT is different from Kerberos etc. For the internal user database we have this documentation here: Internal users database | Security for Elasticsearch | Search Guard You just add users to the configuration and upload the changed configuration with sgadmin. Can you please tell how we can make this documentation more concise/easier here in your opinion and where you got confused?
And, once I will (and if) be successful to achieve what I have planned then would love to contribute so that others won’t spend time in figuring out how to do it rightly.
That would be awesome and we always appreciate feedback and input from users. Especially contributions to the documentation are more than welcome, and we would love to get your input / pull request on this.
Please correct me if I am mistaken or there is already some sample configurations available then please redirect me so that I would learn and implement.
For ES/SG/KI, there is for example this guest post on the Sematext website:
We also publish posts on our own blog, for example this post about JSON web tokens:
But as always, there could be more, I agree.
···
On Friday, April 20, 2018 at 12:54:51 AM UTC-7, Sahil Modgill wrote:
Hello all,
I have been playing with this tool since last three days and below are my understandings and experiences:
Complex to install and understand
Complex to assign role/actions/groups
Documentation not that much easy to have an understanding in one or two read
I think any software which is hard to understand or install won’t be a success as users will refrain to use due to complexity unless there is huge community involvement to drive the change like kubernetes having. As a comparison to ReadOnlyREST plugin, I have found SearchGaurd plugin has a learning curve.
More emphasis would be on making some sample use-cases and include those in the documentation as a readily available sample for new users like:
How to install without jumping out from one link to another link
Generating TLS certs (already in place but requires a bit of understanding at first place)
Creating new users
Assigning roles/permissions/actions to those users
Adding them to specific groups
So that it would be easy to relate the real use-case. All above are (or might be) available but not at one place. It needs to be consolidated to make it easy.
Above views are based on my understanding and experience with the tool as I am struggling to get it done. And, once I will (and if) be successful to achieve what I have planned then would love to contribute so that others won’t spend time in figuring out how to do it rightly.
I hope my views make some sense. Please correct me if I am mistaken or there is already some sample configurations available then please redirect me so that I would learn and implement.
but I would like to outline the reasoning behind our decisions regarding how Search Guard should work.