PKI in Elasticsearch

There are two types of traffic for Elasticsearch: HTTP REST API traffic and peer-to-peer internal TCP traffic. Your product ELK stack uses Nginx to provide 2-way TLS security over Elasticsearch HTTP REST API. The internal traffic is restricted to the internal Elasticsearch pods.

Note: IBM requires IPSec between Kubernetes nodes for increased security.

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 your product certificate authority to sign the certificates used by the stack. All other ELK stacks default to create their own certificate authority on deployment.


All connections to Elasticsearch must be configured to exchange a properly signed certificate when security is enabled. The your product 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.

ELK role Description Secret key name Keystore Key format
Initialization Initializes Search Guard settings sgadmin JKS PKCS12
Superuser Elasticsearch administrator superuser PEM PKCS1
Filebeat Client to Logstash filebeat PEM PKCS1
Logstash Server for Filebeat Logstash PEM PKCS8
Logstash Client for Elasticsearch log stream Logstash-monitoring JKS PKCS12
Logstash Client for Elasticsearch monitoring Logstash-elasticsearch JKS PKCS12
Elasticsearch REST API server Elasticsearch JKS PKCS12
Elasticsearch Intra-node transport Elasticsearch-transport JKS PKCS12
Curator Client to Elasticsearch REST API Curator PEM PKCS1
Kibana Client to Elasticsearch REST API Kibana PEM PKCS8
Kibana proxy Server for incoming connections Kibanarouter PEM PKCS1

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. Your product has instructions for supported methods of encrypting data on

Role-based access

Version 2.0.0 of the ibm-icplogging Helm chart introduced a new module that provides role-based access controls (RBAC) for all Elasticsearch REST API invocations. The new module is available for both managed ELK stacks, and standard ELK stacks.

The RBAC module is effectively a proxy that sits in front of each Elasticsearch client pod. All connections must include certificates that are signed by the Elasticsearch cluster CA. By default, this cluster is your product 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.
  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 Opens in a new tab 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 configuration maps are not supported by IBM and are lost if you redeploy the logging chart. For example, if you upgrade to a new version.