Security Plugin

Change admin password

OD4FE ships with an advanced security plugin. The Security plugin stores its configuration—including users, roles, and permissions—in an index on the Elasticsearch cluster (.opendistro_security). Storing these settings in an index lets you change settings without restarting the cluster and eliminates the need to edit configuration files on every single node.

The plugin comes pre-configured with a number of different users and default passwords for them. Passwords for some of the preconfigured users—kibanaro, logstash, readall, and snapshotrestore—are available to change in the Security UI in Kibana. The admin and kibanaserver users are reserved users, and they must be changed in the security configuration files. Default location : /usr/share/elasticsearch/plugins/opendistro_security/securityconfig/internal_users.yml

First run the hash tool to generate a new password hash.

$ sudo bash /usr/share/elasticsearch/plugins/opendistro_security/tools/hash.sh
[Password:] <type a new secure password>
$2y$12$7f9DHLNLV1QkfhM9K5vhVeLpRxM2.7SMfZnAxUhLDJ5AYC/cs9y1S

Now open /usr/share/elasticsearch/plugins/opendistro_security/securityconfig/internal_users.yml in your favorite editor, and change the password string for the just the admin user with the hash created in the previous step.

After changing any of the configuration files in plugins/opendistro_security/securityconfig, however, you must run plugins/opendistro_security/tools/securityadmin.sh to load these new settings into the index.

Each node also includes the tool at plugins/opendistro_security/tools/securityadmin.sh. Make the script executable before running it:

sudo chmod +x /usr/share/elasticsearch/plugins/opendistro_security/tools/securityadmin.sh

To load configuration changes to Security plugin, you must provide your admin certificate to the tool:

cd /usr/share/elasticsearch/plugins/opendistro_security/tools/
sudo ./securityadmin.sh -cd ../securityconfig/ -icl -nhnv -cacert /etc/elasticsearch/root-ca.pem -cert  /etc/elasticsearch/kirk.pem -key  /etc/elasticsearch/kirk-key.pem

Open Distro Security Admin v7
Will connect to localhost:9300 ... done
Connected as CN=kirk,OU=client,O=client,L=test,C=de
Elasticsearch Version: 7.2.1
Open Distro Security Version: 1.2.1.0
Contacting elasticsearch cluster 'elasticsearch' and wait for YELLOW clusterstate ...
Clustername: od4es
Clusterstate: GREEN
Number of nodes: 7
Number of data nodes: 3
.opendistro_security index already exists, so we do not need to create one.
Populate config from /usr/share/elasticsearch/plugins/opendistro_security/securityconfig
Will update '_doc/config' with ../securityconfig/config.yml
   SUCC: Configuration for 'config' created or updated
Will update '_doc/roles' with ../securityconfig/roles.yml
   SUCC: Configuration for 'roles' created or updated
Will update '_doc/rolesmapping' with ../securityconfig/roles_mapping.yml
   SUCC: Configuration for 'rolesmapping' created or updated
Will update '_doc/internalusers' with ../securityconfig/internal_users.yml
   SUCC: Configuration for 'internalusers' created or updated
Will update '_doc/actiongroups' with ../securityconfig/action_groups.yml
   SUCC: Configuration for 'actiongroups' created or updated
Will update '_doc/tenants' with ../securityconfig/tenants.yml
   SUCC: Configuration for 'tenants' created or updated
Done with success
  • The -cd option specifies where the Security plugin configuration files to upload to the cluster can be found.
  • The -icl (–ignore-clustername) option tells the Security plugin to upload the configuration regardless of the cluster name. As an alternative, you can also specify the cluster name with the -cn (–clustername) option.
  • Because the demo certificates are self-signed, we also disable hostname verification with the -nhnv (–disable-host-name-verification) option.
  • The -cacert, -cert and -key options define the location of your root CA certificate, the admin certificate, and the private key for the admin certificate.

For further details on securityadmin.sh, please refer to the documentation.

Users

We will create local users in the internal user database. We'll create 2 users – devops & itsupport

Login to kibana ( http://<client-node-ip>:5601/ ) with the new admin password.

For each user :

  1. Choose Security , Internal User Database , and Add a new internal user ( blue + button ).

  1. Provide the username and choose a password. The Security plugin automatically hashes the password and stores it in the .opendistro_security index.

  1. Choose Submit.

Roles

Roles are the core way of controlling access to your cluster. Roles contain any combination of cluster-wide permissions, index-specific permissions, document- and field-level security, and tenants. Then you map users to these roles so that users gain those permissions. For more details, please refer to the documentation on Permissions and Action Groups

We'll create 2 roles - itsupport-role & devops-role

  1. Choose Security, Roles, and Add a new role.
  2. Provide a name for the role. (itsupport-role / devops-role )
  3. Then add permissions/action groups as below.

Devops role – read access to metricbeat* index

Similarly – itsupport-role – read access to pa-* index

  1. Choose Save Role Definition.

Map users to roles

After creating roles, you map users to them. Intuitively, people often think of this process as giving a user one or more roles, but in the Security plugin, the process is reversed; you select a role and then map one or more users to it.

We'll map itsupport to itsupport-role and devops to devops-role

  1. Choose Security, Role Mappings , and Add a new role mapping.
  2. Select the role. If a role is greyed-out, a mapping for it already exists. Return to the Role Mappings screen and edit the existing mapping.

  1. Specify the corresponding user
  2. Choose Submit

Kibana multi-tenancy

Tenants in Kibana are spaces for saving index patterns, visualizations, dashboards, and other Kibana objects. By default, all Kibana users have access to two tenants: Private and Global. The global tenant is shared between every Kibana user. The private tenant is exclusive to each user and can't be shared.

Tenants are useful for safely sharing your work with other Kibana users. You can control which roles have access to a tenant and whether those roles have read or write access.

Open Kibana to create tenants

  1. Choose Security , Tenants , and add a new tenant.
  2. Give the tenant a name and description.
  3. Choose Submit.

After creating a tenant, give a role access to it

  1. Choose Security , Roles , and Select the role – devops-role.
  2. Select the Tenant Permissions tab at the top and click Add tenant permissions.

  1. Under Tenant patterns , Click Add Tenant and type in the tenant name – devops-tenant
  2. Under Permissions , give the role read or write permissions and Save Role Definition

Test by logging in as different users

Now login as devops and itsupport users and explore kibana and test to ensure the users have the intended permissions.

For example, when you login as devops user, you should only be able to see the metricbeat index, when trying to create an index-pattern. When you API from dev console, you should be able to read metricbeat index but not be able to write or query any other index.