Change the password for admin

[Xiaoyu_Wu]

I am currently using elasticsearch 6.2.2 and corresponding search-guard. I have already installed the kibana plugin and got into the GUI.
I am wondering how to change the password for the demo users like admin. The document said set ‘read_only’ to false and apply the sgadmin but I am not sure how to use sgadmin to apply the new changes. What I did before is just to follow the instruction and apply the default configuration.

My purpose is to have my own admin account for the later use case.

[jkressin]

First, remove the readonly flag from the roles definition (sg_roles.yml) and if you like also for the internal users (sg_internalusers.yml).

If you are using the demo installer, execute sgadmin_demo.sh to apply the changed configuration.

If you have installed Search Guard without the demo installer please refer to the documentation on how to use sgadmin on the command line:

Migrating configuration files

···

On Sunday, April 15, 2018 at 2:16:40 PM UTC-7, Xiaoyu Wu wrote:

I am currently using elasticsearch 6.2.2 and corresponding search-guard. I have already installed the kibana plugin and got into the GUI.
I am wondering how to change the password for the demo users like admin. The document said set ‘read_only’ to false and apply the sgadmin but I am not sure how to use sgadmin to apply the new changes. What I did before is just to follow the instruction and apply the default configuration.

My purpose is to have my own admin account for the later use case.

[Xiaoyu_Wu]

I did not use the demo installer.

I checked the documentation but it is kinda difficult for me to understand the entire implementation. What I did so far is just:

   ./sgadmin.sh \
-cd /path/to/sgconfig/ \
-cacert /path/to/root-ca.pem \
-cert /path/to/kirk.crt.pem \
-key /path/to/kirk.key.pem \
-keypass changeit
-nhnv
-icl

It seems it only applies the default configuration. I did remove the readonly flag in the yml file.

Could you give me a simple example in this case?

在 2018年4月15日星期日 UTC-4下午7:17:14，Jochen Kressin写道：

···

First, remove the readonly flag from the roles definition (sg_roles.yml) and if you like also for the internal users (sg_internalusers.yml).

If you are using the demo installer, execute sgadmin_demo.sh to apply the changed configuration.

If you have installed Search Guard without the demo installer please refer to the documentation on how to use sgadmin on the command line:

https://docs.search-guard.com/latest/sgadmin

On Sunday, April 15, 2018 at 2:16:40 PM UTC-7, Xiaoyu Wu wrote:

I am currently using elasticsearch 6.2.2 and corresponding search-guard. I have already installed the kibana plugin and got into the GUI.
I am wondering how to change the password for the demo users like admin. The document said set ‘read_only’ to false and apply the sgadmin but I am not sure how to use sgadmin to apply the new changes. What I did before is just to follow the instruction and apply the default configuration.

My purpose is to have my own admin account for the later use case.

[jkressin]

What is the output of the sgadmin tool when you run the command you posted? And what do you see in the Elasticsearch logs when you run sgadmin?

···

On Sunday, April 15, 2018 at 4:34:56 PM UTC-7, Xiaoyu Wu wrote:

I did not use the demo installer.

I checked the documentation but it is kinda difficult for me to understand the entire implementation. What I did so far is just:

   ./sgadmin.sh \
-cd /path/to/sgconfig/ \
-cacert /path/to/root-ca.pem \
-cert /path/to/kirk.crt.pem \
-key /path/to/kirk.key.pem \
-keypass changeit
-nhnv
-icl

It seems it only applies the default configuration. I did remove the readonly flag in the yml file.

Could you give me a simple example in this case?

在 2018年4月15日星期日 UTC-4下午7:17:14，Jochen Kressin写道：

First, remove the readonly flag from the roles definition (sg_roles.yml) and if you like also for the internal users (sg_internalusers.yml).

If you are using the demo installer, execute sgadmin_demo.sh to apply the changed configuration.

If you have installed Search Guard without the demo installer please refer to the documentation on how to use sgadmin on the command line:

https://docs.search-guard.com/latest/sgadmin

On Sunday, April 15, 2018 at 2:16:40 PM UTC-7, Xiaoyu Wu wrote:

I am currently using elasticsearch 6.2.2 and corresponding search-guard. I have already installed the kibana plugin and got into the GUI.
I am wondering how to change the password for the demo users like admin. The document said set ‘read_only’ to false and apply the sgadmin but I am not sure how to use sgadmin to apply the new changes. What I did before is just to follow the instruction and apply the default configuration.

My purpose is to have my own admin account for the later use case.

[Xiaoyu_Wu]

This is the output of sgadmin tool,

searchguard index already exists, so we do not need to create one.

Populate config from /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/

Will update ‘sg/config’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_config.yml

SUCC: Configuration for ‘config’ created or updated

Will update ‘sg/roles’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_roles.yml

SUCC: Configuration for ‘roles’ created or updated

Will update ‘sg/rolesmapping’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_roles_mapping.yml

SUCC: Configuration for ‘rolesmapping’ created or updated

Will update ‘sg/internalusers’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_internal_users.yml

SUCC: Configuration for ‘internalusers’ created or updated

Will update ‘sg/actiongroups’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_action_groups.yml

SUCC: Configuration for ‘actiongroups’ created or updated

Done with success

And when I restarted the Kibana, it threw me the error saying “An error occurred while checking your credentials, make sure you have an Elasticsearch cluster secured by Search Guard running.”

在 2018年4月15日星期日 UTC-4下午7:56:32，Jochen Kressin写道：

···

What is the output of the sgadmin tool when you run the command you posted? And what do you see in the Elasticsearch logs when you run sgadmin?

On Sunday, April 15, 2018 at 4:34:56 PM UTC-7, Xiaoyu Wu wrote:

I did not use the demo installer.

I checked the documentation but it is kinda difficult for me to understand the entire implementation. What I did so far is just:

   ./sgadmin.sh \
-cd /path/to/sgconfig/ \
-cacert /path/to/root-ca.pem \
-cert /path/to/kirk.crt.pem \
-key /path/to/kirk.key.pem \
-keypass changeit
-nhnv
-icl

It seems it only applies the default configuration. I did remove the readonly flag in the yml file.

Could you give me a simple example in this case?

在 2018年4月15日星期日 UTC-4下午7:17:14，Jochen Kressin写道：

First, remove the readonly flag from the roles definition (sg_roles.yml) and if you like also for the internal users (sg_internalusers.yml).

If you are using the demo installer, execute sgadmin_demo.sh to apply the changed configuration.

If you have installed Search Guard without the demo installer please refer to the documentation on how to use sgadmin on the command line:

https://docs.search-guard.com/latest/sgadmin

On Sunday, April 15, 2018 at 2:16:40 PM UTC-7, Xiaoyu Wu wrote:

I am currently using elasticsearch 6.2.2 and corresponding search-guard. I have already installed the kibana plugin and got into the GUI.
I am wondering how to change the password for the demo users like admin. The document said set ‘read_only’ to false and apply the sgadmin but I am not sure how to use sgadmin to apply the new changes. What I did before is just to follow the instruction and apply the default configuration.

My purpose is to have my own admin account for the later use case.

[jkressin]

sgadmin will replace the current configuration in your cluster with the files located in:

/Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/

So if you want to make changes to the configuration, the easiest way of doing so is to change these files, and then run sgadmin again. According to the output sgadmin has succeeded with uploading the configuration. So your sgadmin command seems fine.

There seems to be something wrong with your Kibana configuration and/or the Search Guard configuration.

What is the output of the Elasticsearch log file? Do you see any error there?

What is the Kibana configuration your are using? Please post it here.

Did you try to restart Kibana and reload the login page?

···

On Sunday, April 15, 2018 at 4:59:02 PM UTC-7, Xiaoyu Wu wrote:

This is the output of sgadmin tool,

searchguard index already exists, so we do not need to create one.

Populate config from /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/

Will update ‘sg/config’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_config.yml

SUCC: Configuration for ‘config’ created or updated

Will update ‘sg/roles’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_roles.yml

SUCC: Configuration for ‘roles’ created or updated

Will update ‘sg/rolesmapping’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_roles_mapping.yml

SUCC: Configuration for ‘rolesmapping’ created or updated

Will update ‘sg/internalusers’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_internal_users.yml

SUCC: Configuration for ‘internalusers’ created or updated

Will update ‘sg/actiongroups’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_action_groups.yml

SUCC: Configuration for ‘actiongroups’ created or updated

Done with success

And when I restarted the Kibana, it threw me the error saying “An error occurred while checking your credentials, make sure you have an Elasticsearch cluster secured by Search Guard running.”

在 2018年4月15日星期日 UTC-4下午7:56:32，Jochen Kressin写道：

What is the output of the sgadmin tool when you run the command you posted? And what do you see in the Elasticsearch logs when you run sgadmin?

On Sunday, April 15, 2018 at 4:34:56 PM UTC-7, Xiaoyu Wu wrote:

I did not use the demo installer.

I checked the documentation but it is kinda difficult for me to understand the entire implementation. What I did so far is just:

   ./sgadmin.sh \
-cd /path/to/sgconfig/ \
-cacert /path/to/root-ca.pem \
-cert /path/to/kirk.crt.pem \
-key /path/to/kirk.key.pem \
-keypass changeit
-nhnv
-icl

It seems it only applies the default configuration. I did remove the readonly flag in the yml file.

Could you give me a simple example in this case?

在 2018年4月15日星期日 UTC-4下午7:17:14，Jochen Kressin写道：

First, remove the readonly flag from the roles definition (sg_roles.yml) and if you like also for the internal users (sg_internalusers.yml).

If you are using the demo installer, execute sgadmin_demo.sh to apply the changed configuration.

If you have installed Search Guard without the demo installer please refer to the documentation on how to use sgadmin on the command line:

https://docs.search-guard.com/latest/sgadmin

On Sunday, April 15, 2018 at 2:16:40 PM UTC-7, Xiaoyu Wu wrote:

I am currently using elasticsearch 6.2.2 and corresponding search-guard. I have already installed the kibana plugin and got into the GUI.
I am wondering how to change the password for the demo users like admin. The document said set ‘read_only’ to false and apply the sgadmin but I am not sure how to use sgadmin to apply the new changes. What I did before is just to follow the instruction and apply the default configuration.

My purpose is to have my own admin account for the later use case.

[Xiaoyu_Wu]

I checked localhost:9200/_authinfo and the elasticsearch looks good.

This is a part of my kibana config (the rest is the default)

elasticsearch.username: “kibanaserver”

elasticsearch.password: “kibanaserver”

elasticsearch.ssl.verificationMode: none

Login Page

searchguard.basicauth.login.showbrandimage: true

searchguard.basicauth.login.brandimage: https://www.symantec.com/content/dam/symantec/images/common/symantec-logo-top.png

searchguard.cookie.name: ‘searchguard_authentication’

#searchguard.basicauth.login.title

#searchguard.basicauth.login.subtitle

This is the output of elasticsearch log,

[2018-04-15T20:07:25,113][INFO ][c.f.s.c.IndexBaseConfigurationRepository] Search Guard License Info: SearchGuardLicense [uid=00000000-0000-0000-0000-000000000000, type=TRIAL, issueDate=2018-04-15, expiryDate=2018-06-15, issuedTo=The world, issuer=floragunn GmbH, startDate=2018-04-15, majorVersion=6, clusterName=*, allowedNodeCount=2147483647, msgs=, expiresInDays=60, isExpired=false, valid=true, action=, prodUsage=Yes, one cluster with all commercial features and unlimited nodes per cluster., clusterService=org.elasticsearch.cluster.service.ClusterService@2e500df4, getMsgs()=, getExpiresInDays()=60, isExpired()=false, isValid()=true, getAction()=, getProdUsage()=Yes, one cluster with all commercial features and unlimited nodes per cluster.]

[2018-04-15T20:07:25,113][INFO ][c.f.s.c.IndexBaseConfigurationRepository] Search Guard License Type: TRIAL, valid

[2018-04-15T20:07:25,114][INFO ][c.f.s.c.IndexBaseConfigurationRepository] Node ‘LhPFJNW’ initialized

[2018-04-15T20:07:25,364][INFO ][o.e.c.r.a.AllocationService] [LhPFJNW] Cluster health status changed from [RED] to [YELLOW] (reason: [shards started [[.kibana][0]] …]).

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No index-level perm match for User [name=kibanaserver, roles=, requestedTenant=null] [IndexType [index=watcher_alarms, type=*]] [Action [[indices:admin/get]]] [RolesChecked [sg_kibana_server, sg_own_index]]

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No permissions for {sg_own_index=[IndexType [index=watcher_alarms, type=]], sg_kibana_server=[IndexType [index=watcher_alarms, type=]]}

在 2018年4月15日星期日 UTC-4下午8:05:10，Jochen Kressin写道：

···

sgadmin will replace the current configuration in your cluster with the files located in:

/Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/

So if you want to make changes to the configuration, the easiest way of doing so is to change these files, and then run sgadmin again. According to the output sgadmin has succeeded with uploading the configuration. So your sgadmin command seems fine.

There seems to be something wrong with your Kibana configuration and/or the Search Guard configuration.

What is the output of the Elasticsearch log file? Do you see any error there?

What is the Kibana configuration your are using? Please post it here.

Did you try to restart Kibana and reload the login page?

On Sunday, April 15, 2018 at 4:59:02 PM UTC-7, Xiaoyu Wu wrote:

This is the output of sgadmin tool,

searchguard index already exists, so we do not need to create one.

Populate config from /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/

Will update ‘sg/config’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_config.yml

SUCC: Configuration for ‘config’ created or updated

Will update ‘sg/roles’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_roles.yml

SUCC: Configuration for ‘roles’ created or updated

Will update ‘sg/rolesmapping’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_roles_mapping.yml

SUCC: Configuration for ‘rolesmapping’ created or updated

Will update ‘sg/internalusers’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_internal_users.yml

SUCC: Configuration for ‘internalusers’ created or updated

Will update ‘sg/actiongroups’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_action_groups.yml

SUCC: Configuration for ‘actiongroups’ created or updated

Done with success

And when I restarted the Kibana, it threw me the error saying “An error occurred while checking your credentials, make sure you have an Elasticsearch cluster secured by Search Guard running.”

在 2018年4月15日星期日 UTC-4下午7:56:32，Jochen Kressin写道：

What is the output of the sgadmin tool when you run the command you posted? And what do you see in the Elasticsearch logs when you run sgadmin?

On Sunday, April 15, 2018 at 4:34:56 PM UTC-7, Xiaoyu Wu wrote:

I did not use the demo installer.

I checked the documentation but it is kinda difficult for me to understand the entire implementation. What I did so far is just:

   ./sgadmin.sh \
-cd /path/to/sgconfig/ \
-cacert /path/to/root-ca.pem \
-cert /path/to/kirk.crt.pem \
-key /path/to/kirk.key.pem \
-keypass changeit
-nhnv
-icl

It seems it only applies the default configuration. I did remove the readonly flag in the yml file.

Could you give me a simple example in this case?

在 2018年4月15日星期日 UTC-4下午7:17:14，Jochen Kressin写道：

First, remove the readonly flag from the roles definition (sg_roles.yml) and if you like also for the internal users (sg_internalusers.yml).

If you are using the demo installer, execute sgadmin_demo.sh to apply the changed configuration.

If you have installed Search Guard without the demo installer please refer to the documentation on how to use sgadmin on the command line:

https://docs.search-guard.com/latest/sgadmin

On Sunday, April 15, 2018 at 2:16:40 PM UTC-7, Xiaoyu Wu wrote:

I am currently using elasticsearch 6.2.2 and corresponding search-guard. I have already installed the kibana plugin and got into the GUI.
I am wondering how to change the password for the demo users like admin. The document said set ‘read_only’ to false and apply the sgadmin but I am not sure how to use sgadmin to apply the new changes. What I did before is just to follow the instruction and apply the default configuration.

My purpose is to have my own admin account for the later use case.

[jkressin]

So it seems you also have installed X-Pack and there is an error with your watcher configuration:

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No index-level perm match for User [name=kibanaserver, roles=, requestedTenant=null] [IndexType [index=watcher_alarms, type=*]] [Action [[indices:admin/get]]] [RolesChecked [sg_kibana_server, sg_own_index]]

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No permissions for {sg_own_index=[IndexType [index=watcher_alarms, type=]], sg_kibana_server=[IndexType [index=watcher_alarms, type=]]}

Please post at least:

• kibana.yml

• elasticsearch.yml

• sg_roles.yml

Just remove any sensitive information like paths and passwords.

···

On Sunday, April 15, 2018 at 5:11:26 PM UTC-7, Xiaoyu Wu wrote:

I checked localhost:9200/_authinfo and the elasticsearch looks good.

This is a part of my kibana config (the rest is the default)

elasticsearch.username: “kibanaserver”

elasticsearch.password: “kibanaserver”

elasticsearch.ssl.verificationMode: none

Login Page

searchguard.basicauth.login.showbrandimage: true

searchguard.basicauth.login.brandimage: https://www.symantec.com/content/dam/symantec/images/common/symantec-logo-top.png

searchguard.cookie.name: ‘searchguard_authentication’

#searchguard.basicauth.login.title

#searchguard.basicauth.login.subtitle

This is the output of elasticsearch log,

[2018-04-15T20:07:25,113][INFO ][c.f.s.c.IndexBaseConfigurationRepository] Search Guard License Info: SearchGuardLicense [uid=00000000-0000-0000-0000-000000000000, type=TRIAL, issueDate=2018-04-15, expiryDate=2018-06-15, issuedTo=The world, issuer=floragunn GmbH, startDate=2018-04-15, majorVersion=6, clusterName=*, allowedNodeCount=2147483647, msgs=, expiresInDays=60, isExpired=false, valid=true, action=, prodUsage=Yes, one cluster with all commercial features and unlimited nodes per cluster., clusterService=org.elasticsearch.cluster.service.ClusterService@2e500df4, getMsgs()=, getExpiresInDays()=60, isExpired()=false, isValid()=true, getAction()=, getProdUsage()=Yes, one cluster with all commercial features and unlimited nodes per cluster.]

[2018-04-15T20:07:25,113][INFO ][c.f.s.c.IndexBaseConfigurationRepository] Search Guard License Type: TRIAL, valid

[2018-04-15T20:07:25,114][INFO ][c.f.s.c.IndexBaseConfigurationRepository] Node ‘LhPFJNW’ initialized

[2018-04-15T20:07:25,364][INFO ][o.e.c.r.a.AllocationService] [LhPFJNW] Cluster health status changed from [RED] to [YELLOW] (reason: [shards started [[.kibana][0]] …]).

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No index-level perm match for User [name=kibanaserver, roles=, requestedTenant=null] [IndexType [index=watcher_alarms, type=*]] [Action [[indices:admin/get]]] [RolesChecked [sg_kibana_server, sg_own_index]]

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No permissions for {sg_own_index=[IndexType [index=watcher_alarms, type=]], sg_kibana_server=[IndexType [index=watcher_alarms, type=]]}

在 2018年4月15日星期日 UTC-4下午8:05:10，Jochen Kressin写道：

sgadmin will replace the current configuration in your cluster with the files located in:

/Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/

So if you want to make changes to the configuration, the easiest way of doing so is to change these files, and then run sgadmin again. According to the output sgadmin has succeeded with uploading the configuration. So your sgadmin command seems fine.

There seems to be something wrong with your Kibana configuration and/or the Search Guard configuration.

What is the output of the Elasticsearch log file? Do you see any error there?

What is the Kibana configuration your are using? Please post it here.

Did you try to restart Kibana and reload the login page?

On Sunday, April 15, 2018 at 4:59:02 PM UTC-7, Xiaoyu Wu wrote:

This is the output of sgadmin tool,

searchguard index already exists, so we do not need to create one.

Populate config from /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/

Will update ‘sg/config’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_config.yml

SUCC: Configuration for ‘config’ created or updated

Will update ‘sg/roles’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_roles.yml

SUCC: Configuration for ‘roles’ created or updated

Will update ‘sg/rolesmapping’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_roles_mapping.yml

SUCC: Configuration for ‘rolesmapping’ created or updated

Will update ‘sg/internalusers’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_internal_users.yml

SUCC: Configuration for ‘internalusers’ created or updated

Will update ‘sg/actiongroups’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_action_groups.yml

SUCC: Configuration for ‘actiongroups’ created or updated

Done with success

And when I restarted the Kibana, it threw me the error saying “An error occurred while checking your credentials, make sure you have an Elasticsearch cluster secured by Search Guard running.”

在 2018年4月15日星期日 UTC-4下午7:56:32，Jochen Kressin写道：

What is the output of the sgadmin tool when you run the command you posted? And what do you see in the Elasticsearch logs when you run sgadmin?

On Sunday, April 15, 2018 at 4:34:56 PM UTC-7, Xiaoyu Wu wrote:

I did not use the demo installer.

I checked the documentation but it is kinda difficult for me to understand the entire implementation. What I did so far is just:

   ./sgadmin.sh \
-cd /path/to/sgconfig/ \
-cacert /path/to/root-ca.pem \
-cert /path/to/kirk.crt.pem \
-key /path/to/kirk.key.pem \
-keypass changeit
-nhnv
-icl

It seems it only applies the default configuration. I did remove the readonly flag in the yml file.

Could you give me a simple example in this case?

在 2018年4月15日星期日 UTC-4下午7:17:14，Jochen Kressin写道：

First, remove the readonly flag from the roles definition (sg_roles.yml) and if you like also for the internal users (sg_internalusers.yml).

If you are using the demo installer, execute sgadmin_demo.sh to apply the changed configuration.

If you have installed Search Guard without the demo installer please refer to the documentation on how to use sgadmin on the command line:

https://docs.search-guard.com/latest/sgadmin

On Sunday, April 15, 2018 at 2:16:40 PM UTC-7, Xiaoyu Wu wrote:

I am currently using elasticsearch 6.2.2 and corresponding search-guard. I have already installed the kibana plugin and got into the GUI.
I am wondering how to change the password for the demo users like admin. The document said set ‘read_only’ to false and apply the sgadmin but I am not sure how to use sgadmin to apply the new changes. What I did before is just to follow the instruction and apply the default configuration.

My purpose is to have my own admin account for the later use case.

[Xiaoyu_Wu]

I used to login the kibana page successfully until I customized the login page.

This is the ES config,

======================== Elasticsearch Configuration =========================

···

NOTE: Elasticsearch comes with reasonable defaults for most settings.

Before you set out to tweak and tune the configuration, make sure you

understand what are you trying to accomplish and the consequences.

The primary way of configuring a node is via this file. This template lists

the most important settings you may want to configure for a production cluster.

Please consult the documentation for further information on configuration options:

Elasticsearch Guide | Elastic

---------------------------------- Cluster -----------------------------------

Use a descriptive name for your cluster:

#cluster.name: my-application

------------------------------------ Node ------------------------------------

Use a descriptive name for the node:

#node.name: node-1

Add custom attributes to the node:

#node.attr.rack: r1

----------------------------------- Paths ------------------------------------

Path to directory where to store the data (separate multiple locations by comma):

#path.data: /path/to/data

Path to log files:

#path.logs: /path/to/logs

----------------------------------- Memory -----------------------------------

Lock the memory on startup:

#bootstrap.memory_lock: true

Make sure that the heap size is set to about half the memory available

on the system and that the owner of the process is allowed to use this

limit.

Elasticsearch performs poorly when the system is swapping the memory.

---------------------------------- Network -----------------------------------

Set the bind address to a specific IP (IPv4 or IPv6):

#network.host: 192.168.0.1

Set a custom port for HTTP:

#http.port: 9200

For more information, consult the network module documentation.

--------------------------------- Discovery ----------------------------------

Pass an initial list of hosts to perform discovery when new node is started:

The default list of hosts is [“127.0.0.1”, “[::1]”]

#discovery.zen.ping.unicast.hosts: [“host1”, “host2”]

Prevent the “split brain” by configuring the majority of nodes (total number of master-eligible nodes / 2 + 1):

#discovery.zen.minimum_master_nodes:

For more information, consult the zen discovery module documentation.

---------------------------------- Gateway -----------------------------------

Block initial recovery after a full cluster restart until N nodes are started:

#gateway.recover_after_nodes: 3

For more information, consult the gateway module documentation.

---------------------------------- Various -----------------------------------

Require explicit names when deleting indices:

#action.destructive_requires_name: true

---------------------------------- Search Guard ------------------------------

searchguard.authcz.admin_dn:

• CN=kirk,OU=client,O=client,L=Test,C=DE

Relative path to the certificates key file (PKCS #8), must be placed under the config/ dir

searchguard.ssl.transport.pemkey_filepath: node-0.key.pem

Key password (omit this setting if the key has no password)

#searchguard.ssl.transport.pemkey_password: “secret”

X509 node certificate chain in PEM format, must be placed under the config/ dir

searchguard.ssl.transport.pemcert_filepath: node-0.crt.pem

Trusted certificates

searchguard.ssl.transport.pemtrustedcas_filepath: chain-ca.pem

searchguard.restapi.roles_enabled: [“sg_all_access”]

This is the Kibana,

Kibana is served by a back end server. This setting specifies the port to use.

#server.port: 5601

Specifies the address to which the Kibana server will bind. IP addresses and host names are both valid values.

The default is ‘localhost’, which usually means remote machines will not be able to connect.

To allow connections from remote users, set this parameter to a non-loopback address.

#server.host: “localhost”

Enables you to specify a path to mount Kibana at if you are running behind a proxy. This only affects

the URLs generated by Kibana, your proxy is expected to remove the basePath value before forwarding requests

to Kibana. This setting cannot end in a slash.

#server.basePath: “”

The maximum payload size in bytes for incoming server requests.

#server.maxPayloadBytes: 1048576

The Kibana server’s name. This is used for display purposes.

#server.name: “your-hostname”

The URL of the Elasticsearch instance to use for all your queries.

#elasticsearch.url: “http://localhost:9200”

When this setting’s value is true Kibana uses the hostname specified in the server.host

setting. When the value of this setting is false, Kibana uses the hostname of the host

that connects to this Kibana instance.

#elasticsearch.preserveHost: true

Kibana uses an index in Elasticsearch to store saved searches, visualizations and

dashboards. Kibana creates a new index if the index doesn’t already exist.

#kibana.index: “.kibana”

The default application to load.

#kibana.defaultAppId: “home”

If your Elasticsearch is protected with basic authentication, these settings provide

the username and password that the Kibana server uses to perform maintenance on the Kibana

index at startup. Your Kibana users still need to authenticate with Elasticsearch, which

is proxied through the Kibana server.

#elasticsearch.username: “kibana”

#elasticsearch.password: “BioEPQ1o51gAyIsQYaWc”

Enables SSL and paths to the PEM-format SSL certificate and SSL key files, respectively.

These settings enable SSL for outgoing requests from the Kibana server to the browser.

#server.ssl.enabled: false

#server.ssl.certificate: /path/to/your/server.crt

#server.ssl.key: /path/to/your/server.key

Optional settings that provide the paths to the PEM-format SSL certificate and key files.

These files validate that your Elasticsearch backend uses the same key files.

#elasticsearch.ssl.certificate: /path/to/your/client.crt

#elasticsearch.ssl.key: /path/to/your/client.key

Optional setting that enables you to specify a path to the PEM file for the certificate

authority for your Elasticsearch instance.

#elasticsearch.ssl.certificateAuthorities: [ “/path/to/your/CA.pem” ]

To disregard the validity of SSL certificates, change this setting’s value to ‘none’.

#elasticsearch.ssl.verificationMode: full

Time in milliseconds to wait for Elasticsearch to respond to pings. Defaults to the value of

the elasticsearch.requestTimeout setting.

#elasticsearch.pingTimeout: 1500

Time in milliseconds to wait for responses from the back end or Elasticsearch. This value

must be a positive integer.

#elasticsearch.requestTimeout: 30000

List of Kibana client-side headers to send to Elasticsearch. To send no client-side

headers, set this value to (an empty list).

#elasticsearch.requestHeadersWhitelist: [ authorization ]

Header names and values that are sent to Elasticsearch. Any custom headers cannot be overwritten

by client-side headers, regardless of the elasticsearch.requestHeadersWhitelist configuration.

#elasticsearch.customHeaders: {}

Time in milliseconds for Elasticsearch to wait for responses from shards. Set to 0 to disable.

#elasticsearch.shardTimeout: 0

Time in milliseconds to wait for Elasticsearch at Kibana startup before retrying.

#elasticsearch.startupTimeout: 5000

Specifies the path where Kibana creates the process ID file.

#pid.file: /var/run/kibana.pid

Enables you specify a file where Kibana stores log output.

#logging.dest: stdout

Set the value of this setting to true to suppress all logging output.

#logging.silent: false

Set the value of this setting to true to suppress all logging output other than error messages.

#logging.quiet: false

Set the value of this setting to true to log all events, including system usage information

and all requests.

#logging.verbose: false

Set the interval in milliseconds to sample system and process performance

metrics. Minimum is 100ms. Defaults to 5000.

#ops.interval: 5000

The default locale. This locale can be used in certain circumstances to substitute any missing

translations.

#i18n.defaultLocale: “en”

Config of Sentinl

sentinl:

settings:

email:

active: true

user: ------

password: -------

host: -------

ssl: true

timeout: 10000

elasticsearch.username: “kibanaserver”

elasticsearch.password: “kibanaserver”

elasticsearch.ssl.verificationMode: none

Login Page

searchguard.basicauth.login.showbrandimage: true

searchguard.basicauth.login.brandimage: https://www.symantec.com/content/dam/symantec/images/common/symantec-logo-top.png

searchguard.cookie.name: ‘searchguard_authentication’

#searchguard.basicauth.login.title

#searchguard.basicauth.login.subtitle

This is the sg_roles,

#<sg_role_name>:

cluster:

- ‘’

indices:

‘’:

‘’:

- ‘’

dls: ‘’

fls:

- ‘’

- ‘’

When a user make a request to Elasticsearch then the following roles will be evaluated to see if the user has

permissions for the request. A request is always associated with an action and is executed against and index (or alias)

and a type. If a request is executed against all indices (or all types) then the asterix (‘*’) is needed.

Every role a user has will be examined if it allows the action against an index (or type). At least one role must match

for the request to be successful. If no role match then the request will be denied. Currently a match must happen within

one single role - that means that permissions can not span multiple roles.

For , and simple wildcards and regular expressions are possible.

A asterix (*) will match any character sequence (or an empty sequence)

A question mark (?) will match any single character (but NOT empty character)

Example: ‘myindex’ will match ‘my_first_index’ as well as ‘myindex’ but not ‘myindex1’

Example: ‘?kibana’ will match ‘.kibana’ but not ‘kibana’

To use a full blown regex you have to pre- and apend a ‘/’ to use regex instead of simple wildcards

‘//’

Example: ‘/\S*/’ will match any non whitespace characters

Important:

Index, alias or type names can not contain dots (.) in the or expression.

Reason is that we currently parse the config file into a elasticsearch settings object which cannot cope with dots in keys.

Workaround: Just configure something like ‘?kibana’ instead of ‘.kibana’ or ‘my?index’ instead of ‘my.index’

This limitation will likely removed with Search Guard 6

DLS (Document level security) - NOT FREE FOR COMMERCIAL

Search Guard Documentation 404 | Security for Elasticsearch | Search Guard

FLS (Field level security) - NOT FREE FOR COMMERCIAL

Search Guard Documentation 404 | Security for Elasticsearch | Search Guard

Kibana multitenancy - NOT FREE FOR COMMERCIAL

Search Guard Documentation 404 | Security for Elasticsearch | Search Guard

Allows everything, but no changes to searchguard configuration index

sg_all_access:

readonly: true

cluster:

• UNLIMITED

indices:

‘*’:

‘*’:

• UNLIMITED

tenants:

admin_tenant: RW

Read all, but no write permissions

sg_readall:

readonly: true

cluster:

• CLUSTER_COMPOSITE_OPS_RO

indices:

‘*’:

‘*’:

• READ

Read all and monitor, but no write permissions

sg_readall_and_monitor:

cluster:

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS_RO

indices:

‘*’:

‘*’:

• READ

For users which use kibana, access to indices must be granted separately

sg_kibana_user:

readonly: true

cluster:

• MONITOR

• CLUSTER_COMPOSITE_OPS_RO

indices:

‘?kibana’:

‘*’:

• MANAGE

• INDEX

• READ

• DELETE

‘*’:

‘*’:

• indices:data/read/field_caps*

For the kibana server

sg_kibana_server:

readonly: true

cluster:

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS

• cluster:admin/xpack/monitoring*

• indices:admin/template*

indices:

‘?kibana’:

‘*’:

• INDICES_ALL

‘?reporting*’:

‘*’:

• INDICES_ALL

‘?monitoring*’:

‘*’:

• INDICES_ALL

For logstash and beats

sg_logstash:

cluster:

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS

• indices:admin/template/get

• indices:admin/template/put

indices:

‘logstash-*’:

‘*’:

• CRUD

• CREATE_INDEX

‘beat’:

‘*’:

• CRUD

• CREATE_INDEX

Allows adding and modifying repositories and creating and restoring snapshots

sg_manage_snapshots:

cluster:

• MANAGE_SNAPSHOTS

indices:

‘*’:

‘*’:

• “indices:data/write/index”

• “indices:admin/create”

Allows each user to access own named index

sg_own_index:

cluster:

• CLUSTER_COMPOSITE_OPS

indices:

‘${user_name}’:

‘*’:

• INDICES_ALL

X-Pack COMPATIBILITY

sg_xp_monitoring:

readonly: true

indices:

‘?monitor*’:

‘*’:

• INDICES_ALL

sg_xp_alerting:

readonly: true

cluster:

• indices:data/read/scroll

• cluster:admin/xpack/watcher*

• cluster:monitor/xpack/watcher*

indices:

‘?watches*’:

‘*’:

• INDICES_ALL

‘?watcher-history-*’:

‘*’:

• INDICES_ALL

‘?triggered_watches’:

‘*’:

• INDICES_ALL

‘*’:

‘*’:

• READ

• indices:admin/aliases/get

sg_xp_machine_learning:

readonly: true

cluster:

• cluster:admin/persistent*

• cluster:internal/xpack/ml*

• indices:data/read/scroll*

• cluster:admin/xpack/ml*

• cluster:monitor/xpack/ml*

indices:

‘*’:

‘*’:

• READ

• indices:admin/get*

‘?ml-*’:

‘*’:

• “*”

LEGACY ROLES, FOR COMPATIBILITY ONLY

WILL BE REMOVED IN SG7, DO NOT USE ANYMORE

sg_readonly_and_monitor:

cluster:

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS_RO

indices:

‘*’:

‘*’:

• READ

Make xpack monitoring work

sg_monitor:

cluster:

• cluster:admin/xpack/monitoring/*

• cluster:admin/ingest/pipeline/put

• cluster:admin/ingest/pipeline/get

• indices:admin/template/get

• indices:admin/template/put

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS

indices:

‘?monitor*’:

‘*’:

• INDICES_ALL

‘?marvel*’:

‘*’:

• INDICES_ALL

‘?kibana*’:

‘*’:

• READ

‘*’:

‘*’:

• indices:data/read/field_caps

Make xpack alerting work

sg_alerting:

cluster:

• indices:data/read/scroll

• cluster:admin/xpack/watcher/watch/put

• cluster:admin/xpack/watcher*

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS

indices:

‘?kibana*’:

‘*’:

• READ

‘?watches*’:

‘*’:

• INDICES_ALL

‘?watcher-history-*’:

‘*’:

• INDICES_ALL

‘?triggered_watches’:

‘*’:

• INDICES_ALL

‘*’:

‘*’:

• READ

在 2018年4月15日星期日 UTC-4下午8:15:42，Jochen Kressin写道：

So it seems you also have installed X-Pack and there is an error with your watcher configuration:

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No index-level perm match for User [name=kibanaserver, roles=, requestedTenant=null] [IndexType [index=watcher_alarms, type=*]] [Action [[indices:admin/get]]] [RolesChecked [sg_kibana_server, sg_own_index]]

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No permissions for {sg_own_index=[IndexType [index=watcher_alarms, type=]], sg_kibana_server=[IndexType [index=watcher_alarms, type=]]}

Please post at least:

• kibana.yml

• elasticsearch.yml

• sg_roles.yml

Just remove any sensitive information like paths and passwords.

On Sunday, April 15, 2018 at 5:11:26 PM UTC-7, Xiaoyu Wu wrote:

I checked localhost:9200/_authinfo and the elasticsearch looks good.

This is a part of my kibana config (the rest is the default)

elasticsearch.username: “kibanaserver”

elasticsearch.password: “kibanaserver”

elasticsearch.ssl.verificationMode: none

Login Page

searchguard.basicauth.login.showbrandimage: true

searchguard.basicauth.login.brandimage: https://www.symantec.com/content/dam/symantec/images/common/symantec-logo-top.png

searchguard.cookie.name: ‘searchguard_authentication’

#searchguard.basicauth.login.title

#searchguard.basicauth.login.subtitle

This is the output of elasticsearch log,

[2018-04-15T20:07:25,113][INFO ][c.f.s.c.IndexBaseConfigurationRepository] Search Guard License Info: SearchGuardLicense [uid=00000000-0000-0000-0000-000000000000, type=TRIAL, issueDate=2018-04-15, expiryDate=2018-06-15, issuedTo=The world, issuer=floragunn GmbH, startDate=2018-04-15, majorVersion=6, clusterName=*, allowedNodeCount=2147483647, msgs=, expiresInDays=60, isExpired=false, valid=true, action=, prodUsage=Yes, one cluster with all commercial features and unlimited nodes per cluster., clusterService=org.elasticsearch.cluster.service.ClusterService@2e500df4, getMsgs()=, getExpiresInDays()=60, isExpired()=false, isValid()=true, getAction()=, getProdUsage()=Yes, one cluster with all commercial features and unlimited nodes per cluster.]

[2018-04-15T20:07:25,113][INFO ][c.f.s.c.IndexBaseConfigurationRepository] Search Guard License Type: TRIAL, valid

[2018-04-15T20:07:25,114][INFO ][c.f.s.c.IndexBaseConfigurationRepository] Node ‘LhPFJNW’ initialized

[2018-04-15T20:07:25,364][INFO ][o.e.c.r.a.AllocationService] [LhPFJNW] Cluster health status changed from [RED] to [YELLOW] (reason: [shards started [[.kibana][0]] …]).

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No index-level perm match for User [name=kibanaserver, roles=, requestedTenant=null] [IndexType [index=watcher_alarms, type=*]] [Action [[indices:admin/get]]] [RolesChecked [sg_kibana_server, sg_own_index]]

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No permissions for {sg_own_index=[IndexType [index=watcher_alarms, type=]], sg_kibana_server=[IndexType [index=watcher_alarms, type=]]}

在 2018年4月15日星期日 UTC-4下午8:05:10，Jochen Kressin写道：

sgadmin will replace the current configuration in your cluster with the files located in:

/Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/

So if you want to make changes to the configuration, the easiest way of doing so is to change these files, and then run sgadmin again. According to the output sgadmin has succeeded with uploading the configuration. So your sgadmin command seems fine.

There seems to be something wrong with your Kibana configuration and/or the Search Guard configuration.

What is the output of the Elasticsearch log file? Do you see any error there?

What is the Kibana configuration your are using? Please post it here.

Did you try to restart Kibana and reload the login page?

On Sunday, April 15, 2018 at 4:59:02 PM UTC-7, Xiaoyu Wu wrote:

This is the output of sgadmin tool,

searchguard index already exists, so we do not need to create one.

Populate config from /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/

Will update ‘sg/config’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_config.yml

SUCC: Configuration for ‘config’ created or updated

Will update ‘sg/roles’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_roles.yml

SUCC: Configuration for ‘roles’ created or updated

Will update ‘sg/rolesmapping’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_roles_mapping.yml

SUCC: Configuration for ‘rolesmapping’ created or updated

Will update ‘sg/internalusers’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_internal_users.yml

SUCC: Configuration for ‘internalusers’ created or updated

Will update ‘sg/actiongroups’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_action_groups.yml

SUCC: Configuration for ‘actiongroups’ created or updated

Done with success

And when I restarted the Kibana, it threw me the error saying “An error occurred while checking your credentials, make sure you have an Elasticsearch cluster secured by Search Guard running.”

在 2018年4月15日星期日 UTC-4下午7:56:32，Jochen Kressin写道：

What is the output of the sgadmin tool when you run the command you posted? And what do you see in the Elasticsearch logs when you run sgadmin?

On Sunday, April 15, 2018 at 4:34:56 PM UTC-7, Xiaoyu Wu wrote:

I did not use the demo installer.

I checked the documentation but it is kinda difficult for me to understand the entire implementation. What I did so far is just:

   ./sgadmin.sh \
-cd /path/to/sgconfig/ \
-cacert /path/to/root-ca.pem \
-cert /path/to/kirk.crt.pem \
-key /path/to/kirk.key.pem \
-keypass changeit
-nhnv
-icl

It seems it only applies the default configuration. I did remove the readonly flag in the yml file.

Could you give me a simple example in this case?

在 2018年4月15日星期日 UTC-4下午7:17:14，Jochen Kressin写道：

First, remove the readonly flag from the roles definition (sg_roles.yml) and if you like also for the internal users (sg_internalusers.yml).

If you are using the demo installer, execute sgadmin_demo.sh to apply the changed configuration.

If you have installed Search Guard without the demo installer please refer to the documentation on how to use sgadmin on the command line:

https://docs.search-guard.com/latest/sgadmin

On Sunday, April 15, 2018 at 2:16:40 PM UTC-7, Xiaoyu Wu wrote:

I am currently using elasticsearch 6.2.2 and corresponding search-guard. I have already installed the kibana plugin and got into the GUI.
I am wondering how to change the password for the demo users like admin. The document said set ‘read_only’ to false and apply the sgadmin but I am not sure how to use sgadmin to apply the new changes. What I did before is just to follow the instruction and apply the default configuration.

My purpose is to have my own admin account for the later use case.

[Xiaoyu_Wu]

This is the output of Kibana,

log [00:07:55.456] [info][Sentinl][scheduler] scheduled watcher sentinl-watcher:524238a0-345b-11e8-a95a-9954b3f36dde, to run every every 2 minutes

/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hoek/lib/index.js:736

throw new Error(msgs.join(' ') || 'Unknown error');

^

Error: Header value cannot contain or convert into non-ascii characters: set-cookie

at Object.exports.assert (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hoek/lib/index.js:736:11)

at internals.Response._header (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hapi/lib/response.js:141:22)

at request.connection.states.format (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hapi/lib/transmit.js:507:22)

at Items.serial (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/statehood/lib/index.js:436:16)

at done (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/items/lib/index.js:31:25)

at exports.prepareValue (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/statehood/lib/index.js:431:20)

at internals.sign (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/statehood/lib/index.js:461:20)

at process.nextTick (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hoek/lib/index.js:858:22)

at _combinedTickCallback (internal/process/next_tick.js:73:7)

at process._tickDomainCallback (internal/process/next_tick.js:128:9)

在 2018年4月15日星期日 UTC-4下午8:20:39，Xiaoyu Wu写道：

···

I used to login the kibana page successfully until I customized the login page.

This is the ES config,

======================== Elasticsearch Configuration =========================

NOTE: Elasticsearch comes with reasonable defaults for most settings.

Before you set out to tweak and tune the configuration, make sure you

understand what are you trying to accomplish and the consequences.

The primary way of configuring a node is via this file. This template lists

the most important settings you may want to configure for a production cluster.

Please consult the documentation for further information on configuration options:

https://www.elastic.co/guide/en/elasticsearch/reference/index.html

---------------------------------- Cluster -----------------------------------

Use a descriptive name for your cluster:

#cluster.name: my-application

------------------------------------ Node ------------------------------------

Use a descriptive name for the node:

#node.name: node-1

Add custom attributes to the node:

#node.attr.rack: r1

----------------------------------- Paths ------------------------------------

Path to directory where to store the data (separate multiple locations by comma):

#path.data: /path/to/data

Path to log files:

#path.logs: /path/to/logs

----------------------------------- Memory -----------------------------------

Lock the memory on startup:

#bootstrap.memory_lock: true

Make sure that the heap size is set to about half the memory available

on the system and that the owner of the process is allowed to use this

limit.

Elasticsearch performs poorly when the system is swapping the memory.

---------------------------------- Network -----------------------------------

Set the bind address to a specific IP (IPv4 or IPv6):

#network.host: 192.168.0.1

Set a custom port for HTTP:

#http.port: 9200

For more information, consult the network module documentation.

--------------------------------- Discovery ----------------------------------

Pass an initial list of hosts to perform discovery when new node is started:

The default list of hosts is [“127.0.0.1”, “[::1]”]

#discovery.zen.ping.unicast.hosts: [“host1”, “host2”]

Prevent the “split brain” by configuring the majority of nodes (total number of master-eligible nodes / 2 + 1):

#discovery.zen.minimum_master_nodes:

For more information, consult the zen discovery module documentation.

---------------------------------- Gateway -----------------------------------

Block initial recovery after a full cluster restart until N nodes are started:

#gateway.recover_after_nodes: 3

For more information, consult the gateway module documentation.

---------------------------------- Various -----------------------------------

Require explicit names when deleting indices:

#action.destructive_requires_name: true

---------------------------------- Search Guard ------------------------------

searchguard.authcz.admin_dn:

• CN=kirk,OU=client,O=client,L=Test,C=DE

Relative path to the certificates key file (PKCS #8), must be placed under the config/ dir

searchguard.ssl.transport.pemkey_filepath: node-0.key.pem

Key password (omit this setting if the key has no password)

#searchguard.ssl.transport.pemkey_password: “secret”

X509 node certificate chain in PEM format, must be placed under the config/ dir

searchguard.ssl.transport.pemcert_filepath: node-0.crt.pem

Trusted certificates

searchguard.ssl.transport.pemtrustedcas_filepath: chain-ca.pem

searchguard.restapi.roles_enabled: [“sg_all_access”]

This is the Kibana,

Kibana is served by a back end server. This setting specifies the port to use.

#server.port: 5601

Specifies the address to which the Kibana server will bind. IP addresses and host names are both valid values.

The default is ‘localhost’, which usually means remote machines will not be able to connect.

To allow connections from remote users, set this parameter to a non-loopback address.

#server.host: “localhost”

Enables you to specify a path to mount Kibana at if you are running behind a proxy. This only affects

the URLs generated by Kibana, your proxy is expected to remove the basePath value before forwarding requests

to Kibana. This setting cannot end in a slash.

#server.basePath: “”

The maximum payload size in bytes for incoming server requests.

#server.maxPayloadBytes: 1048576

The Kibana server’s name. This is used for display purposes.

#server.name: “your-hostname”

The URL of the Elasticsearch instance to use for all your queries.

#elasticsearch.url: “http://localhost:9200”

When this setting’s value is true Kibana uses the hostname specified in the server.host

setting. When the value of this setting is false, Kibana uses the hostname of the host

that connects to this Kibana instance.

#elasticsearch.preserveHost: true

Kibana uses an index in Elasticsearch to store saved searches, visualizations and

dashboards. Kibana creates a new index if the index doesn’t already exist.

#kibana.index: “.kibana”

The default application to load.

#kibana.defaultAppId: “home”

If your Elasticsearch is protected with basic authentication, these settings provide

the username and password that the Kibana server uses to perform maintenance on the Kibana

index at startup. Your Kibana users still need to authenticate with Elasticsearch, which

is proxied through the Kibana server.

#elasticsearch.username: “kibana”

#elasticsearch.password: “BioEPQ1o51gAyIsQYaWc”

Enables SSL and paths to the PEM-format SSL certificate and SSL key files, respectively.

These settings enable SSL for outgoing requests from the Kibana server to the browser.

#server.ssl.enabled: false

#server.ssl.certificate: /path/to/your/server.crt

#server.ssl.key: /path/to/your/server.key

Optional settings that provide the paths to the PEM-format SSL certificate and key files.

These files validate that your Elasticsearch backend uses the same key files.

#elasticsearch.ssl.certificate: /path/to/your/client.crt

#elasticsearch.ssl.key: /path/to/your/client.key

Optional setting that enables you to specify a path to the PEM file for the certificate

authority for your Elasticsearch instance.

#elasticsearch.ssl.certificateAuthorities: [ “/path/to/your/CA.pem” ]

To disregard the validity of SSL certificates, change this setting’s value to ‘none’.

#elasticsearch.ssl.verificationMode: full

Time in milliseconds to wait for Elasticsearch to respond to pings. Defaults to the value of

the elasticsearch.requestTimeout setting.

#elasticsearch.pingTimeout: 1500

Time in milliseconds to wait for responses from the back end or Elasticsearch. This value

must be a positive integer.

#elasticsearch.requestTimeout: 30000

List of Kibana client-side headers to send to Elasticsearch. To send no client-side

headers, set this value to (an empty list).

#elasticsearch.requestHeadersWhitelist: [ authorization ]

Header names and values that are sent to Elasticsearch. Any custom headers cannot be overwritten

by client-side headers, regardless of the elasticsearch.requestHeadersWhitelist configuration.

#elasticsearch.customHeaders: {}

Time in milliseconds for Elasticsearch to wait for responses from shards. Set to 0 to disable.

#elasticsearch.shardTimeout: 0

Time in milliseconds to wait for Elasticsearch at Kibana startup before retrying.

#elasticsearch.startupTimeout: 5000

Specifies the path where Kibana creates the process ID file.

#pid.file: /var/run/kibana.pid

Enables you specify a file where Kibana stores log output.

#logging.dest: stdout

Set the value of this setting to true to suppress all logging output.

#logging.silent: false

Set the value of this setting to true to suppress all logging output other than error messages.

#logging.quiet: false

Set the value of this setting to true to log all events, including system usage information

and all requests.

#logging.verbose: false

Set the interval in milliseconds to sample system and process performance

metrics. Minimum is 100ms. Defaults to 5000.

#ops.interval: 5000

The default locale. This locale can be used in certain circumstances to substitute any missing

translations.

#i18n.defaultLocale: “en”

Config of Sentinl

sentinl:

settings:

email:

active: true

user: ------

password: -------

host: -------

ssl: true

timeout: 10000

elasticsearch.username: “kibanaserver”

elasticsearch.password: “kibanaserver”

elasticsearch.ssl.verificationMode: none

Login Page

searchguard.basicauth.login.showbrandimage: true

searchguard.basicauth.login.brandimage: https://www.symantec.com/content/dam/symantec/images/common/symantec-logo-top.png

searchguard.cookie.name: ‘searchguard_authentication’

#searchguard.basicauth.login.title

#searchguard.basicauth.login.subtitle

This is the sg_roles,

#<sg_role_name>:

cluster:

- ‘’

indices:

‘’:

‘’:

- ‘’

dls: ‘’

fls:

- ‘’

- ‘’

When a user make a request to Elasticsearch then the following roles will be evaluated to see if the user has

permissions for the request. A request is always associated with an action and is executed against and index (or alias)

and a type. If a request is executed against all indices (or all types) then the asterix (‘*’) is needed.

Every role a user has will be examined if it allows the action against an index (or type). At least one role must match

for the request to be successful. If no role match then the request will be denied. Currently a match must happen within

one single role - that means that permissions can not span multiple roles.

For , and simple wildcards and regular expressions are possible.

A asterix (*) will match any character sequence (or an empty sequence)

A question mark (?) will match any single character (but NOT empty character)

Example: ‘myindex’ will match ‘my_first_index’ as well as ‘myindex’ but not ‘myindex1’

Example: ‘?kibana’ will match ‘.kibana’ but not ‘kibana’

To use a full blown regex you have to pre- and apend a ‘/’ to use regex instead of simple wildcards

‘//’

Example: ‘/\S*/’ will match any non whitespace characters

Important:

Index, alias or type names can not contain dots (.) in the or expression.

Reason is that we currently parse the config file into a elasticsearch settings object which cannot cope with dots in keys.

Workaround: Just configure something like ‘?kibana’ instead of ‘.kibana’ or ‘my?index’ instead of ‘my.index’

This limitation will likely removed with Search Guard 6

DLS (Document level security) - NOT FREE FOR COMMERCIAL

http://docs.search-guard.com/v6/document-level-security

FLS (Field level security) - NOT FREE FOR COMMERCIAL

http://docs.search-guard.com/v6/field-level-security

Kibana multitenancy - NOT FREE FOR COMMERCIAL

http://docs.search-guard.com/v6/kibana-multi-tenancy

Allows everything, but no changes to searchguard configuration index

sg_all_access:

readonly: true

cluster:

• UNLIMITED

indices:

‘*’:

‘*’:

• UNLIMITED

tenants:

admin_tenant: RW

Read all, but no write permissions

sg_readall:

readonly: true

cluster:

• CLUSTER_COMPOSITE_OPS_RO

indices:

‘*’:

‘*’:

• READ

Read all and monitor, but no write permissions

sg_readall_and_monitor:

cluster:

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS_RO

indices:

‘*’:

‘*’:

• READ

For users which use kibana, access to indices must be granted separately

sg_kibana_user:

readonly: true

cluster:

• MONITOR

• CLUSTER_COMPOSITE_OPS_RO

indices:

‘?kibana’:

‘*’:

• MANAGE

• INDEX

• READ

• DELETE

‘*’:

‘*’:

• indices:data/read/field_caps*

For the kibana server

sg_kibana_server:

readonly: true

cluster:

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS

• cluster:admin/xpack/monitoring*

• indices:admin/template*

indices:

‘?kibana’:

‘*’:

• INDICES_ALL

‘?reporting*’:

‘*’:

• INDICES_ALL

‘?monitoring*’:

‘*’:

• INDICES_ALL

For logstash and beats

sg_logstash:

cluster:

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS

• indices:admin/template/get

• indices:admin/template/put

indices:

‘logstash-*’:

‘*’:

• CRUD

• CREATE_INDEX

‘beat’:

‘*’:

• CRUD

• CREATE_INDEX

Allows adding and modifying repositories and creating and restoring snapshots

sg_manage_snapshots:

cluster:

• MANAGE_SNAPSHOTS

indices:

‘*’:

‘*’:

• “indices:data/write/index”

• “indices:admin/create”

Allows each user to access own named index

sg_own_index:

cluster:

• CLUSTER_COMPOSITE_OPS

indices:

‘${user_name}’:

‘*’:

• INDICES_ALL

X-Pack COMPATIBILITY

sg_xp_monitoring:

readonly: true

indices:

‘?monitor*’:

‘*’:

• INDICES_ALL

sg_xp_alerting:

readonly: true

cluster:

• indices:data/read/scroll

• cluster:admin/xpack/watcher*

• cluster:monitor/xpack/watcher*

indices:

‘?watches*’:

‘*’:

• INDICES_ALL

‘?watcher-history-*’:

‘*’:

• INDICES_ALL

‘?triggered_watches’:

‘*’:

• INDICES_ALL

‘*’:

‘*’:

• READ

• indices:admin/aliases/get

sg_xp_machine_learning:

readonly: true

cluster:

• cluster:admin/persistent*

• cluster:internal/xpack/ml*

• indices:data/read/scroll*

• cluster:admin/xpack/ml*

• cluster:monitor/xpack/ml*

indices:

‘*’:

‘*’:

• READ

• indices:admin/get*

‘?ml-*’:

‘*’:

• “*”

LEGACY ROLES, FOR COMPATIBILITY ONLY

WILL BE REMOVED IN SG7, DO NOT USE ANYMORE

sg_readonly_and_monitor:

cluster:

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS_RO

indices:

‘*’:

‘*’:

• READ

Make xpack monitoring work

sg_monitor:

cluster:

• cluster:admin/xpack/monitoring/*

• cluster:admin/ingest/pipeline/put

• cluster:admin/ingest/pipeline/get

• indices:admin/template/get

• indices:admin/template/put

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS

indices:

‘?monitor*’:

‘*’:

• INDICES_ALL

‘?marvel*’:

‘*’:

• INDICES_ALL

‘?kibana*’:

‘*’:

• READ

‘*’:

‘*’:

• indices:data/read/field_caps

Make xpack alerting work

sg_alerting:

cluster:

• indices:data/read/scroll

• cluster:admin/xpack/watcher/watch/put

• cluster:admin/xpack/watcher*

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS

indices:

‘?kibana*’:

‘*’:

• READ

‘?watches*’:

‘*’:

• INDICES_ALL

‘?watcher-history-*’:

‘*’:

• INDICES_ALL

‘?triggered_watches’:

‘*’:

• INDICES_ALL

‘*’:

‘*’:

• READ

在 2018年4月15日星期日 UTC-4下午8:15:42，Jochen Kressin写道：

So it seems you also have installed X-Pack and there is an error with your watcher configuration:

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No index-level perm match for User [name=kibanaserver, roles=, requestedTenant=null] [IndexType [index=watcher_alarms, type=*]] [Action [[indices:admin/get]]] [RolesChecked [sg_kibana_server, sg_own_index]]

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No permissions for {sg_own_index=[IndexType [index=watcher_alarms, type=]], sg_kibana_server=[IndexType [index=watcher_alarms, type=]]}

Please post at least:

• kibana.yml

• elasticsearch.yml

• sg_roles.yml

Just remove any sensitive information like paths and passwords.

On Sunday, April 15, 2018 at 5:11:26 PM UTC-7, Xiaoyu Wu wrote:

I checked localhost:9200/_authinfo and the elasticsearch looks good.

This is a part of my kibana config (the rest is the default)

elasticsearch.username: “kibanaserver”

elasticsearch.password: “kibanaserver”

elasticsearch.ssl.verificationMode: none

Login Page

searchguard.basicauth.login.showbrandimage: true

searchguard.basicauth.login.brandimage: https://www.symantec.com/content/dam/symantec/images/common/symantec-logo-top.png

searchguard.cookie.name: ‘searchguard_authentication’

#searchguard.basicauth.login.title

#searchguard.basicauth.login.subtitle

This is the output of elasticsearch log,

[2018-04-15T20:07:25,113][INFO ][c.f.s.c.IndexBaseConfigurationRepository] Search Guard License Info: SearchGuardLicense [uid=00000000-0000-0000-0000-000000000000, type=TRIAL, issueDate=2018-04-15, expiryDate=2018-06-15, issuedTo=The world, issuer=floragunn GmbH, startDate=2018-04-15, majorVersion=6, clusterName=*, allowedNodeCount=2147483647, msgs=, expiresInDays=60, isExpired=false, valid=true, action=, prodUsage=Yes, one cluster with all commercial features and unlimited nodes per cluster., clusterService=org.elasticsearch.cluster.service.ClusterService@2e500df4, getMsgs()=, getExpiresInDays()=60, isExpired()=false, isValid()=true, getAction()=, getProdUsage()=Yes, one cluster with all commercial features and unlimited nodes per cluster.]

[2018-04-15T20:07:25,113][INFO ][c.f.s.c.IndexBaseConfigurationRepository] Search Guard License Type: TRIAL, valid

[2018-04-15T20:07:25,114][INFO ][c.f.s.c.IndexBaseConfigurationRepository] Node ‘LhPFJNW’ initialized

[2018-04-15T20:07:25,364][INFO ][o.e.c.r.a.AllocationService] [LhPFJNW] Cluster health status changed from [RED] to [YELLOW] (reason: [shards started [[.kibana][0]] …]).

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No index-level perm match for User [name=kibanaserver, roles=, requestedTenant=null] [IndexType [index=watcher_alarms, type=*]] [Action [[indices:admin/get]]] [RolesChecked [sg_kibana_server, sg_own_index]]

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No permissions for {sg_own_index=[IndexType [index=watcher_alarms, type=]], sg_kibana_server=[IndexType [index=watcher_alarms, type=]]}

在 2018年4月15日星期日 UTC-4下午8:05:10，Jochen Kressin写道：

sgadmin will replace the current configuration in your cluster with the files located in:

/Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/

So if you want to make changes to the configuration, the easiest way of doing so is to change these files, and then run sgadmin again. According to the output sgadmin has succeeded with uploading the configuration. So your sgadmin command seems fine.

There seems to be something wrong with your Kibana configuration and/or the Search Guard configuration.

What is the output of the Elasticsearch log file? Do you see any error there?

What is the Kibana configuration your are using? Please post it here.

Did you try to restart Kibana and reload the login page?

On Sunday, April 15, 2018 at 4:59:02 PM UTC-7, Xiaoyu Wu wrote:

This is the output of sgadmin tool,

searchguard index already exists, so we do not need to create one.

Populate config from /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/

Will update ‘sg/config’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_config.yml

SUCC: Configuration for ‘config’ created or updated

Will update ‘sg/roles’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_roles.yml

SUCC: Configuration for ‘roles’ created or updated

Will update ‘sg/rolesmapping’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_roles_mapping.yml

SUCC: Configuration for ‘rolesmapping’ created or updated

Will update ‘sg/internalusers’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_internal_users.yml

SUCC: Configuration for ‘internalusers’ created or updated

Will update ‘sg/actiongroups’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_action_groups.yml

SUCC: Configuration for ‘actiongroups’ created or updated

Done with success

And when I restarted the Kibana, it threw me the error saying “An error occurred while checking your credentials, make sure you have an Elasticsearch cluster secured by Search Guard running.”

在 2018年4月15日星期日 UTC-4下午7:56:32，Jochen Kressin写道：

What is the output of the sgadmin tool when you run the command you posted? And what do you see in the Elasticsearch logs when you run sgadmin?

On Sunday, April 15, 2018 at 4:34:56 PM UTC-7, Xiaoyu Wu wrote:

I did not use the demo installer.

I checked the documentation but it is kinda difficult for me to understand the entire implementation. What I did so far is just:

   ./sgadmin.sh \
-cd /path/to/sgconfig/ \
-cacert /path/to/root-ca.pem \
-cert /path/to/kirk.crt.pem \
-key /path/to/kirk.key.pem \
-keypass changeit
-nhnv
-icl

It seems it only applies the default configuration. I did remove the readonly flag in the yml file.

Could you give me a simple example in this case?

在 2018年4月15日星期日 UTC-4下午7:17:14，Jochen Kressin写道：

First, remove the readonly flag from the roles definition (sg_roles.yml) and if you like also for the internal users (sg_internalusers.yml).

If you are using the demo installer, execute sgadmin_demo.sh to apply the changed configuration.

If you have installed Search Guard without the demo installer please refer to the documentation on how to use sgadmin on the command line:

https://docs.search-guard.com/latest/sgadmin

On Sunday, April 15, 2018 at 2:16:40 PM UTC-7, Xiaoyu Wu wrote:

I am currently using elasticsearch 6.2.2 and corresponding search-guard. I have already installed the kibana plugin and got into the GUI.
I am wondering how to change the password for the demo users like admin. The document said set ‘read_only’ to false and apply the sgadmin but I am not sure how to use sgadmin to apply the new changes. What I did before is just to follow the instruction and apply the default configuration.

My purpose is to have my own admin account for the later use case.

[jkressin]

This line in kibana.yml looks suspicious:

searchguard.cookie.name: ‘searchguard_authentication’

And corresponds to the error:

Error: Header value cannot contain or convert into non-ascii characters: set-cookie

Please try to use regular double quotes or comment this line out for the moment.

···

On Sunday, April 15, 2018 at 5:29:07 PM UTC-7, Xiaoyu Wu wrote:

This is the output of Kibana,

log [00:07:55.456] [info][Sentinl][scheduler] scheduled watcher sentinl-watcher:524238a0-345b-11e8-a95a-9954b3f36dde, to run every every 2 minutes

/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hoek/lib/index.js:736

throw new Error(msgs.join(' ') || 'Unknown error');

^

Error: Header value cannot contain or convert into non-ascii characters: set-cookie

at Object.exports.assert (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hoek/lib/index.js:736:11)

at internals.Response._header (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hapi/lib/response.js:141:22)

at request.connection.states.format (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hapi/lib/transmit.js:507:22)

at Items.serial (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/statehood/lib/index.js:436:16)

at done (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/items/lib/index.js:31:25)

at exports.prepareValue (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/statehood/lib/index.js:431:20)

at internals.sign (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/statehood/lib/index.js:461:20)

at process.nextTick (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hoek/lib/index.js:858:22)

at _combinedTickCallback (internal/process/next_tick.js:73:7)

at process._tickDomainCallback (internal/process/next_tick.js:128:9)

在 2018年4月15日星期日 UTC-4下午8:20:39，Xiaoyu Wu写道：

I used to login the kibana page successfully until I customized the login page.

This is the ES config,

======================== Elasticsearch Configuration =========================

NOTE: Elasticsearch comes with reasonable defaults for most settings.

Before you set out to tweak and tune the configuration, make sure you

understand what are you trying to accomplish and the consequences.

The primary way of configuring a node is via this file. This template lists

the most important settings you may want to configure for a production cluster.

Please consult the documentation for further information on configuration options:

https://www.elastic.co/guide/en/elasticsearch/reference/index.html

---------------------------------- Cluster -----------------------------------

Use a descriptive name for your cluster:

#cluster.name: my-application

------------------------------------ Node ------------------------------------

Use a descriptive name for the node:

#node.name: node-1

Add custom attributes to the node:

#node.attr.rack: r1

----------------------------------- Paths ------------------------------------

Path to directory where to store the data (separate multiple locations by comma):

#path.data: /path/to/data

Path to log files:

#path.logs: /path/to/logs

----------------------------------- Memory -----------------------------------

Lock the memory on startup:

#bootstrap.memory_lock: true

Make sure that the heap size is set to about half the memory available

on the system and that the owner of the process is allowed to use this

limit.

Elasticsearch performs poorly when the system is swapping the memory.

---------------------------------- Network -----------------------------------

Set the bind address to a specific IP (IPv4 or IPv6):

#network.host: 192.168.0.1

Set a custom port for HTTP:

#http.port: 9200

For more information, consult the network module documentation.

--------------------------------- Discovery ----------------------------------

Pass an initial list of hosts to perform discovery when new node is started:

The default list of hosts is [“127.0.0.1”, “[::1]”]

#discovery.zen.ping.unicast.hosts: [“host1”, “host2”]

Prevent the “split brain” by configuring the majority of nodes (total number of master-eligible nodes / 2 + 1):

#discovery.zen.minimum_master_nodes:

For more information, consult the zen discovery module documentation.

---------------------------------- Gateway -----------------------------------

Block initial recovery after a full cluster restart until N nodes are started:

#gateway.recover_after_nodes: 3

For more information, consult the gateway module documentation.

---------------------------------- Various -----------------------------------

Require explicit names when deleting indices:

#action.destructive_requires_name: true

---------------------------------- Search Guard ------------------------------

searchguard.authcz.admin_dn:

• CN=kirk,OU=client,O=client,L=Test,C=DE

Relative path to the certificates key file (PKCS #8), must be placed under the config/ dir

searchguard.ssl.transport.pemkey_filepath: node-0.key.pem

Key password (omit this setting if the key has no password)

#searchguard.ssl.transport.pemkey_password: “secret”

X509 node certificate chain in PEM format, must be placed under the config/ dir

searchguard.ssl.transport.pemcert_filepath: node-0.crt.pem

Trusted certificates

searchguard.ssl.transport.pemtrustedcas_filepath: chain-ca.pem

searchguard.restapi.roles_enabled: [“sg_all_access”]

This is the Kibana,

Kibana is served by a back end server. This setting specifies the port to use.

#server.port: 5601

Specifies the address to which the Kibana server will bind. IP addresses and host names are both valid values.

The default is ‘localhost’, which usually means remote machines will not be able to connect.

To allow connections from remote users, set this parameter to a non-loopback address.

#server.host: “localhost”

Enables you to specify a path to mount Kibana at if you are running behind a proxy. This only affects

the URLs generated by Kibana, your proxy is expected to remove the basePath value before forwarding requests

to Kibana. This setting cannot end in a slash.

#server.basePath: “”

The maximum payload size in bytes for incoming server requests.

#server.maxPayloadBytes: 1048576

The Kibana server’s name. This is used for display purposes.

#server.name: “your-hostname”

The URL of the Elasticsearch instance to use for all your queries.

#elasticsearch.url: “http://localhost:9200”

When this setting’s value is true Kibana uses the hostname specified in the server.host

setting. When the value of this setting is false, Kibana uses the hostname of the host

that connects to this Kibana instance.

#elasticsearch.preserveHost: true

Kibana uses an index in Elasticsearch to store saved searches, visualizations and

dashboards. Kibana creates a new index if the index doesn’t already exist.

#kibana.index: “.kibana”

The default application to load.

#kibana.defaultAppId: “home”

If your Elasticsearch is protected with basic authentication, these settings provide

the username and password that the Kibana server uses to perform maintenance on the Kibana

index at startup. Your Kibana users still need to authenticate with Elasticsearch, which

is proxied through the Kibana server.

#elasticsearch.username: “kibana”

#elasticsearch.password: “BioEPQ1o51gAyIsQYaWc”

Enables SSL and paths to the PEM-format SSL certificate and SSL key files, respectively.

These settings enable SSL for outgoing requests from the Kibana server to the browser.

#server.ssl.enabled: false

#server.ssl.certificate: /path/to/your/server.crt

#server.ssl.key: /path/to/your/server.key

Optional settings that provide the paths to the PEM-format SSL certificate and key files.

These files validate that your Elasticsearch backend uses the same key files.

#elasticsearch.ssl.certificate: /path/to/your/client.crt

#elasticsearch.ssl.key: /path/to/your/client.key

Optional setting that enables you to specify a path to the PEM file for the certificate

authority for your Elasticsearch instance.

#elasticsearch.ssl.certificateAuthorities: [ “/path/to/your/CA.pem” ]

To disregard the validity of SSL certificates, change this setting’s value to ‘none’.

#elasticsearch.ssl.verificationMode: full

Time in milliseconds to wait for Elasticsearch to respond to pings. Defaults to the value of

the elasticsearch.requestTimeout setting.

#elasticsearch.pingTimeout: 1500

Time in milliseconds to wait for responses from the back end or Elasticsearch. This value

must be a positive integer.

#elasticsearch.requestTimeout: 30000

List of Kibana client-side headers to send to Elasticsearch. To send no client-side

headers, set this value to (an empty list).

#elasticsearch.requestHeadersWhitelist: [ authorization ]

Header names and values that are sent to Elasticsearch. Any custom headers cannot be overwritten

by client-side headers, regardless of the elasticsearch.requestHeadersWhitelist configuration.

#elasticsearch.customHeaders: {}

Time in milliseconds for Elasticsearch to wait for responses from shards. Set to 0 to disable.

#elasticsearch.shardTimeout: 0

Time in milliseconds to wait for Elasticsearch at Kibana startup before retrying.

#elasticsearch.startupTimeout: 5000

Specifies the path where Kibana creates the process ID file.

#pid.file: /var/run/kibana.pid

Enables you specify a file where Kibana stores log output.

#logging.dest: stdout

Set the value of this setting to true to suppress all logging output.

#logging.silent: false

Set the value of this setting to true to suppress all logging output other than error messages.

#logging.quiet: false

Set the value of this setting to true to log all events, including system usage information

and all requests.

#logging.verbose: false

Set the interval in milliseconds to sample system and process performance

metrics. Minimum is 100ms. Defaults to 5000.

#ops.interval: 5000

The default locale. This locale can be used in certain circumstances to substitute any missing

translations.

#i18n.defaultLocale: “en”

Config of Sentinl

sentinl:

settings:

email:

active: true

user: ------

password: -------

host: -------

ssl: true

timeout: 10000

elasticsearch.username: “kibanaserver”

elasticsearch.password: “kibanaserver”

elasticsearch.ssl.verificationMode: none

Login Page

searchguard.basicauth.login.showbrandimage: true

searchguard.basicauth.login.brandimage: https://www.symantec.com/content/dam/symantec/images/common/symantec-logo-top.png

searchguard.cookie.name: ‘searchguard_authentication’

#searchguard.basicauth.login.title

#searchguard.basicauth.login.subtitle

This is the sg_roles,

#<sg_role_name>:

cluster:

- ‘’

indices:

‘’:

‘’:

- ‘’

dls: ‘’

fls:

- ‘’

- ‘’

When a user make a request to Elasticsearch then the following roles will be evaluated to see if the user has

permissions for the request. A request is always associated with an action and is executed against and index (or alias)

and a type. If a request is executed against all indices (or all types) then the asterix (‘*’) is needed.

Every role a user has will be examined if it allows the action against an index (or type). At least one role must match

for the request to be successful. If no role match then the request will be denied. Currently a match must happen within

one single role - that means that permissions can not span multiple roles.

For , and simple wildcards and regular expressions are possible.

A asterix (*) will match any character sequence (or an empty sequence)

A question mark (?) will match any single character (but NOT empty character)

Example: ‘myindex’ will match ‘my_first_index’ as well as ‘myindex’ but not ‘myindex1’

Example: ‘?kibana’ will match ‘.kibana’ but not ‘kibana’

To use a full blown regex you have to pre- and apend a ‘/’ to use regex instead of simple wildcards

‘//’

Example: ‘/\S*/’ will match any non whitespace characters

Important:

Index, alias or type names can not contain dots (.) in the or expression.

Reason is that we currently parse the config file into a elasticsearch settings object which cannot cope with dots in keys.

Workaround: Just configure something like ‘?kibana’ instead of ‘.kibana’ or ‘my?index’ instead of ‘my.index’

This limitation will likely removed with Search Guard 6

DLS (Document level security) - NOT FREE FOR COMMERCIAL

http://docs.search-guard.com/v6/document-level-security

FLS (Field level security) - NOT FREE FOR COMMERCIAL

http://docs.search-guard.com/v6/field-level-security

Kibana multitenancy - NOT FREE FOR COMMERCIAL

http://docs.search-guard.com/v6/kibana-multi-tenancy

Allows everything, but no changes to searchguard configuration index

sg_all_access:

readonly: true

cluster:

• UNLIMITED

indices:

‘*’:

‘*’:

• UNLIMITED

tenants:

admin_tenant: RW

Read all, but no write permissions

sg_readall:

readonly: true

cluster:

• CLUSTER_COMPOSITE_OPS_RO

indices:

‘*’:

‘*’:

• READ

Read all and monitor, but no write permissions

sg_readall_and_monitor:

cluster:

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS_RO

indices:

‘*’:

‘*’:

• READ

For users which use kibana, access to indices must be granted separately

sg_kibana_user:

readonly: true

cluster:

• MONITOR

• CLUSTER_COMPOSITE_OPS_RO

indices:

‘?kibana’:

‘*’:

• MANAGE

• INDEX

• READ

• DELETE

‘*’:

‘*’:

• indices:data/read/field_caps*

For the kibana server

sg_kibana_server:

readonly: true

cluster:

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS

• cluster:admin/xpack/monitoring*

• indices:admin/template*

indices:

‘?kibana’:

‘*’:

• INDICES_ALL

‘?reporting*’:

‘*’:

• INDICES_ALL

‘?monitoring*’:

‘*’:

• INDICES_ALL

For logstash and beats

sg_logstash:

cluster:

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS

• indices:admin/template/get

• indices:admin/template/put

indices:

‘logstash-*’:

‘*’:

• CRUD

• CREATE_INDEX

‘beat’:

‘*’:

• CRUD

• CREATE_INDEX

Allows adding and modifying repositories and creating and restoring snapshots

sg_manage_snapshots:

cluster:

• MANAGE_SNAPSHOTS

indices:

‘*’:

‘*’:

• “indices:data/write/index”

• “indices:admin/create”

Allows each user to access own named index

sg_own_index:

cluster:

• CLUSTER_COMPOSITE_OPS

indices:

‘${user_name}’:

‘*’:

• INDICES_ALL

X-Pack COMPATIBILITY

sg_xp_monitoring:

readonly: true

indices:

‘?monitor*’:

‘*’:

• INDICES_ALL

sg_xp_alerting:

readonly: true

cluster:

• indices:data/read/scroll

• cluster:admin/xpack/watcher*

• cluster:monitor/xpack/watcher*

indices:

‘?watches*’:

‘*’:

• INDICES_ALL

‘?watcher-history-*’:

‘*’:

• INDICES_ALL

‘?triggered_watches’:

‘*’:

• INDICES_ALL

‘*’:

‘*’:

• READ

• indices:admin/aliases/get

sg_xp_machine_learning:

readonly: true

cluster:

• cluster:admin/persistent*

• cluster:internal/xpack/ml*

• indices:data/read/scroll*

• cluster:admin/xpack/ml*

• cluster:monitor/xpack/ml*

indices:

‘*’:

‘*’:

• READ

• indices:admin/get*

‘?ml-*’:

‘*’:

• “*”

LEGACY ROLES, FOR COMPATIBILITY ONLY

WILL BE REMOVED IN SG7, DO NOT USE ANYMORE

sg_readonly_and_monitor:

cluster:

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS_RO

indices:

‘*’:

‘*’:

• READ

Make xpack monitoring work

sg_monitor:

cluster:

• cluster:admin/xpack/monitoring/*

• cluster:admin/ingest/pipeline/put

• cluster:admin/ingest/pipeline/get

• indices:admin/template/get

• indices:admin/template/put

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS

indices:

‘?monitor*’:

‘*’:

• INDICES_ALL

‘?marvel*’:

‘*’:

• INDICES_ALL

‘?kibana*’:

‘*’:

• READ

‘*’:

‘*’:

• indices:data/read/field_caps

Make xpack alerting work

sg_alerting:

cluster:

• indices:data/read/scroll

• cluster:admin/xpack/watcher/watch/put

• cluster:admin/xpack/watcher*

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS

indices:

‘?kibana*’:

‘*’:

• READ

‘?watches*’:

‘*’:

• INDICES_ALL

‘?watcher-history-*’:

‘*’:

• INDICES_ALL

‘?triggered_watches’:

‘*’:

• INDICES_ALL

‘*’:

‘*’:

• READ

在 2018年4月15日星期日 UTC-4下午8:15:42，Jochen Kressin写道：

So it seems you also have installed X-Pack and there is an error with your watcher configuration:

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No index-level perm match for User [name=kibanaserver, roles=, requestedTenant=null] [IndexType [index=watcher_alarms, type=*]] [Action [[indices:admin/get]]] [RolesChecked [sg_kibana_server, sg_own_index]]

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No permissions for {sg_own_index=[IndexType [index=watcher_alarms, type=]], sg_kibana_server=[IndexType [index=watcher_alarms, type=]]}

Please post at least:

• kibana.yml

• elasticsearch.yml

• sg_roles.yml

Just remove any sensitive information like paths and passwords.

On Sunday, April 15, 2018 at 5:11:26 PM UTC-7, Xiaoyu Wu wrote:

I checked localhost:9200/_authinfo and the elasticsearch looks good.

This is a part of my kibana config (the rest is the default)

elasticsearch.username: “kibanaserver”

elasticsearch.password: “kibanaserver”

elasticsearch.ssl.verificationMode: none

Login Page

searchguard.basicauth.login.showbrandimage: true

searchguard.basicauth.login.brandimage: https://www.symantec.com/content/dam/symantec/images/common/symantec-logo-top.png

searchguard.cookie.name: ‘searchguard_authentication’

#searchguard.basicauth.login.title

#searchguard.basicauth.login.subtitle

This is the output of elasticsearch log,

[2018-04-15T20:07:25,113][INFO ][c.f.s.c.IndexBaseConfigurationRepository] Search Guard License Info: SearchGuardLicense [uid=00000000-0000-0000-0000-000000000000, type=TRIAL, issueDate=2018-04-15, expiryDate=2018-06-15, issuedTo=The world, issuer=floragunn GmbH, startDate=2018-04-15, majorVersion=6, clusterName=*, allowedNodeCount=2147483647, msgs=, expiresInDays=60, isExpired=false, valid=true, action=, prodUsage=Yes, one cluster with all commercial features and unlimited nodes per cluster., clusterService=org.elasticsearch.cluster.service.ClusterService@2e500df4, getMsgs()=, getExpiresInDays()=60, isExpired()=false, isValid()=true, getAction()=, getProdUsage()=Yes, one cluster with all commercial features and unlimited nodes per cluster.]

[2018-04-15T20:07:25,113][INFO ][c.f.s.c.IndexBaseConfigurationRepository] Search Guard License Type: TRIAL, valid

[2018-04-15T20:07:25,114][INFO ][c.f.s.c.IndexBaseConfigurationRepository] Node ‘LhPFJNW’ initialized

[2018-04-15T20:07:25,364][INFO ][o.e.c.r.a.AllocationService] [LhPFJNW] Cluster health status changed from [RED] to [YELLOW] (reason: [shards started [[.kibana][0]] …]).

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No index-level perm match for User [name=kibanaserver, roles=, requestedTenant=null] [IndexType [index=watcher_alarms, type=*]] [Action [[indices:admin/get]]] [RolesChecked [sg_kibana_server, sg_own_index]]

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No permissions for {sg_own_index=[IndexType [index=watcher_alarms, type=]], sg_kibana_server=[IndexType [index=watcher_alarms, type=]]}

在 2018年4月15日星期日 UTC-4下午8:05:10，Jochen Kressin写道：

sgadmin will replace the current configuration in your cluster with the files located in:

/Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/

So if you want to make changes to the configuration, the easiest way of doing so is to change these files, and then run sgadmin again. According to the output sgadmin has succeeded with uploading the configuration. So your sgadmin command seems fine.

There seems to be something wrong with your Kibana configuration and/or the Search Guard configuration.

What is the output of the Elasticsearch log file? Do you see any error there?

What is the Kibana configuration your are using? Please post it here.

Did you try to restart Kibana and reload the login page?

On Sunday, April 15, 2018 at 4:59:02 PM UTC-7, Xiaoyu Wu wrote:

This is the output of sgadmin tool,

searchguard index already exists, so we do not need to create one.

Populate config from /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/

Will update ‘sg/config’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_config.yml

SUCC: Configuration for ‘config’ created or updated

Will update ‘sg/roles’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_roles.yml

SUCC: Configuration for ‘roles’ created or updated

Will update ‘sg/rolesmapping’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_roles_mapping.yml

SUCC: Configuration for ‘rolesmapping’ created or updated

Will update ‘sg/internalusers’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_internal_users.yml

SUCC: Configuration for ‘internalusers’ created or updated

Will update ‘sg/actiongroups’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_action_groups.yml

SUCC: Configuration for ‘actiongroups’ created or updated

Done with success

And when I restarted the Kibana, it threw me the error saying “An error occurred while checking your credentials, make sure you have an Elasticsearch cluster secured by Search Guard running.”

在 2018年4月15日星期日 UTC-4下午7:56:32，Jochen Kressin写道：

What is the output of the sgadmin tool when you run the command you posted? And what do you see in the Elasticsearch logs when you run sgadmin?

On Sunday, April 15, 2018 at 4:34:56 PM UTC-7, Xiaoyu Wu wrote:

I did not use the demo installer.

I checked the documentation but it is kinda difficult for me to understand the entire implementation. What I did so far is just:

   ./sgadmin.sh \
-cd /path/to/sgconfig/ \
-cacert /path/to/root-ca.pem \
-cert /path/to/kirk.crt.pem \
-key /path/to/kirk.key.pem \
-keypass changeit
-nhnv
-icl

It seems it only applies the default configuration. I did remove the readonly flag in the yml file.

Could you give me a simple example in this case?

在 2018年4月15日星期日 UTC-4下午7:17:14，Jochen Kressin写道：

First, remove the readonly flag from the roles definition (sg_roles.yml) and if you like also for the internal users (sg_internalusers.yml).

If you are using the demo installer, execute sgadmin_demo.sh to apply the changed configuration.

If you have installed Search Guard without the demo installer please refer to the documentation on how to use sgadmin on the command line:

https://docs.search-guard.com/latest/sgadmin

On Sunday, April 15, 2018 at 2:16:40 PM UTC-7, Xiaoyu Wu wrote:

I am currently using elasticsearch 6.2.2 and corresponding search-guard. I have already installed the kibana plugin and got into the GUI.
I am wondering how to change the password for the demo users like admin. The document said set ‘read_only’ to false and apply the sgadmin but I am not sure how to use sgadmin to apply the new changes. What I did before is just to follow the instruction and apply the default configuration.

My purpose is to have my own admin account for the later use case.

[Xiaoyu_Wu]

I just removed that line, and it solved the login issue.

Thank you so much!

But it seems the “admin” user is still reserved.

Here is a part of code in my sg_internal_users.yml,

#password is: admin

admin:

readonly: false

hash: *******************

roles:

• admin

attributes:

#no dots allowed in attribute names

attribute1: value1

attribute2: value2

attribute3: value3

在 2018年4月15日星期日 UTC-4下午8:32:22，Jochen Kressin写道：

···

This line in kibana.yml looks suspicious:

searchguard.cookie.name: ‘searchguard_authentication’

And corresponds to the error:

Error: Header value cannot contain or convert into non-ascii characters: set-cookie

Please try to use regular double quotes or comment this line out for the moment.

On Sunday, April 15, 2018 at 5:29:07 PM UTC-7, Xiaoyu Wu wrote:

This is the output of Kibana,

log [00:07:55.456] [info][Sentinl][scheduler] scheduled watcher sentinl-watcher:524238a0-345b-11e8-a95a-9954b3f36dde, to run every every 2 minutes

/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hoek/lib/index.js:736

throw new Error(msgs.join(' ') || 'Unknown error');

^

Error: Header value cannot contain or convert into non-ascii characters: set-cookie

at Object.exports.assert (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hoek/lib/index.js:736:11)

at internals.Response._header (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hapi/lib/response.js:141:22)

at request.connection.states.format (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hapi/lib/transmit.js:507:22)

at Items.serial (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/statehood/lib/index.js:436:16)

at done (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/items/lib/index.js:31:25)

at exports.prepareValue (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/statehood/lib/index.js:431:20)

at internals.sign (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/statehood/lib/index.js:461:20)

at process.nextTick (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hoek/lib/index.js:858:22)

at _combinedTickCallback (internal/process/next_tick.js:73:7)

at process._tickDomainCallback (internal/process/next_tick.js:128:9)

在 2018年4月15日星期日 UTC-4下午8:20:39，Xiaoyu Wu写道：

I used to login the kibana page successfully until I customized the login page.

This is the ES config,

======================== Elasticsearch Configuration =========================

NOTE: Elasticsearch comes with reasonable defaults for most settings.

Before you set out to tweak and tune the configuration, make sure you

understand what are you trying to accomplish and the consequences.

The primary way of configuring a node is via this file. This template lists

the most important settings you may want to configure for a production cluster.

Please consult the documentation for further information on configuration options:

https://www.elastic.co/guide/en/elasticsearch/reference/index.html

---------------------------------- Cluster -----------------------------------

Use a descriptive name for your cluster:

#cluster.name: my-application

------------------------------------ Node ------------------------------------

Use a descriptive name for the node:

#node.name: node-1

Add custom attributes to the node:

#node.attr.rack: r1

----------------------------------- Paths ------------------------------------

Path to directory where to store the data (separate multiple locations by comma):

#path.data: /path/to/data

Path to log files:

#path.logs: /path/to/logs

----------------------------------- Memory -----------------------------------

Lock the memory on startup:

#bootstrap.memory_lock: true

Make sure that the heap size is set to about half the memory available

on the system and that the owner of the process is allowed to use this

limit.

Elasticsearch performs poorly when the system is swapping the memory.

---------------------------------- Network -----------------------------------

Set the bind address to a specific IP (IPv4 or IPv6):

#network.host: 192.168.0.1

Set a custom port for HTTP:

#http.port: 9200

For more information, consult the network module documentation.

--------------------------------- Discovery ----------------------------------

Pass an initial list of hosts to perform discovery when new node is started:

The default list of hosts is [“127.0.0.1”, “[::1]”]

#discovery.zen.ping.unicast.hosts: [“host1”, “host2”]

Prevent the “split brain” by configuring the majority of nodes (total number of master-eligible nodes / 2 + 1):

#discovery.zen.minimum_master_nodes:

For more information, consult the zen discovery module documentation.

---------------------------------- Gateway -----------------------------------

Block initial recovery after a full cluster restart until N nodes are started:

#gateway.recover_after_nodes: 3

For more information, consult the gateway module documentation.

---------------------------------- Various -----------------------------------

Require explicit names when deleting indices:

#action.destructive_requires_name: true

---------------------------------- Search Guard ------------------------------

searchguard.authcz.admin_dn:

• CN=kirk,OU=client,O=client,L=Test,C=DE

Relative path to the certificates key file (PKCS #8), must be placed under the config/ dir

searchguard.ssl.transport.pemkey_filepath: node-0.key.pem

Key password (omit this setting if the key has no password)

#searchguard.ssl.transport.pemkey_password: “secret”

X509 node certificate chain in PEM format, must be placed under the config/ dir

searchguard.ssl.transport.pemcert_filepath: node-0.crt.pem

Trusted certificates

searchguard.ssl.transport.pemtrustedcas_filepath: chain-ca.pem

searchguard.restapi.roles_enabled: [“sg_all_access”]

This is the Kibana,

Kibana is served by a back end server. This setting specifies the port to use.

#server.port: 5601

Specifies the address to which the Kibana server will bind. IP addresses and host names are both valid values.

The default is ‘localhost’, which usually means remote machines will not be able to connect.

To allow connections from remote users, set this parameter to a non-loopback address.

#server.host: “localhost”

Enables you to specify a path to mount Kibana at if you are running behind a proxy. This only affects

the URLs generated by Kibana, your proxy is expected to remove the basePath value before forwarding requests

to Kibana. This setting cannot end in a slash.

#server.basePath: “”

The maximum payload size in bytes for incoming server requests.

#server.maxPayloadBytes: 1048576

The Kibana server’s name. This is used for display purposes.

#server.name: “your-hostname”

The URL of the Elasticsearch instance to use for all your queries.

#elasticsearch.url: “http://localhost:9200”

When this setting’s value is true Kibana uses the hostname specified in the server.host

setting. When the value of this setting is false, Kibana uses the hostname of the host

that connects to this Kibana instance.

#elasticsearch.preserveHost: true

Kibana uses an index in Elasticsearch to store saved searches, visualizations and

dashboards. Kibana creates a new index if the index doesn’t already exist.

#kibana.index: “.kibana”

The default application to load.

#kibana.defaultAppId: “home”

If your Elasticsearch is protected with basic authentication, these settings provide

the username and password that the Kibana server uses to perform maintenance on the Kibana

index at startup. Your Kibana users still need to authenticate with Elasticsearch, which

is proxied through the Kibana server.

#elasticsearch.username: “kibana”

#elasticsearch.password: “BioEPQ1o51gAyIsQYaWc”

Enables SSL and paths to the PEM-format SSL certificate and SSL key files, respectively.

These settings enable SSL for outgoing requests from the Kibana server to the browser.

#server.ssl.enabled: false

#server.ssl.certificate: /path/to/your/server.crt

#server.ssl.key: /path/to/your/server.key

Optional settings that provide the paths to the PEM-format SSL certificate and key files.

These files validate that your Elasticsearch backend uses the same key files.

#elasticsearch.ssl.certificate: /path/to/your/client.crt

#elasticsearch.ssl.key: /path/to/your/client.key

Optional setting that enables you to specify a path to the PEM file for the certificate

authority for your Elasticsearch instance.

#elasticsearch.ssl.certificateAuthorities: [ “/path/to/your/CA.pem” ]

To disregard the validity of SSL certificates, change this setting’s value to ‘none’.

#elasticsearch.ssl.verificationMode: full

Time in milliseconds to wait for Elasticsearch to respond to pings. Defaults to the value of

the elasticsearch.requestTimeout setting.

#elasticsearch.pingTimeout: 1500

Time in milliseconds to wait for responses from the back end or Elasticsearch. This value

must be a positive integer.

#elasticsearch.requestTimeout: 30000

List of Kibana client-side headers to send to Elasticsearch. To send no client-side

headers, set this value to (an empty list).

#elasticsearch.requestHeadersWhitelist: [ authorization ]

Header names and values that are sent to Elasticsearch. Any custom headers cannot be overwritten

by client-side headers, regardless of the elasticsearch.requestHeadersWhitelist configuration.

#elasticsearch.customHeaders: {}

Time in milliseconds for Elasticsearch to wait for responses from shards. Set to 0 to disable.

#elasticsearch.shardTimeout: 0

Time in milliseconds to wait for Elasticsearch at Kibana startup before retrying.

#elasticsearch.startupTimeout: 5000

Specifies the path where Kibana creates the process ID file.

#pid.file: /var/run/kibana.pid

Enables you specify a file where Kibana stores log output.

#logging.dest: stdout

Set the value of this setting to true to suppress all logging output.

#logging.silent: false

Set the value of this setting to true to suppress all logging output other than error messages.

#logging.quiet: false

Set the value of this setting to true to log all events, including system usage information

and all requests.

#logging.verbose: false

Set the interval in milliseconds to sample system and process performance

metrics. Minimum is 100ms. Defaults to 5000.

#ops.interval: 5000

The default locale. This locale can be used in certain circumstances to substitute any missing

translations.

#i18n.defaultLocale: “en”

Config of Sentinl

sentinl:

settings:

email:

active: true

user: ------

password: -------

host: -------

ssl: true

timeout: 10000

elasticsearch.username: “kibanaserver”

elasticsearch.password: “kibanaserver”

elasticsearch.ssl.verificationMode: none

Login Page

searchguard.basicauth.login.showbrandimage: true

searchguard.basicauth.login.brandimage: https://www.symantec.com/content/dam/symantec/images/common/symantec-logo-top.png

searchguard.cookie.name: ‘searchguard_authentication’

#searchguard.basicauth.login.title

#searchguard.basicauth.login.subtitle

This is the sg_roles,

#<sg_role_name>:

cluster:

- ‘’

indices:

‘’:

‘’:

- ‘’

dls: ‘’

fls:

- ‘’

- ‘’

When a user make a request to Elasticsearch then the following roles will be evaluated to see if the user has

permissions for the request. A request is always associated with an action and is executed against and index (or alias)

and a type. If a request is executed against all indices (or all types) then the asterix (‘*’) is needed.

Every role a user has will be examined if it allows the action against an index (or type). At least one role must match

for the request to be successful. If no role match then the request will be denied. Currently a match must happen within

one single role - that means that permissions can not span multiple roles.

For , and simple wildcards and regular expressions are possible.

A asterix (*) will match any character sequence (or an empty sequence)

A question mark (?) will match any single character (but NOT empty character)

Example: ‘myindex’ will match ‘my_first_index’ as well as ‘myindex’ but not ‘myindex1’

Example: ‘?kibana’ will match ‘.kibana’ but not ‘kibana’

To use a full blown regex you have to pre- and apend a ‘/’ to use regex instead of simple wildcards

‘//’

Example: ‘/\S*/’ will match any non whitespace characters

Important:

Index, alias or type names can not contain dots (.) in the or expression.

Reason is that we currently parse the config file into a elasticsearch settings object which cannot cope with dots in keys.

Workaround: Just configure something like ‘?kibana’ instead of ‘.kibana’ or ‘my?index’ instead of ‘my.index’

This limitation will likely removed with Search Guard 6

DLS (Document level security) - NOT FREE FOR COMMERCIAL

http://docs.search-guard.com/v6/document-level-security

FLS (Field level security) - NOT FREE FOR COMMERCIAL

http://docs.search-guard.com/v6/field-level-security

Kibana multitenancy - NOT FREE FOR COMMERCIAL

http://docs.search-guard.com/v6/kibana-multi-tenancy

Allows everything, but no changes to searchguard configuration index

sg_all_access:

readonly: true

cluster:

• UNLIMITED

indices:

‘*’:

‘*’:

• UNLIMITED

tenants:

admin_tenant: RW

Read all, but no write permissions

sg_readall:

readonly: true

cluster:

• CLUSTER_COMPOSITE_OPS_RO

indices:

‘*’:

‘*’:

• READ

Read all and monitor, but no write permissions

sg_readall_and_monitor:

cluster:

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS_RO

indices:

‘*’:

‘*’:

• READ

For users which use kibana, access to indices must be granted separately

sg_kibana_user:

readonly: true

cluster:

• MONITOR

• CLUSTER_COMPOSITE_OPS_RO

indices:

‘?kibana’:

‘*’:

• MANAGE

• INDEX

• READ

• DELETE

‘*’:

‘*’:

• indices:data/read/field_caps*

For the kibana server

sg_kibana_server:

readonly: true

cluster:

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS

• cluster:admin/xpack/monitoring*

• indices:admin/template*

indices:

‘?kibana’:

‘*’:

• INDICES_ALL

‘?reporting*’:

‘*’:

• INDICES_ALL

‘?monitoring*’:

‘*’:

• INDICES_ALL

For logstash and beats

sg_logstash:

cluster:

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS

• indices:admin/template/get

• indices:admin/template/put

indices:

‘logstash-*’:

‘*’:

• CRUD

• CREATE_INDEX

‘beat’:

‘*’:

• CRUD

• CREATE_INDEX

Allows adding and modifying repositories and creating and restoring snapshots

sg_manage_snapshots:

cluster:

• MANAGE_SNAPSHOTS

indices:

‘*’:

‘*’:

• “indices:data/write/index”

• “indices:admin/create”

Allows each user to access own named index

sg_own_index:

cluster:

• CLUSTER_COMPOSITE_OPS

indices:

‘${user_name}’:

‘*’:

• INDICES_ALL

X-Pack COMPATIBILITY

sg_xp_monitoring:

readonly: true

indices:

‘?monitor*’:

‘*’:

• INDICES_ALL

sg_xp_alerting:

readonly: true

cluster:

• indices:data/read/scroll

• cluster:admin/xpack/watcher*

• cluster:monitor/xpack/watcher*

indices:

‘?watches*’:

‘*’:

• INDICES_ALL

‘?watcher-history-*’:

‘*’:

• INDICES_ALL

‘?triggered_watches’:

‘*’:

• INDICES_ALL

‘*’:

‘*’:

• READ

• indices:admin/aliases/get

sg_xp_machine_learning:

readonly: true

cluster:

• cluster:admin/persistent*

• cluster:internal/xpack/ml*

• indices:data/read/scroll*

• cluster:admin/xpack/ml*

• cluster:monitor/xpack/ml*

indices:

‘*’:

‘*’:

• READ

• indices:admin/get*

‘?ml-*’:

‘*’:

• “*”

LEGACY ROLES, FOR COMPATIBILITY ONLY

WILL BE REMOVED IN SG7, DO NOT USE ANYMORE

sg_readonly_and_monitor:

cluster:

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS_RO

indices:

‘*’:

‘*’:

• READ

Make xpack monitoring work

sg_monitor:

cluster:

• cluster:admin/xpack/monitoring/*

• cluster:admin/ingest/pipeline/put

• cluster:admin/ingest/pipeline/get

• indices:admin/template/get

• indices:admin/template/put

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS

indices:

‘?monitor*’:

‘*’:

• INDICES_ALL

‘?marvel*’:

‘*’:

• INDICES_ALL

‘?kibana*’:

‘*’:

• READ

‘*’:

‘*’:

• indices:data/read/field_caps

Make xpack alerting work

sg_alerting:

cluster:

• indices:data/read/scroll

• cluster:admin/xpack/watcher/watch/put

• cluster:admin/xpack/watcher*

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS

indices:

‘?kibana*’:

‘*’:

• READ

‘?watches*’:

‘*’:

• INDICES_ALL

‘?watcher-history-*’:

‘*’:

• INDICES_ALL

‘?triggered_watches’:

‘*’:

• INDICES_ALL

‘*’:

‘*’:

• READ

在 2018年4月15日星期日 UTC-4下午8:15:42，Jochen Kressin写道：

So it seems you also have installed X-Pack and there is an error with your watcher configuration:

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No index-level perm match for User [name=kibanaserver, roles=, requestedTenant=null] [IndexType [index=watcher_alarms, type=*]] [Action [[indices:admin/get]]] [RolesChecked [sg_kibana_server, sg_own_index]]

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No permissions for {sg_own_index=[IndexType [index=watcher_alarms, type=]], sg_kibana_server=[IndexType [index=watcher_alarms, type=]]}

Please post at least:

• kibana.yml

• elasticsearch.yml

• sg_roles.yml

Just remove any sensitive information like paths and passwords.

On Sunday, April 15, 2018 at 5:11:26 PM UTC-7, Xiaoyu Wu wrote:

I checked localhost:9200/_authinfo and the elasticsearch looks good.

This is a part of my kibana config (the rest is the default)

elasticsearch.username: “kibanaserver”

elasticsearch.password: “kibanaserver”

elasticsearch.ssl.verificationMode: none

Login Page

searchguard.basicauth.login.showbrandimage: true

searchguard.basicauth.login.brandimage: https://www.symantec.com/content/dam/symantec/images/common/symantec-logo-top.png

searchguard.cookie.name: ‘searchguard_authentication’

#searchguard.basicauth.login.title

#searchguard.basicauth.login.subtitle

This is the output of elasticsearch log,

[2018-04-15T20:07:25,113][INFO ][c.f.s.c.IndexBaseConfigurationRepository] Search Guard License Info: SearchGuardLicense [uid=00000000-0000-0000-0000-000000000000, type=TRIAL, issueDate=2018-04-15, expiryDate=2018-06-15, issuedTo=The world, issuer=floragunn GmbH, startDate=2018-04-15, majorVersion=6, clusterName=*, allowedNodeCount=2147483647, msgs=, expiresInDays=60, isExpired=false, valid=true, action=, prodUsage=Yes, one cluster with all commercial features and unlimited nodes per cluster., clusterService=org.elasticsearch.cluster.service.ClusterService@2e500df4, getMsgs()=, getExpiresInDays()=60, isExpired()=false, isValid()=true, getAction()=, getProdUsage()=Yes, one cluster with all commercial features and unlimited nodes per cluster.]

[2018-04-15T20:07:25,113][INFO ][c.f.s.c.IndexBaseConfigurationRepository] Search Guard License Type: TRIAL, valid

[2018-04-15T20:07:25,114][INFO ][c.f.s.c.IndexBaseConfigurationRepository] Node ‘LhPFJNW’ initialized

[2018-04-15T20:07:25,364][INFO ][o.e.c.r.a.AllocationService] [LhPFJNW] Cluster health status changed from [RED] to [YELLOW] (reason: [shards started [[.kibana][0]] …]).

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No index-level perm match for User [name=kibanaserver, roles=, requestedTenant=null] [IndexType [index=watcher_alarms, type=*]] [Action [[indices:admin/get]]] [RolesChecked [sg_kibana_server, sg_own_index]]

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No permissions for {sg_own_index=[IndexType [index=watcher_alarms, type=]], sg_kibana_server=[IndexType [index=watcher_alarms, type=]]}

在 2018年4月15日星期日 UTC-4下午8:05:10，Jochen Kressin写道：

sgadmin will replace the current configuration in your cluster with the files located in:

/Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/

So if you want to make changes to the configuration, the easiest way of doing so is to change these files, and then run sgadmin again. According to the output sgadmin has succeeded with uploading the configuration. So your sgadmin command seems fine.

There seems to be something wrong with your Kibana configuration and/or the Search Guard configuration.

What is the output of the Elasticsearch log file? Do you see any error there?

What is the Kibana configuration your are using? Please post it here.

Did you try to restart Kibana and reload the login page?

On Sunday, April 15, 2018 at 4:59:02 PM UTC-7, Xiaoyu Wu wrote:

This is the output of sgadmin tool,

searchguard index already exists, so we do not need to create one.

Populate config from /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/

Will update ‘sg/config’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_config.yml

SUCC: Configuration for ‘config’ created or updated

Will update ‘sg/roles’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_roles.yml

SUCC: Configuration for ‘roles’ created or updated

Will update ‘sg/rolesmapping’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_roles_mapping.yml

SUCC: Configuration for ‘rolesmapping’ created or updated

Will update ‘sg/internalusers’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_internal_users.yml

SUCC: Configuration for ‘internalusers’ created or updated

Will update ‘sg/actiongroups’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_action_groups.yml

SUCC: Configuration for ‘actiongroups’ created or updated

Done with success

And when I restarted the Kibana, it threw me the error saying “An error occurred while checking your credentials, make sure you have an Elasticsearch cluster secured by Search Guard running.”

在 2018年4月15日星期日 UTC-4下午7:56:32，Jochen Kressin写道：

What is the output of the sgadmin tool when you run the command you posted? And what do you see in the Elasticsearch logs when you run sgadmin?

On Sunday, April 15, 2018 at 4:34:56 PM UTC-7, Xiaoyu Wu wrote:

I did not use the demo installer.

I checked the documentation but it is kinda difficult for me to understand the entire implementation. What I did so far is just:

   ./sgadmin.sh \
-cd /path/to/sgconfig/ \
-cacert /path/to/root-ca.pem \
-cert /path/to/kirk.crt.pem \
-key /path/to/kirk.key.pem \
-keypass changeit
-nhnv
-icl

It seems it only applies the default configuration. I did remove the readonly flag in the yml file.

Could you give me a simple example in this case?

在 2018年4月15日星期日 UTC-4下午7:17:14，Jochen Kressin写道：

First, remove the readonly flag from the roles definition (sg_roles.yml) and if you like also for the internal users (sg_internalusers.yml).

If you are using the demo installer, execute sgadmin_demo.sh to apply the changed configuration.

If you have installed Search Guard without the demo installer please refer to the documentation on how to use sgadmin on the command line:

https://docs.search-guard.com/latest/sgadmin

On Sunday, April 15, 2018 at 2:16:40 PM UTC-7, Xiaoyu Wu wrote:

I am currently using elasticsearch 6.2.2 and corresponding search-guard. I have already installed the kibana plugin and got into the GUI.
I am wondering how to change the password for the demo users like admin. The document said set ‘read_only’ to false and apply the sgadmin but I am not sure how to use sgadmin to apply the new changes. What I did before is just to follow the instruction and apply the default configuration.

My purpose is to have my own admin account for the later use case.

[Xiaoyu_Wu]

For now, the GUI shows that “admin” is not reserved. But when I actually want to change the password for it, it throws the internal server error 500.

This is the output of Kibana,

error [03:29:44.313] Error: Resource not valid

at /Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/plugins/searchguard/lib/configuration/backend/searchguard_configuration_backend.js:134:24

at next (native)

at step (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/plugins/searchguard/lib/configuration/backend/searchguard_configuration_backend.js:61:191)

at /Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/plugins/searchguard/lib/configuration/backend/searchguard_configuration_backend.js:61:437

at /Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/plugins/searchguard/lib/configuration/backend/searchguard_configuration_backend.js:61:99

at SearchGuardConfigurationBackend.save (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/plugins/searchguard/lib/configuration/backend/searchguard_configuration_backend.js:131:49)

at /Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/plugins/searchguard/lib/configuration/routes/routes.js:141:42

at next (native)

at step (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/plugins/searchguard/lib/configuration/routes/routes.js:272:191)

at /Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/plugins/searchguard/lib/configuration/routes/routes.js:272:437

at /Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/plugins/searchguard/lib/configuration/routes/routes.js:272:99

at async (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/plugins/searchguard/lib/configuration/routes/routes.js:139:7)

at /Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/plugins/searchguard/node_modules/hapi-async-handler/build/index.js:11:20

at Object.internals.handler (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hapi/lib/handler.js:96:36)

at request._protect.run (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hapi/lib/handler.js:30:23)

at internals.Protect.run (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hapi/lib/protect.js:64:5)

at exports.execute (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hapi/lib/handler.js:24:22)

at each (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hapi/lib/request.js:384:16)

at iterate (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/items/lib/index.js:36:13)

at done (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/items/lib/index.js:28:25)

at Hoek.once (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hapi/lib/protect.js:52:16)

at wrapped (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hoek/lib/index.js:875:20)

在 2018年4月15日星期日 UTC-4下午9:02:55，Xiaoyu Wu写道：

···

I just removed that line, and it solved the login issue.

Thank you so much!

But it seems the “admin” user is still reserved.

Here is a part of code in my sg_internal_users.yml,

#password is: admin

admin:

readonly: false

hash: *******************

roles:

• admin

attributes:

#no dots allowed in attribute names

attribute1: value1

attribute2: value2

attribute3: value3

在 2018年4月15日星期日 UTC-4下午8:32:22，Jochen Kressin写道：

This line in kibana.yml looks suspicious:

searchguard.cookie.name: ‘searchguard_authentication’

And corresponds to the error:

Error: Header value cannot contain or convert into non-ascii characters: set-cookie

Please try to use regular double quotes or comment this line out for the moment.

On Sunday, April 15, 2018 at 5:29:07 PM UTC-7, Xiaoyu Wu wrote:

This is the output of Kibana,

log [00:07:55.456] [info][Sentinl][scheduler] scheduled watcher sentinl-watcher:524238a0-345b-11e8-a95a-9954b3f36dde, to run every every 2 minutes

/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hoek/lib/index.js:736

throw new Error(msgs.join(' ') || 'Unknown error');

^

Error: Header value cannot contain or convert into non-ascii characters: set-cookie

at Object.exports.assert (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hoek/lib/index.js:736:11)

at internals.Response._header (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hapi/lib/response.js:141:22)

at request.connection.states.format (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hapi/lib/transmit.js:507:22)

at Items.serial (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/statehood/lib/index.js:436:16)

at done (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/items/lib/index.js:31:25)

at exports.prepareValue (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/statehood/lib/index.js:431:20)

at internals.sign (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/statehood/lib/index.js:461:20)

at process.nextTick (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hoek/lib/index.js:858:22)

at _combinedTickCallback (internal/process/next_tick.js:73:7)

at process._tickDomainCallback (internal/process/next_tick.js:128:9)

在 2018年4月15日星期日 UTC-4下午8:20:39，Xiaoyu Wu写道：

I used to login the kibana page successfully until I customized the login page.

This is the ES config,

======================== Elasticsearch Configuration =========================

NOTE: Elasticsearch comes with reasonable defaults for most settings.

Before you set out to tweak and tune the configuration, make sure you

understand what are you trying to accomplish and the consequences.

The primary way of configuring a node is via this file. This template lists

the most important settings you may want to configure for a production cluster.

Please consult the documentation for further information on configuration options:

https://www.elastic.co/guide/en/elasticsearch/reference/index.html

---------------------------------- Cluster -----------------------------------

Use a descriptive name for your cluster:

#cluster.name: my-application

------------------------------------ Node ------------------------------------

Use a descriptive name for the node:

#node.name: node-1

Add custom attributes to the node:

#node.attr.rack: r1

----------------------------------- Paths ------------------------------------

Path to directory where to store the data (separate multiple locations by comma):

#path.data: /path/to/data

Path to log files:

#path.logs: /path/to/logs

----------------------------------- Memory -----------------------------------

Lock the memory on startup:

#bootstrap.memory_lock: true

Make sure that the heap size is set to about half the memory available

on the system and that the owner of the process is allowed to use this

limit.

Elasticsearch performs poorly when the system is swapping the memory.

---------------------------------- Network -----------------------------------

Set the bind address to a specific IP (IPv4 or IPv6):

#network.host: 192.168.0.1

Set a custom port for HTTP:

#http.port: 9200

For more information, consult the network module documentation.

--------------------------------- Discovery ----------------------------------

Pass an initial list of hosts to perform discovery when new node is started:

The default list of hosts is [“127.0.0.1”, “[::1]”]

#discovery.zen.ping.unicast.hosts: [“host1”, “host2”]

Prevent the “split brain” by configuring the majority of nodes (total number of master-eligible nodes / 2 + 1):

#discovery.zen.minimum_master_nodes:

For more information, consult the zen discovery module documentation.

---------------------------------- Gateway -----------------------------------

Block initial recovery after a full cluster restart until N nodes are started:

#gateway.recover_after_nodes: 3

For more information, consult the gateway module documentation.

---------------------------------- Various -----------------------------------

Require explicit names when deleting indices:

#action.destructive_requires_name: true

---------------------------------- Search Guard ------------------------------

searchguard.authcz.admin_dn:

• CN=kirk,OU=client,O=client,L=Test,C=DE

Relative path to the certificates key file (PKCS #8), must be placed under the config/ dir

searchguard.ssl.transport.pemkey_filepath: node-0.key.pem

Key password (omit this setting if the key has no password)

#searchguard.ssl.transport.pemkey_password: “secret”

X509 node certificate chain in PEM format, must be placed under the config/ dir

searchguard.ssl.transport.pemcert_filepath: node-0.crt.pem

Trusted certificates

searchguard.ssl.transport.pemtrustedcas_filepath: chain-ca.pem

searchguard.restapi.roles_enabled: [“sg_all_access”]

This is the Kibana,

Kibana is served by a back end server. This setting specifies the port to use.

#server.port: 5601

Specifies the address to which the Kibana server will bind. IP addresses and host names are both valid values.

The default is ‘localhost’, which usually means remote machines will not be able to connect.

To allow connections from remote users, set this parameter to a non-loopback address.

#server.host: “localhost”

Enables you to specify a path to mount Kibana at if you are running behind a proxy. This only affects

the URLs generated by Kibana, your proxy is expected to remove the basePath value before forwarding requests

to Kibana. This setting cannot end in a slash.

#server.basePath: “”

The maximum payload size in bytes for incoming server requests.

#server.maxPayloadBytes: 1048576

The Kibana server’s name. This is used for display purposes.

#server.name: “your-hostname”

The URL of the Elasticsearch instance to use for all your queries.

#elasticsearch.url: “http://localhost:9200”

When this setting’s value is true Kibana uses the hostname specified in the server.host

setting. When the value of this setting is false, Kibana uses the hostname of the host

that connects to this Kibana instance.

#elasticsearch.preserveHost: true

Kibana uses an index in Elasticsearch to store saved searches, visualizations and

dashboards. Kibana creates a new index if the index doesn’t already exist.

#kibana.index: “.kibana”

The default application to load.

#kibana.defaultAppId: “home”

If your Elasticsearch is protected with basic authentication, these settings provide

the username and password that the Kibana server uses to perform maintenance on the Kibana

index at startup. Your Kibana users still need to authenticate with Elasticsearch, which

is proxied through the Kibana server.

#elasticsearch.username: “kibana”

#elasticsearch.password: “BioEPQ1o51gAyIsQYaWc”

Enables SSL and paths to the PEM-format SSL certificate and SSL key files, respectively.

These settings enable SSL for outgoing requests from the Kibana server to the browser.

#server.ssl.enabled: false

#server.ssl.certificate: /path/to/your/server.crt

#server.ssl.key: /path/to/your/server.key

Optional settings that provide the paths to the PEM-format SSL certificate and key files.

These files validate that your Elasticsearch backend uses the same key files.

#elasticsearch.ssl.certificate: /path/to/your/client.crt

#elasticsearch.ssl.key: /path/to/your/client.key

Optional setting that enables you to specify a path to the PEM file for the certificate

authority for your Elasticsearch instance.

#elasticsearch.ssl.certificateAuthorities: [ “/path/to/your/CA.pem” ]

To disregard the validity of SSL certificates, change this setting’s value to ‘none’.

#elasticsearch.ssl.verificationMode: full

Time in milliseconds to wait for Elasticsearch to respond to pings. Defaults to the value of

the elasticsearch.requestTimeout setting.

#elasticsearch.pingTimeout: 1500

Time in milliseconds to wait for responses from the back end or Elasticsearch. This value

must be a positive integer.

#elasticsearch.requestTimeout: 30000

List of Kibana client-side headers to send to Elasticsearch. To send no client-side

headers, set this value to (an empty list).

#elasticsearch.requestHeadersWhitelist: [ authorization ]

Header names and values that are sent to Elasticsearch. Any custom headers cannot be overwritten

by client-side headers, regardless of the elasticsearch.requestHeadersWhitelist configuration.

#elasticsearch.customHeaders: {}

Time in milliseconds for Elasticsearch to wait for responses from shards. Set to 0 to disable.

#elasticsearch.shardTimeout: 0

Time in milliseconds to wait for Elasticsearch at Kibana startup before retrying.

#elasticsearch.startupTimeout: 5000

Specifies the path where Kibana creates the process ID file.

#pid.file: /var/run/kibana.pid

Enables you specify a file where Kibana stores log output.

#logging.dest: stdout

Set the value of this setting to true to suppress all logging output.

#logging.silent: false

Set the value of this setting to true to suppress all logging output other than error messages.

#logging.quiet: false

Set the value of this setting to true to log all events, including system usage information

and all requests.

#logging.verbose: false

Set the interval in milliseconds to sample system and process performance

metrics. Minimum is 100ms. Defaults to 5000.

#ops.interval: 5000

The default locale. This locale can be used in certain circumstances to substitute any missing

translations.

#i18n.defaultLocale: “en”

Config of Sentinl

sentinl:

settings:

email:

active: true

user: ------

password: -------

host: -------

ssl: true

timeout: 10000

elasticsearch.username: “kibanaserver”

elasticsearch.password: “kibanaserver”

elasticsearch.ssl.verificationMode: none

Login Page

searchguard.basicauth.login.showbrandimage: true

searchguard.basicauth.login.brandimage: https://www.symantec.com/content/dam/symantec/images/common/symantec-logo-top.png

searchguard.cookie.name: ‘searchguard_authentication’

#searchguard.basicauth.login.title

#searchguard.basicauth.login.subtitle

This is the sg_roles,

#<sg_role_name>:

cluster:

- ‘’

indices:

‘’:

‘’:

- ‘’

dls: ‘’

fls:

- ‘’

- ‘’

When a user make a request to Elasticsearch then the following roles will be evaluated to see if the user has

permissions for the request. A request is always associated with an action and is executed against and index (or alias)

and a type. If a request is executed against all indices (or all types) then the asterix (‘*’) is needed.

Every role a user has will be examined if it allows the action against an index (or type). At least one role must match

for the request to be successful. If no role match then the request will be denied. Currently a match must happen within

one single role - that means that permissions can not span multiple roles.

For , and simple wildcards and regular expressions are possible.

A asterix (*) will match any character sequence (or an empty sequence)

A question mark (?) will match any single character (but NOT empty character)

Example: ‘myindex’ will match ‘my_first_index’ as well as ‘myindex’ but not ‘myindex1’

Example: ‘?kibana’ will match ‘.kibana’ but not ‘kibana’

To use a full blown regex you have to pre- and apend a ‘/’ to use regex instead of simple wildcards

‘//’

Example: ‘/\S*/’ will match any non whitespace characters

Important:

Index, alias or type names can not contain dots (.) in the or expression.

Reason is that we currently parse the config file into a elasticsearch settings object which cannot cope with dots in keys.

Workaround: Just configure something like ‘?kibana’ instead of ‘.kibana’ or ‘my?index’ instead of ‘my.index’

This limitation will likely removed with Search Guard 6

DLS (Document level security) - NOT FREE FOR COMMERCIAL

http://docs.search-guard.com/v6/document-level-security

FLS (Field level security) - NOT FREE FOR COMMERCIAL

http://docs.search-guard.com/v6/field-level-security

Kibana multitenancy - NOT FREE FOR COMMERCIAL

http://docs.search-guard.com/v6/kibana-multi-tenancy

Allows everything, but no changes to searchguard configuration index

sg_all_access:

readonly: true

cluster:

• UNLIMITED

indices:

‘*’:

‘*’:

• UNLIMITED

tenants:

admin_tenant: RW

Read all, but no write permissions

sg_readall:

readonly: true

cluster:

• CLUSTER_COMPOSITE_OPS_RO

indices:

‘*’:

‘*’:

• READ

Read all and monitor, but no write permissions

sg_readall_and_monitor:

cluster:

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS_RO

indices:

‘*’:

‘*’:

• READ

For users which use kibana, access to indices must be granted separately

sg_kibana_user:

readonly: true

cluster:

• MONITOR

• CLUSTER_COMPOSITE_OPS_RO

indices:

‘?kibana’:

‘*’:

• MANAGE

• INDEX

• READ

• DELETE

‘*’:

‘*’:

• indices:data/read/field_caps*

For the kibana server

sg_kibana_server:

readonly: true

cluster:

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS

• cluster:admin/xpack/monitoring*

• indices:admin/template*

indices:

‘?kibana’:

‘*’:

• INDICES_ALL

‘?reporting*’:

‘*’:

• INDICES_ALL

‘?monitoring*’:

‘*’:

• INDICES_ALL

For logstash and beats

sg_logstash:

cluster:

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS

• indices:admin/template/get

• indices:admin/template/put

indices:

‘logstash-*’:

‘*’:

• CRUD

• CREATE_INDEX

‘beat’:

‘*’:

• CRUD

• CREATE_INDEX

Allows adding and modifying repositories and creating and restoring snapshots

sg_manage_snapshots:

cluster:

• MANAGE_SNAPSHOTS

indices:

‘*’:

‘*’:

• “indices:data/write/index”

• “indices:admin/create”

Allows each user to access own named index

sg_own_index:

cluster:

• CLUSTER_COMPOSITE_OPS

indices:

‘${user_name}’:

‘*’:

• INDICES_ALL

X-Pack COMPATIBILITY

sg_xp_monitoring:

readonly: true

indices:

‘?monitor*’:

‘*’:

• INDICES_ALL

sg_xp_alerting:

readonly: true

cluster:

• indices:data/read/scroll

• cluster:admin/xpack/watcher*

• cluster:monitor/xpack/watcher*

indices:

‘?watches*’:

‘*’:

• INDICES_ALL

‘?watcher-history-*’:

‘*’:

• INDICES_ALL

‘?triggered_watches’:

‘*’:

• INDICES_ALL

‘*’:

‘*’:

• READ

• indices:admin/aliases/get

sg_xp_machine_learning:

readonly: true

cluster:

• cluster:admin/persistent*

• cluster:internal/xpack/ml*

• indices:data/read/scroll*

• cluster:admin/xpack/ml*

• cluster:monitor/xpack/ml*

indices:

‘*’:

‘*’:

• READ

• indices:admin/get*

‘?ml-*’:

‘*’:

• “*”

LEGACY ROLES, FOR COMPATIBILITY ONLY

WILL BE REMOVED IN SG7, DO NOT USE ANYMORE

sg_readonly_and_monitor:

cluster:

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS_RO

indices:

‘*’:

‘*’:

• READ

Make xpack monitoring work

sg_monitor:

cluster:

• cluster:admin/xpack/monitoring/*

• cluster:admin/ingest/pipeline/put

• cluster:admin/ingest/pipeline/get

• indices:admin/template/get

• indices:admin/template/put

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS

indices:

‘?monitor*’:

‘*’:

• INDICES_ALL

‘?marvel*’:

‘*’:

• INDICES_ALL

‘?kibana*’:

‘*’:

• READ

‘*’:

‘*’:

• indices:data/read/field_caps

Make xpack alerting work

sg_alerting:

cluster:

• indices:data/read/scroll

• cluster:admin/xpack/watcher/watch/put

• cluster:admin/xpack/watcher*

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS

indices:

‘?kibana*’:

‘*’:

• READ

‘?watches*’:

‘*’:

• INDICES_ALL

‘?watcher-history-*’:

‘*’:

• INDICES_ALL

‘?triggered_watches’:

‘*’:

• INDICES_ALL

‘*’:

‘*’:

• READ

在 2018年4月15日星期日 UTC-4下午8:15:42，Jochen Kressin写道：

So it seems you also have installed X-Pack and there is an error with your watcher configuration:

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No index-level perm match for User [name=kibanaserver, roles=, requestedTenant=null] [IndexType [index=watcher_alarms, type=*]] [Action [[indices:admin/get]]] [RolesChecked [sg_kibana_server, sg_own_index]]

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No permissions for {sg_own_index=[IndexType [index=watcher_alarms, type=]], sg_kibana_server=[IndexType [index=watcher_alarms, type=]]}

Please post at least:

• kibana.yml

• elasticsearch.yml

• sg_roles.yml

Just remove any sensitive information like paths and passwords.

On Sunday, April 15, 2018 at 5:11:26 PM UTC-7, Xiaoyu Wu wrote:

I checked localhost:9200/_authinfo and the elasticsearch looks good.

This is a part of my kibana config (the rest is the default)

elasticsearch.username: “kibanaserver”

elasticsearch.password: “kibanaserver”

elasticsearch.ssl.verificationMode: none

Login Page

searchguard.basicauth.login.showbrandimage: true

searchguard.basicauth.login.brandimage: https://www.symantec.com/content/dam/symantec/images/common/symantec-logo-top.png

searchguard.cookie.name: ‘searchguard_authentication’

#searchguard.basicauth.login.title

#searchguard.basicauth.login.subtitle

This is the output of elasticsearch log,

[2018-04-15T20:07:25,113][INFO ][c.f.s.c.IndexBaseConfigurationRepository] Search Guard License Info: SearchGuardLicense [uid=00000000-0000-0000-0000-000000000000, type=TRIAL, issueDate=2018-04-15, expiryDate=2018-06-15, issuedTo=The world, issuer=floragunn GmbH, startDate=2018-04-15, majorVersion=6, clusterName=*, allowedNodeCount=2147483647, msgs=, expiresInDays=60, isExpired=false, valid=true, action=, prodUsage=Yes, one cluster with all commercial features and unlimited nodes per cluster., clusterService=org.elasticsearch.cluster.service.ClusterService@2e500df4, getMsgs()=, getExpiresInDays()=60, isExpired()=false, isValid()=true, getAction()=, getProdUsage()=Yes, one cluster with all commercial features and unlimited nodes per cluster.]

[2018-04-15T20:07:25,113][INFO ][c.f.s.c.IndexBaseConfigurationRepository] Search Guard License Type: TRIAL, valid

[2018-04-15T20:07:25,114][INFO ][c.f.s.c.IndexBaseConfigurationRepository] Node ‘LhPFJNW’ initialized

[2018-04-15T20:07:25,364][INFO ][o.e.c.r.a.AllocationService] [LhPFJNW] Cluster health status changed from [RED] to [YELLOW] (reason: [shards started [[.kibana][0]] …]).

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No index-level perm match for User [name=kibanaserver, roles=, requestedTenant=null] [IndexType [index=watcher_alarms, type=*]] [Action [[indices:admin/get]]] [RolesChecked [sg_kibana_server, sg_own_index]]

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No permissions for {sg_own_index=[IndexType [index=watcher_alarms, type=]], sg_kibana_server=[IndexType [index=watcher_alarms, type=]]}

在 2018年4月15日星期日 UTC-4下午8:05:10，Jochen Kressin写道：

sgadmin will replace the current configuration in your cluster with the files located in:

/Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/

So if you want to make changes to the configuration, the easiest way of doing so is to change these files, and then run sgadmin again. According to the output sgadmin has succeeded with uploading the configuration. So your sgadmin command seems fine.

There seems to be something wrong with your Kibana configuration and/or the Search Guard configuration.

What is the output of the Elasticsearch log file? Do you see any error there?

What is the Kibana configuration your are using? Please post it here.

Did you try to restart Kibana and reload the login page?

On Sunday, April 15, 2018 at 4:59:02 PM UTC-7, Xiaoyu Wu wrote:

This is the output of sgadmin tool,

searchguard index already exists, so we do not need to create one.

Populate config from /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/

Will update ‘sg/config’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_config.yml

SUCC: Configuration for ‘config’ created or updated

Will update ‘sg/roles’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_roles.yml

SUCC: Configuration for ‘roles’ created or updated

Will update ‘sg/rolesmapping’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_roles_mapping.yml

SUCC: Configuration for ‘rolesmapping’ created or updated

Will update ‘sg/internalusers’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_internal_users.yml

SUCC: Configuration for ‘internalusers’ created or updated

Will update ‘sg/actiongroups’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_action_groups.yml

SUCC: Configuration for ‘actiongroups’ created or updated

Done with success

And when I restarted the Kibana, it threw me the error saying “An error occurred while checking your credentials, make sure you have an Elasticsearch cluster secured by Search Guard running.”

在 2018年4月15日星期日 UTC-4下午7:56:32，Jochen Kressin写道：

What is the output of the sgadmin tool when you run the command you posted? And what do you see in the Elasticsearch logs when you run sgadmin?

On Sunday, April 15, 2018 at 4:34:56 PM UTC-7, Xiaoyu Wu wrote:

I did not use the demo installer.

I checked the documentation but it is kinda difficult for me to understand the entire implementation. What I did so far is just:

   ./sgadmin.sh \
-cd /path/to/sgconfig/ \
-cacert /path/to/root-ca.pem \
-cert /path/to/kirk.crt.pem \
-key /path/to/kirk.key.pem \
-keypass changeit
-nhnv
-icl

It seems it only applies the default configuration. I did remove the readonly flag in the yml file.

Could you give me a simple example in this case?

在 2018年4月15日星期日 UTC-4下午7:17:14，Jochen Kressin写道：

First, remove the readonly flag from the roles definition (sg_roles.yml) and if you like also for the internal users (sg_internalusers.yml).

If you are using the demo installer, execute sgadmin_demo.sh to apply the changed configuration.

If you have installed Search Guard without the demo installer please refer to the documentation on how to use sgadmin on the command line:

https://docs.search-guard.com/latest/sgadmin

On Sunday, April 15, 2018 at 2:16:40 PM UTC-7, Xiaoyu Wu wrote:

I am currently using elasticsearch 6.2.2 and corresponding search-guard. I have already installed the kibana plugin and got into the GUI.
I am wondering how to change the password for the demo users like admin. The document said set ‘read_only’ to false and apply the sgadmin but I am not sure how to use sgadmin to apply the new changes. What I did before is just to follow the instruction and apply the default configuration.

My purpose is to have my own admin account for the later use case.

[jkressin]

Maybe you are logged in with the user “admin” and try to change the password for the logged in user? This is not possible since it would break your current session and you can lock yourself out if you mistype the password. That’s why the demo admin user is marked “reserved” in the first place.

What is it that you want to achieve exactly? If I know I can probably help you better.

···

On Sunday, April 15, 2018 at 8:33:38 PM UTC-7, Xiaoyu Wu wrote:

For now, the GUI shows that “admin” is not reserved. But when I actually want to change the password for it, it throws the internal server error 500.

This is the output of Kibana,

error [03:29:44.313] Error: Resource not valid

at /Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/plugins/searchguard/lib/configuration/backend/searchguard_configuration_backend.js:134:24

at next (native)

at step (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/plugins/searchguard/lib/configuration/backend/searchguard_configuration_backend.js:61:191)

at /Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/plugins/searchguard/lib/configuration/backend/searchguard_configuration_backend.js:61:437

at /Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/plugins/searchguard/lib/configuration/backend/searchguard_configuration_backend.js:61:99

at SearchGuardConfigurationBackend.save (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/plugins/searchguard/lib/configuration/backend/searchguard_configuration_backend.js:131:49)

at /Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/plugins/searchguard/lib/configuration/routes/routes.js:141:42

at next (native)

at step (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/plugins/searchguard/lib/configuration/routes/routes.js:272:191)

at /Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/plugins/searchguard/lib/configuration/routes/routes.js:272:437

at /Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/plugins/searchguard/lib/configuration/routes/routes.js:272:99

at async (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/plugins/searchguard/lib/configuration/routes/routes.js:139:7)

at /Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/plugins/searchguard/node_modules/hapi-async-handler/build/index.js:11:20

at Object.internals.handler (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hapi/lib/handler.js:96:36)

at request._protect.run (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hapi/lib/handler.js:30:23)

at internals.Protect.run (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hapi/lib/protect.js:64:5)

at exports.execute (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hapi/lib/handler.js:24:22)

at each (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hapi/lib/request.js:384:16)

at iterate (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/items/lib/index.js:36:13)

at done (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/items/lib/index.js:28:25)

at Hoek.once (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hapi/lib/protect.js:52:16)

at wrapped (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hoek/lib/index.js:875:20)

在 2018年4月15日星期日 UTC-4下午9:02:55，Xiaoyu Wu写道：

I just removed that line, and it solved the login issue.

Thank you so much!

But it seems the “admin” user is still reserved.

Here is a part of code in my sg_internal_users.yml,

#password is: admin

admin:

readonly: false

hash: *******************

roles:

• admin

attributes:

#no dots allowed in attribute names

attribute1: value1

attribute2: value2

attribute3: value3

在 2018年4月15日星期日 UTC-4下午8:32:22，Jochen Kressin写道：

This line in kibana.yml looks suspicious:

searchguard.cookie.name: ‘searchguard_authentication’

And corresponds to the error:

Error: Header value cannot contain or convert into non-ascii characters: set-cookie

Please try to use regular double quotes or comment this line out for the moment.

On Sunday, April 15, 2018 at 5:29:07 PM UTC-7, Xiaoyu Wu wrote:

This is the output of Kibana,

log [00:07:55.456] [info][Sentinl][scheduler] scheduled watcher sentinl-watcher:524238a0-345b-11e8-a95a-9954b3f36dde, to run every every 2 minutes

/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hoek/lib/index.js:736

throw new Error(msgs.join(' ') || 'Unknown error');

^

Error: Header value cannot contain or convert into non-ascii characters: set-cookie

at Object.exports.assert (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hoek/lib/index.js:736:11)

at internals.Response._header (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hapi/lib/response.js:141:22)

at request.connection.states.format (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hapi/lib/transmit.js:507:22)

at Items.serial (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/statehood/lib/index.js:436:16)

at done (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/items/lib/index.js:31:25)

at exports.prepareValue (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/statehood/lib/index.js:431:20)

at internals.sign (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/statehood/lib/index.js:461:20)

at process.nextTick (/Users/apple/Desktop/kibana-6.2.2-darwin-x86_64/node_modules/hoek/lib/index.js:858:22)

at _combinedTickCallback (internal/process/next_tick.js:73:7)

at process._tickDomainCallback (internal/process/next_tick.js:128:9)

在 2018年4月15日星期日 UTC-4下午8:20:39，Xiaoyu Wu写道：

I used to login the kibana page successfully until I customized the login page.

This is the ES config,

======================== Elasticsearch Configuration =========================

NOTE: Elasticsearch comes with reasonable defaults for most settings.

Before you set out to tweak and tune the configuration, make sure you

understand what are you trying to accomplish and the consequences.

The primary way of configuring a node is via this file. This template lists

the most important settings you may want to configure for a production cluster.

Please consult the documentation for further information on configuration options:

https://www.elastic.co/guide/en/elasticsearch/reference/index.html

---------------------------------- Cluster -----------------------------------

Use a descriptive name for your cluster:

#cluster.name: my-application

------------------------------------ Node ------------------------------------

Use a descriptive name for the node:

#node.name: node-1

Add custom attributes to the node:

#node.attr.rack: r1

----------------------------------- Paths ------------------------------------

Path to directory where to store the data (separate multiple locations by comma):

#path.data: /path/to/data

Path to log files:

#path.logs: /path/to/logs

----------------------------------- Memory -----------------------------------

Lock the memory on startup:

#bootstrap.memory_lock: true

Make sure that the heap size is set to about half the memory available

on the system and that the owner of the process is allowed to use this

limit.

Elasticsearch performs poorly when the system is swapping the memory.

---------------------------------- Network -----------------------------------

Set the bind address to a specific IP (IPv4 or IPv6):

#network.host: 192.168.0.1

Set a custom port for HTTP:

#http.port: 9200

For more information, consult the network module documentation.

--------------------------------- Discovery ----------------------------------

Pass an initial list of hosts to perform discovery when new node is started:

The default list of hosts is [“127.0.0.1”, “[::1]”]

#discovery.zen.ping.unicast.hosts: [“host1”, “host2”]

Prevent the “split brain” by configuring the majority of nodes (total number of master-eligible nodes / 2 + 1):

#discovery.zen.minimum_master_nodes:

For more information, consult the zen discovery module documentation.

---------------------------------- Gateway -----------------------------------

Block initial recovery after a full cluster restart until N nodes are started:

#gateway.recover_after_nodes: 3

For more information, consult the gateway module documentation.

---------------------------------- Various -----------------------------------

Require explicit names when deleting indices:

#action.destructive_requires_name: true

---------------------------------- Search Guard ------------------------------

searchguard.authcz.admin_dn:

• CN=kirk,OU=client,O=client,L=Test,C=DE

Relative path to the certificates key file (PKCS #8), must be placed under the config/ dir

searchguard.ssl.transport.pemkey_filepath: node-0.key.pem

Key password (omit this setting if the key has no password)

#searchguard.ssl.transport.pemkey_password: “secret”

X509 node certificate chain in PEM format, must be placed under the config/ dir

searchguard.ssl.transport.pemcert_filepath: node-0.crt.pem

Trusted certificates

searchguard.ssl.transport.pemtrustedcas_filepath: chain-ca.pem

searchguard.restapi.roles_enabled: [“sg_all_access”]

This is the Kibana,

Kibana is served by a back end server. This setting specifies the port to use.

#server.port: 5601

Specifies the address to which the Kibana server will bind. IP addresses and host names are both valid values.

The default is ‘localhost’, which usually means remote machines will not be able to connect.

To allow connections from remote users, set this parameter to a non-loopback address.

#server.host: “localhost”

Enables you to specify a path to mount Kibana at if you are running behind a proxy. This only affects

the URLs generated by Kibana, your proxy is expected to remove the basePath value before forwarding requests

to Kibana. This setting cannot end in a slash.

#server.basePath: “”

The maximum payload size in bytes for incoming server requests.

#server.maxPayloadBytes: 1048576

The Kibana server’s name. This is used for display purposes.

#server.name: “your-hostname”

The URL of the Elasticsearch instance to use for all your queries.

#elasticsearch.url: “http://localhost:9200”

When this setting’s value is true Kibana uses the hostname specified in the server.host

setting. When the value of this setting is false, Kibana uses the hostname of the host

that connects to this Kibana instance.

#elasticsearch.preserveHost: true

Kibana uses an index in Elasticsearch to store saved searches, visualizations and

dashboards. Kibana creates a new index if the index doesn’t already exist.

#kibana.index: “.kibana”

The default application to load.

#kibana.defaultAppId: “home”

If your Elasticsearch is protected with basic authentication, these settings provide

the username and password that the Kibana server uses to perform maintenance on the Kibana

index at startup. Your Kibana users still need to authenticate with Elasticsearch, which

is proxied through the Kibana server.

#elasticsearch.username: “kibana”

#elasticsearch.password: “BioEPQ1o51gAyIsQYaWc”

Enables SSL and paths to the PEM-format SSL certificate and SSL key files, respectively.

These settings enable SSL for outgoing requests from the Kibana server to the browser.

#server.ssl.enabled: false

#server.ssl.certificate: /path/to/your/server.crt

#server.ssl.key: /path/to/your/server.key

Optional settings that provide the paths to the PEM-format SSL certificate and key files.

These files validate that your Elasticsearch backend uses the same key files.

#elasticsearch.ssl.certificate: /path/to/your/client.crt

#elasticsearch.ssl.key: /path/to/your/client.key

Optional setting that enables you to specify a path to the PEM file for the certificate

authority for your Elasticsearch instance.

#elasticsearch.ssl.certificateAuthorities: [ “/path/to/your/CA.pem” ]

To disregard the validity of SSL certificates, change this setting’s value to ‘none’.

#elasticsearch.ssl.verificationMode: full

Time in milliseconds to wait for Elasticsearch to respond to pings. Defaults to the value of

the elasticsearch.requestTimeout setting.

#elasticsearch.pingTimeout: 1500

Time in milliseconds to wait for responses from the back end or Elasticsearch. This value

must be a positive integer.

#elasticsearch.requestTimeout: 30000

List of Kibana client-side headers to send to Elasticsearch. To send no client-side

headers, set this value to (an empty list).

#elasticsearch.requestHeadersWhitelist: [ authorization ]

Header names and values that are sent to Elasticsearch. Any custom headers cannot be overwritten

by client-side headers, regardless of the elasticsearch.requestHeadersWhitelist configuration.

#elasticsearch.customHeaders: {}

Time in milliseconds for Elasticsearch to wait for responses from shards. Set to 0 to disable.

#elasticsearch.shardTimeout: 0

Time in milliseconds to wait for Elasticsearch at Kibana startup before retrying.

#elasticsearch.startupTimeout: 5000

Specifies the path where Kibana creates the process ID file.

#pid.file: /var/run/kibana.pid

Enables you specify a file where Kibana stores log output.

#logging.dest: stdout

Set the value of this setting to true to suppress all logging output.

#logging.silent: false

Set the value of this setting to true to suppress all logging output other than error messages.

#logging.quiet: false

Set the value of this setting to true to log all events, including system usage information

and all requests.

#logging.verbose: false

Set the interval in milliseconds to sample system and process performance

metrics. Minimum is 100ms. Defaults to 5000.

#ops.interval: 5000

The default locale. This locale can be used in certain circumstances to substitute any missing

translations.

#i18n.defaultLocale: “en”

Config of Sentinl

sentinl:

settings:

email:

active: true

user: ------

password: -------

host: -------

ssl: true

timeout: 10000

elasticsearch.username: “kibanaserver”

elasticsearch.password: “kibanaserver”

elasticsearch.ssl.verificationMode: none

Login Page

searchguard.basicauth.login.showbrandimage: true

searchguard.basicauth.login.brandimage: https://www.symantec.com/content/dam/symantec/images/common/symantec-logo-top.png

searchguard.cookie.name: ‘searchguard_authentication’

#searchguard.basicauth.login.title

#searchguard.basicauth.login.subtitle

This is the sg_roles,

#<sg_role_name>:

cluster:

- ‘’

indices:

‘’:

‘’:

- ‘’

dls: ‘’

fls:

- ‘’

- ‘’

When a user make a request to Elasticsearch then the following roles will be evaluated to see if the user has

permissions for the request. A request is always associated with an action and is executed against and index (or alias)

and a type. If a request is executed against all indices (or all types) then the asterix (‘*’) is needed.

Every role a user has will be examined if it allows the action against an index (or type). At least one role must match

for the request to be successful. If no role match then the request will be denied. Currently a match must happen within

one single role - that means that permissions can not span multiple roles.

For , and simple wildcards and regular expressions are possible.

A asterix (*) will match any character sequence (or an empty sequence)

A question mark (?) will match any single character (but NOT empty character)

Example: ‘myindex’ will match ‘my_first_index’ as well as ‘myindex’ but not ‘myindex1’

Example: ‘?kibana’ will match ‘.kibana’ but not ‘kibana’

To use a full blown regex you have to pre- and apend a ‘/’ to use regex instead of simple wildcards

‘//’

Example: ‘/\S*/’ will match any non whitespace characters

Important:

Index, alias or type names can not contain dots (.) in the or expression.

Reason is that we currently parse the config file into a elasticsearch settings object which cannot cope with dots in keys.

Workaround: Just configure something like ‘?kibana’ instead of ‘.kibana’ or ‘my?index’ instead of ‘my.index’

This limitation will likely removed with Search Guard 6

DLS (Document level security) - NOT FREE FOR COMMERCIAL

http://docs.search-guard.com/v6/document-level-security

FLS (Field level security) - NOT FREE FOR COMMERCIAL

http://docs.search-guard.com/v6/field-level-security

Kibana multitenancy - NOT FREE FOR COMMERCIAL

http://docs.search-guard.com/v6/kibana-multi-tenancy

Allows everything, but no changes to searchguard configuration index

sg_all_access:

readonly: true

cluster:

• UNLIMITED

indices:

‘*’:

‘*’:

• UNLIMITED

tenants:

admin_tenant: RW

Read all, but no write permissions

sg_readall:

readonly: true

cluster:

• CLUSTER_COMPOSITE_OPS_RO

indices:

‘*’:

‘*’:

• READ

Read all and monitor, but no write permissions

sg_readall_and_monitor:

cluster:

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS_RO

indices:

‘*’:

‘*’:

• READ

For users which use kibana, access to indices must be granted separately

sg_kibana_user:

readonly: true

cluster:

• MONITOR

• CLUSTER_COMPOSITE_OPS_RO

indices:

‘?kibana’:

‘*’:

• MANAGE

• INDEX

• READ

• DELETE

‘*’:

‘*’:

• indices:data/read/field_caps*

For the kibana server

sg_kibana_server:

readonly: true

cluster:

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS

• cluster:admin/xpack/monitoring*

• indices:admin/template*

indices:

‘?kibana’:

‘*’:

• INDICES_ALL

‘?reporting*’:

‘*’:

• INDICES_ALL

‘?monitoring*’:

‘*’:

• INDICES_ALL

For logstash and beats

sg_logstash:

cluster:

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS

• indices:admin/template/get

• indices:admin/template/put

indices:

‘logstash-*’:

‘*’:

• CRUD

• CREATE_INDEX

‘beat’:

‘*’:

• CRUD

• CREATE_INDEX

Allows adding and modifying repositories and creating and restoring snapshots

sg_manage_snapshots:

cluster:

• MANAGE_SNAPSHOTS

indices:

‘*’:

‘*’:

• “indices:data/write/index”

• “indices:admin/create”

Allows each user to access own named index

sg_own_index:

cluster:

• CLUSTER_COMPOSITE_OPS

indices:

‘${user_name}’:

‘*’:

• INDICES_ALL

X-Pack COMPATIBILITY

sg_xp_monitoring:

readonly: true

indices:

‘?monitor*’:

‘*’:

• INDICES_ALL

sg_xp_alerting:

readonly: true

cluster:

• indices:data/read/scroll

• cluster:admin/xpack/watcher*

• cluster:monitor/xpack/watcher*

indices:

‘?watches*’:

‘*’:

• INDICES_ALL

‘?watcher-history-*’:

‘*’:

• INDICES_ALL

‘?triggered_watches’:

‘*’:

• INDICES_ALL

‘*’:

‘*’:

• READ

• indices:admin/aliases/get

sg_xp_machine_learning:

readonly: true

cluster:

• cluster:admin/persistent*

• cluster:internal/xpack/ml*

• indices:data/read/scroll*

• cluster:admin/xpack/ml*

• cluster:monitor/xpack/ml*

indices:

‘*’:

‘*’:

• READ

• indices:admin/get*

‘?ml-*’:

‘*’:

• “*”

LEGACY ROLES, FOR COMPATIBILITY ONLY

WILL BE REMOVED IN SG7, DO NOT USE ANYMORE

sg_readonly_and_monitor:

cluster:

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS_RO

indices:

‘*’:

‘*’:

• READ

Make xpack monitoring work

sg_monitor:

cluster:

• cluster:admin/xpack/monitoring/*

• cluster:admin/ingest/pipeline/put

• cluster:admin/ingest/pipeline/get

• indices:admin/template/get

• indices:admin/template/put

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS

indices:

‘?monitor*’:

‘*’:

• INDICES_ALL

‘?marvel*’:

‘*’:

• INDICES_ALL

‘?kibana*’:

‘*’:

• READ

‘*’:

‘*’:

• indices:data/read/field_caps

Make xpack alerting work

sg_alerting:

cluster:

• indices:data/read/scroll

• cluster:admin/xpack/watcher/watch/put

• cluster:admin/xpack/watcher*

• CLUSTER_MONITOR

• CLUSTER_COMPOSITE_OPS

indices:

‘?kibana*’:

‘*’:

• READ

‘?watches*’:

‘*’:

• INDICES_ALL

‘?watcher-history-*’:

‘*’:

• INDICES_ALL

‘?triggered_watches’:

‘*’:

• INDICES_ALL

‘*’:

‘*’:

• READ

在 2018年4月15日星期日 UTC-4下午8:15:42，Jochen Kressin写道：

So it seems you also have installed X-Pack and there is an error with your watcher configuration:

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No index-level perm match for User [name=kibanaserver, roles=, requestedTenant=null] [IndexType [index=watcher_alarms, type=*]] [Action [[indices:admin/get]]] [RolesChecked [sg_kibana_server, sg_own_index]]

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No permissions for {sg_own_index=[IndexType [index=watcher_alarms, type=]], sg_kibana_server=[IndexType [index=watcher_alarms, type=]]}

Please post at least:

• kibana.yml

• elasticsearch.yml

• sg_roles.yml

Just remove any sensitive information like paths and passwords.

On Sunday, April 15, 2018 at 5:11:26 PM UTC-7, Xiaoyu Wu wrote:

I checked localhost:9200/_authinfo and the elasticsearch looks good.

This is a part of my kibana config (the rest is the default)

elasticsearch.username: “kibanaserver”

elasticsearch.password: “kibanaserver”

elasticsearch.ssl.verificationMode: none

Login Page

searchguard.basicauth.login.showbrandimage: true

searchguard.basicauth.login.brandimage: https://www.symantec.com/content/dam/symantec/images/common/symantec-logo-top.png

searchguard.cookie.name: ‘searchguard_authentication’

#searchguard.basicauth.login.title

#searchguard.basicauth.login.subtitle

This is the output of elasticsearch log,

[2018-04-15T20:07:25,113][INFO ][c.f.s.c.IndexBaseConfigurationRepository] Search Guard License Info: SearchGuardLicense [uid=00000000-0000-0000-0000-000000000000, type=TRIAL, issueDate=2018-04-15, expiryDate=2018-06-15, issuedTo=The world, issuer=floragunn GmbH, startDate=2018-04-15, majorVersion=6, clusterName=*, allowedNodeCount=2147483647, msgs=, expiresInDays=60, isExpired=false, valid=true, action=, prodUsage=Yes, one cluster with all commercial features and unlimited nodes per cluster., clusterService=org.elasticsearch.cluster.service.ClusterService@2e500df4, getMsgs()=, getExpiresInDays()=60, isExpired()=false, isValid()=true, getAction()=, getProdUsage()=Yes, one cluster with all commercial features and unlimited nodes per cluster.]

[2018-04-15T20:07:25,113][INFO ][c.f.s.c.IndexBaseConfigurationRepository] Search Guard License Type: TRIAL, valid

[2018-04-15T20:07:25,114][INFO ][c.f.s.c.IndexBaseConfigurationRepository] Node ‘LhPFJNW’ initialized

[2018-04-15T20:07:25,364][INFO ][o.e.c.r.a.AllocationService] [LhPFJNW] Cluster health status changed from [RED] to [YELLOW] (reason: [shards started [[.kibana][0]] …]).

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No index-level perm match for User [name=kibanaserver, roles=, requestedTenant=null] [IndexType [index=watcher_alarms, type=*]] [Action [[indices:admin/get]]] [RolesChecked [sg_kibana_server, sg_own_index]]

[2018-04-15T20:07:31,351][INFO ][c.f.s.c.PrivilegesEvaluator] No permissions for {sg_own_index=[IndexType [index=watcher_alarms, type=]], sg_kibana_server=[IndexType [index=watcher_alarms, type=]]}

在 2018年4月15日星期日 UTC-4下午8:05:10，Jochen Kressin写道：

sgadmin will replace the current configuration in your cluster with the files located in:

/Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/

So if you want to make changes to the configuration, the easiest way of doing so is to change these files, and then run sgadmin again. According to the output sgadmin has succeeded with uploading the configuration. So your sgadmin command seems fine.

There seems to be something wrong with your Kibana configuration and/or the Search Guard configuration.

What is the output of the Elasticsearch log file? Do you see any error there?

What is the Kibana configuration your are using? Please post it here.

Did you try to restart Kibana and reload the login page?

On Sunday, April 15, 2018 at 4:59:02 PM UTC-7, Xiaoyu Wu wrote:

This is the output of sgadmin tool,

searchguard index already exists, so we do not need to create one.

Populate config from /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/

Will update ‘sg/config’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_config.yml

SUCC: Configuration for ‘config’ created or updated

Will update ‘sg/roles’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_roles.yml

SUCC: Configuration for ‘roles’ created or updated

Will update ‘sg/rolesmapping’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_roles_mapping.yml

SUCC: Configuration for ‘rolesmapping’ created or updated

Will update ‘sg/internalusers’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_internal_users.yml

SUCC: Configuration for ‘internalusers’ created or updated

Will update ‘sg/actiongroups’ with /Users/apple/Desktop/elasticsearch-6.2.2/plugins/search-guard-6/sgconfig/sg_action_groups.yml

SUCC: Configuration for ‘actiongroups’ created or updated

Done with success

And when I restarted the Kibana, it threw me the error saying “An error occurred while checking your credentials, make sure you have an Elasticsearch cluster secured by Search Guard running.”

在 2018年4月15日星期日 UTC-4下午7:56:32，Jochen Kressin写道：

What is the output of the sgadmin tool when you run the command you posted? And what do you see in the Elasticsearch logs when you run sgadmin?

On Sunday, April 15, 2018 at 4:34:56 PM UTC-7, Xiaoyu Wu wrote:

I did not use the demo installer.

I checked the documentation but it is kinda difficult for me to understand the entire implementation. What I did so far is just:

   ./sgadmin.sh \
-cd /path/to/sgconfig/ \
-cacert /path/to/root-ca.pem \
-cert /path/to/kirk.crt.pem \
-key /path/to/kirk.key.pem \
-keypass changeit
-nhnv
-icl

It seems it only applies the default configuration. I did remove the readonly flag in the yml file.

Could you give me a simple example in this case?

在 2018年4月15日星期日 UTC-4下午7:17:14，Jochen Kressin写道：

First, remove the readonly flag from the roles definition (sg_roles.yml) and if you like also for the internal users (sg_internalusers.yml).

If you are using the demo installer, execute sgadmin_demo.sh to apply the changed configuration.

If you have installed Search Guard without the demo installer please refer to the documentation on how to use sgadmin on the command line:

https://docs.search-guard.com/latest/sgadmin

On Sunday, April 15, 2018 at 2:16:40 PM UTC-7, Xiaoyu Wu wrote:

I am currently using elasticsearch 6.2.2 and corresponding search-guard. I have already installed the kibana plugin and got into the GUI.
I am wondering how to change the password for the demo users like admin. The document said set ‘read_only’ to false and apply the sgadmin but I am not sure how to use sgadmin to apply the new changes. What I did before is just to follow the instruction and apply the default configuration.

My purpose is to have my own admin account for the later use case.