- PKI in Elasticsearch
- Securing data-in-transit
- Securing data-at-rest
- Role-based access
- Sensitive data
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.
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. 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:
|ELK role||Description||Secret key name||Keystore||Key format|
|Initialization||Initializes Search Guard settings||sgadmin||JKS||PKCS12|
|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|
|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|
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 disk.es.md).
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
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:
- A user with the role
ClusterAdministratorcan access any resource, whether audit or application log.
- A user with the role
Auditoris only granted access to audit logs in the namespaces for which that user is authorized.
- A user with any other role can access application logs only in the namespaces for which that user is authorized.
- 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.
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 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.