Security

• PKI in Elasticsearch
• Securing data-in-transit
• Certificates
• Securing data-at-rest
• Role-based access
• Sensitive data

PKI in Elasticsearch

Beginning with version 5.0, the old TLS enablement plug-in was deprecated and replaced with a new plug-in called X-Pack. X-Pack offers a number of extra features that are marketed to Enterprise users, but a license is required. The features are free for a 30-day limited-use period, after which all X-Pack functions are disabled.

Search Guard is another product that offers security-related plug-ins for the ELK stack. In contrast to X-Pack, some of its features are offered under a community edition category with no limitation on use. As stated by the readme file: Search Guard offers all basic security features for free. The Community Edition of Search Guard can be used for all projects, including commercial projects, at absolutely no cost. TLS encryption with PKI is one of these community edition features.

By default, the IBM Cloud Private ELK stack uses Search Guard to provide PKI. If you already have a license for X-Pack, or plan to purchase one, you can specify the following parameters during deployment to configure the ELK stack to use X-Pack's PKI implementation. The customer is responsible for installation of the license after deployment.

   logging:
     security:
       provider: xpack

Securing data-in-transit

Each deployment of the Elasticsearch stack is secured by default with mutual authentication over TLS. The managed ELK stack is also configured to use the IBM Cloud Private certificate authority to sign the certificates used by the stack. All other ELK stacks default to create their own certificate authority on deployment. To toggle security on or off for more ELK stacks, disable security in the catalog UI or the values override file for Helm deployment.

Helm

The following snippet can be added to a values override file for Helm deployment to enable or disable security.

  security:
    enabled: true|false

Certificates

All connections to Elasticsearch must be configured to exchange a properly signed certificate when security is enabled. The IBM Cloud Private ELK stack architecture generates a number of certificates to apply to discrete roles. All are stored in the same Kubernetes secret and use the following naming convention: <release_name>-ibm-icplogging-certs.

Securing data-at-rest

The Elasticsearch stack does not offer data encryption at rest internally. The Elastic company recommends third-party solutions to achieve this goal. IBM Cloud Private has instructions for supported methods of encrypting data on disk. For more information, see Encrypting volumes that are used by IBM Cloud Private.

Role-based access

Version 2.0.0 of the ibm-icplogging Helm chart (included in IBM Cloud Private 3.1.0) introduced a new module that provides role-based access controls (RBAC) for all Elasticsearch REST API invocations. The new module is available only for managed ELK stacks.

The RBAC module is effectively a proxy that sits in front of each Elasticsearch client pod. All connections are required to have certificates signed by the Elasticsearch cluster CA. By default, this is the IBM Cloud Private root CA. The RBAC module examines the request for an authorization header and at that point enforces role-based controls. In general, the RBAC rules are as follows:

1. A user with the role ClusterAdministrator can access any resource, whether audit or application log.
2. A user with the role Auditor is only granted access to audit logs in the namespaces for which that user is authorized. If audit logs are routed to ELK rather than the suggested existing enterprise SIEM tool, see IBM Cloud Private audit logging integration with enterprise SIEM tools.
3. A user with any other role can access application logs only in the namespaces for which that user is authorized.
4. Any attempt by an auditor to access application logs, or a non-auditor to access audit logs, is rejected.

The RBAC rules provide basic data retrieval control for users that access Kibana. The rules do not prevent seeing metadata such as log field names or saved Kibana dashboards.

Sensitive data

You might be required to mask sensitive data before it reaches Elasticsearch. Logstash deploys with a helpful plugin named Mutate that offers many functions for locating data that is considered to be sensitive. Adding these masks requires customization of the Logstash configuration, which is typically found in a configmap resource named <release_name>-ibm-icplogging-logstash-config. release_name refers to the release name given to a specific Helm chart deployment.

Modifications to the Logstash configuration will automatically propagate to the deployed containers after a short delay.

Modifications to configuration maps are lost if you redeploy the logging chart. For example, if you upgrade to a new version.