Security

Abstract

The punch integrates the security plugin from amazon opendistro. It allows you to protect your data, and to define various role-based access control rules so as to expose your data to your users the way you need.

Overview

In this guide, you will learn to :
1. Equip your punch with the security plugins
2. Secure your cluster with authentication and access control

Installation

First, make sure that Elasticsearch and Kibana are not running.

punchplatform-standalone.sh --stop

Then enable the security plugin. This can be performed on your existing standalone.

cd ${PUNCHPLATFORM_CONF_DIR}/..
./install.sh -s --with-opendistro-security
source ./activate.sh

and restart your platform

punchplatform-standalone --start

Once ElasticSearch and Kibana are running, open a web browser and go to http://localhost:5601. You should hit this window :

Congratulations ! You have secured ElasticSearch and Kibana with authentication and access control for your cluster ! It is as simple as that.

Walkthrough

This presentation will go through the Kibana interfaces, but keep in mind that all the configuration steps described below can be performed through configuration files.

First, log on to Kibana with user admin and password admin.

Security

When you are connected, click on the Security tab. You should see this:

Let us describe this security interface :

Category	Description
Action Groups	Provides the creation of actions (a set of permissions) to grant access to a data type or API
Roles	Provides the creation of roles to define a scope for action groups on clusters, indices, documents or fields. It also provides the creation of tenants
Users	Provides the creation of user accounts
Role Mappings	Provides the mappings between the created roles and the created users
Authentication and Authorization	Provides information about the authentication and authorization mechanisms used for your ElasticSearch instance

The most important thing to understand is role management. Go to Roles, then click on all_access role to edit it.

The sections that can be edited are :

Section	Description
Overview	A summary of all users, backend roles and host permissions affected to the roles
Cluster Permissions	Provides cluster-wide permissions by assigning action groups to the cluster
Index Permissions	Provides index permissions by assigning action groups to indices and document types
DLS/FLS	Provides document and field permissions by writing an ElasticSearch query that affect an index. Also provides a way to include, exclude or anonymize fields
Tenants	Provides tenant permissions for the current role, based on read/write access

As you can see, the security plugin is focusing on indices and documents access control. You can now manage actions and roles, create users and bind them all together with mappings inside the Security tab to grant permissions to your data.

Tenants

Click on the Tenants tab. You should see this:

From Opendistro security plugin, this feature allows a user to self-manage the access controls to its own index patterns, visualizations and dashboards and to protect them from other users. Each tenant can be understood as a workspace where a user's monitoring creations are stored.
For example, if a visualization is created with the private tenant selected, this visualization will not be viewable from any other selected tenant or user.

The default tenants are :

tenant name	Description
Global	Accessible from any other tenant or user
Private	Accessible from this tenant and user only
{custom name}	Attached to a role, this tenant is accessible for any other user who shares the same role

For example, the tenant admin_tenant can be accessed from any other user who has the all_access role.

Influence on PunchPlatform components

Since a basic authentication is now needed to connect to Elasticsearch, additional settings must be placed in every components that needs to read or write data in Elasticsearch indices.

Topologies

Additional settings for ElasticSearch spouts and bolts are needed. Please check credential setting : * elasticsearch_spout * elasticsearch_bolt

Data analytics nodes

In pml files, add inside elastic_settings :

{
  ...,
    elastic_settings : {
      es.net.http.auth.user: user
      es.net.http.auth.pass: pass
    },
  ...
}

Demonstration

The punch ships with a small demo so that you can play right away with some data, users and roles.

Installation

First, make sure that ElasticSearch and Kibana are running, then execute :

$PUNCHPLATFORM_CONF_DIR/samples/opendistro/install_demo.sh

When it is DONE, go to your running Kibana instance and connect to the admin account with user admin, password admin.
Click on Management > Index Patterns. You can see two new indices : ppsecurity_q1 and ppsecurity_q2.

Demonstration Use case

Consider a monitoring project named PPSecurity.

The monitoring activity is lasting for several month so monitoring data was split into two quarters : Q1 and Q2.
The data contain connection information about four projects (Project A, B, C and D) in two working zones (Zone 1 and 2), as follows :

Zone 1	Zone 2
Project A and B	Project C and D

On kibana, through roles, role mappings and user definitions, you can gather the following information :

role	permissions	role mapping (users)
head_manager	Grant access to all data of PPSecurity	Sam
project_manager	Grant access to all documents in Zone 1	Rosie
engineer	Can only monitor data for index ppsecurity_q1	Merry

Thus, Rosie, who is a project manager, can access to any data in all indices that concerns all the projects inside the first zone only.

Practice

As head manager

Logout from admin and connect to Sam account with username sam and password samsam. You can notice that you have no rights to manage the security tab from this user anymore, since you are not currently logged as the admin user.

Go to Tenants tab and select Private tenant.

Go to Management tab and define a new index pattern with pp*. Choose fields.event_timestamp as time filter then click on Create index pattern. Now, by clicking on Discover tab and by selecting your new index pattern, you can display 4 documents with various information about zones and projects that are all the data available for the project PPSecurity, since head_manager has no restrictions on PPSecurity indices.

To push the experience a little further, go to Tenant tab and select another tenant then go back to Discover tab. Your previous index named pp* is not accessible anymore. You can restore it by selecting the tenant you were in when you created the index pattern. This is how tenants work.

As engineer

Let us now check Merry's permissions by connecting to the admin user and go to Security > Roles > engineer > Index Permissions

Because of INDICES_ALL action group permission assigned to index ppsecurity_q1, Merry will be able to monitor all data inside this index but he also won't be able to access to ppsecurity_q2's data at all.

Now log in merry account with password merry.

Go to Management tab then click on Index Patterns. As explained above, the only index visible for Merry is the one we just precised in security settings for his role. You can now create an index pattern by defining ppsecurity_q1 then any visualizations or dashboards from its data, but Merry will never access to ppsecurity_q2 index.

Feel free to change the index pattern for permissions or even action groups to test all the possibilities of Index Permissions security settings.

As project manager

Let us check Rosie's permissions by connecting to the admin user and go to Security > Roles > project_manager > DLS/FLS. Check the ElasticSearch query written for index pattern pp* :

{
  "bool": {
    "must": {
      "match": {
        "fields.cloud.zone_type": "Zone1"
      }
    }
  }
}

Because of this query, Rosie can access to any document containing "Zone1" as value for the field "fields.cloud.zone_type" inside any index beginning with "pp".

Now log in rosie account with password rosie.

Go to Management tab and create a new index pattern with pp*, then display documents in Discover tab. As explained above, the only documents visible for Rosie are those with the value Zone1 for zone_type field, without taking into account the project names.

Another possibility is to change this query to grant to Rosie the access to all documents containing ProjectA or ProjectC as value of the field fields.user.project :

{
  "bool": {
    "must": {
      "bool": {
        "should": [
          {
            "match": {
              "fields.user.project": "ProjectA"
            }
          },
          {
            "match": {
              "fields.user.project": "ProjectC"
            }
          }
        ]
      }
    }
  }
}

Rosie can now access to all document matching this query. The permissions are immediately updated on the Rosie's account.

Feel free to change the index pattern or even the entire query to test all the possibilities of DLS/FLS security settings.

Going further

You have learned how to manage users access rights on indices, documents or even fields, try now to create a new user and assign to it one of the existing roles. Then play with tenants by creating dashboards in private and role's tenant and see what happens by switching between the different dashboards of the user's accounts.