Using Elasticsearch 6.2 with Searchguard 6.2.2-22.1 & Kibana Rest API Plugin 6.2.2-30.0 configured for all access.
Everything is working fine with Searchguard and I can configure users, roles etc using the yaml files.
When using the Kibana Searchguard UI, everything seems to work ok I can create users, edit roles etc.without any errors.
The issue is that none of the changes are committed to Searchguard or appear in the yaml files, sg_internal_users.yml etc.
Is there something I’m missing with the config? I am logged in via trusted proxy with a user who has full access. The elasticsearch.yml has the addition of searchguard.restapi.roles_enabled: [“sg_all_access”, admin]
Also, I have noticed that if using the ‘username’ option for a user with dots/symbols in the name then this user is shown in the UI OK if setup manually, but there doesn’t seem to be an option to configure the username option in the UI when creating a new user.
Hi,
so just to make sure I understood it correctly:
“When using the Kibana Searchguard UI, everything seems to work ok I can create users, edit roles etc.without any errors.”
“The issue is that none of the changes are committed to Searchguard or appear in the yaml files, sg_internal_users.yml etc.”
That means you can make changes with the UI, and the changes also take effect. Like, you can add a role and the role is created successfully, right? And you expect that the changes reflect in the configuration files?
This is not how the Search Guard configuration actually works. The configuration is always stored in Elasticsearch directly, in a specially secured searchguard index. The configuration files are never read by Search Guard, you only use them to push the configuration to the said Search Guard index with sgadmin. This way you never have to have configuration files with sensitive information like usernames or role definitions anywhere on your nodes physically.
Changes to the Search Guard index, with sgadmin or the UI, are thus never written back to any configuration files. You would not have them on your nodes anyways.
But please do let me know if you meant something different!
“Also, I have noticed that if using the ‘username’ option for a user with dots/symbols in the name then this user is shown in the UI OK if setup manually, but there doesn’t seem to be an option to configure the username option in the UI when creating a new user.”
True 
This is a known issue and we’re investigating it.
···
On Sunday, May 6, 2018 at 9:12:35 AM UTC+2, Bernie Carolan wrote:
Using Elasticsearch 6.2 with Searchguard 6.2.2-22.1 & Kibana Rest API Plugin 6.2.2-30.0 configured for all access.
Everything is working fine with Searchguard and I can configure users, roles etc using the yaml files.
When using the Kibana Searchguard UI, everything seems to work ok I can create users, edit roles etc.without any errors.
The issue is that none of the changes are committed to Searchguard or appear in the yaml files, sg_internal_users.yml etc.
Is there something I’m missing with the config? I am logged in via trusted proxy with a user who has full access. The elasticsearch.yml has the addition of searchguard.restapi.roles_enabled: [“sg_all_access”, admin]
Also, I have noticed that if using the ‘username’ option for a user with dots/symbols in the name then this user is shown in the UI OK if setup manually, but there doesn’t seem to be an option to configure the username option in the UI when creating a new user.
I have the same problem too. I can see I defined user and role info. in GUI. But when I use the defined user in java http client, it is invalid. And after I execute sgadmin.sh, I can not see this defined user in GUI.
在 2018年5月9日星期三 UTC+8上午1:02:48，Jochen Kressin写道：
···
Hi,
so just to make sure I understood it correctly:
“When using the Kibana Searchguard UI, everything seems to work ok I can create users, edit roles etc.without any errors.”
“The issue is that none of the changes are committed to Searchguard or appear in the yaml files, sg_internal_users.yml etc.”
That means you can make changes with the UI, and the changes also take effect. Like, you can add a role and the role is created successfully, right? And you expect that the changes reflect in the configuration files?
This is not how the Search Guard configuration actually works. The configuration is always stored in Elasticsearch directly, in a specially secured searchguard index. The configuration files are never read by Search Guard, you only use them to push the configuration to the said Search Guard index with sgadmin. This way you never have to have configuration files with sensitive information like usernames or role definitions anywhere on your nodes physically.
Changes to the Search Guard index, with sgadmin or the UI, are thus never written back to any configuration files. You would not have them on your nodes anyways.
But please do let me know if you meant something different!
“Also, I have noticed that if using the ‘username’ option for a user with dots/symbols in the name then this user is shown in the UI OK if setup manually, but there doesn’t seem to be an option to configure the username option in the UI when creating a new user.”
True This is a known issue and we’re investigating it.
On Sunday, May 6, 2018 at 9:12:35 AM UTC+2, Bernie Carolan wrote:
Using Elasticsearch 6.2 with Searchguard 6.2.2-22.1 & Kibana Rest API Plugin 6.2.2-30.0 configured for all access.
Everything is working fine with Searchguard and I can configure users, roles etc using the yaml files.
When using the Kibana Searchguard UI, everything seems to work ok I can create users, edit roles etc.without any errors.
The issue is that none of the changes are committed to Searchguard or appear in the yaml files, sg_internal_users.yml etc.
Is there something I’m missing with the config? I am logged in via trusted proxy with a user who has full access. The elasticsearch.yml has the addition of searchguard.restapi.roles_enabled: [“sg_all_access”, admin]
Also, I have noticed that if using the ‘username’ option for a user with dots/symbols in the name then this user is shown in the UI OK if setup manually, but there doesn’t seem to be an option to configure the username option in the UI when creating a new user.
Hi,
what exactly do you mean by " The issue is that none of the changes are committed to Searchguard or appear in the yaml files, sg_internal_users.yml etc."?
Configuration changes are never written back to any configuration file. The whole concept of Search Guard is to store all configuration settings in the Search Guard index in Elasticsearch. That allows for config hot-reload, and you do not need to place any configuration files (which may contain sensitive information) on any node in the cluster. The sgadmin tool and the REST API merely write changes to this index.
If you want to retrieve the current configuration from your cluster, you can use the -r/–retrieve option in sgadmin. This will download the config.
Regarding the dots: Yes, dots are a constant annoyance and problematic due to the way Elasticsearch stores documents. We are working on this, but at the moment you cannot use dots in usernames in the config GUI.
···
On Sunday, May 6, 2018 at 9:12:35 AM UTC+2, Bernie Carolan wrote:
Using Elasticsearch 6.2 with Searchguard 6.2.2-22.1 & Kibana Rest API Plugin 6.2.2-30.0 configured for all access.
Everything is working fine with Searchguard and I can configure users, roles etc using the yaml files.
When using the Kibana Searchguard UI, everything seems to work ok I can create users, edit roles etc.without any errors.
The issue is that none of the changes are committed to Searchguard or appear in the yaml files, sg_internal_users.yml etc.
Is there something I’m missing with the config? I am logged in via trusted proxy with a user who has full access. The elasticsearch.yml has the addition of searchguard.restapi.roles_enabled: [“sg_all_access”, admin]
Also, I have noticed that if using the ‘username’ option for a user with dots/symbols in the name then this user is shown in the UI OK if setup manually, but there doesn’t seem to be an option to configure the username option in the UI when creating a new user.