Note: This is a guest post by Jochen Kressin, the CTO of floragunn GmbH, the makers of Search Guard, an open-source X-Pack Security alternative.
Elasticsearch is a great piece of software. We really love it. However, there is one major drawback: Elasticsearch does not have any security capabilities built in. Anyone who has access to your network can see, modify and delete any data. Which leaves your cluster wide open for malicious hackers.
Welcome to Search Guard – the security suite for Elasticsearch and the entire ELK stack.
When it comes to security for Elasticsearch, Search Guard is your Swiss army knife to implement security solutions tailored to your needs and your infrastructure. Regardless of whether you just want to encrypt data in transit, authenticate users against Active Directory, use Kerberos or JSON web tokens for Single Sign On or need to monitor and log malicious access attempts, Search Guard is your one-stop solution. And the best part is that the basic version comes for free!
Features
The four pillars of security
Encryption – protect against sniffing, snooping and tampering
The first step of securing your data is to implement encryption. Search Guard provides SSL/TLS encryption for node-to-node traffic, REST traffic and transport client traffic. Your sensitive data is always secure as it travels across the network, even if an attacker gains access to your infrastructure. By leveraging TLS, you make sure that
- No one can sniff your data
- No one can tamper with your data
- Only authenticated nodes can join your cluster
In order to minimize the performance impact of applying encryption, Search Guard supports native OpenSSL. OpenSSL provides superior performance over the standard Java Cryptography Extensions, and also comes with a wider, more modern range of cipher suites.
Authentication and authorization – control who has access to your data
Search Guard offers a wide range of pluggable authentication modules to choose from. The free version comes with an integrated user database, HTTP Basic Authentication as well as certificate- and proxy based authentication. The enterprise version offers advanced authentication modules for LDAP/Active Directory, Kerberos and JSON web tokens. You can even combine authorization modules! Depending on your configuration, Search Guard extracts the user credentials from the request, authenticates them against the configured modules, and assigns roles to the user.
Role-based permissions – at every level, as granular as you need
Permissions can be configured on cluster, index, document and field level, and they can be as granular as you need them to be.
- Cluster-level
- Who can access nodes stats or check the cluster health?
- Index-level
- Who can create, modify or delete documents of certain types?
- Document-level
- Who has access to sensitive documents in the result set?
- Field-level
- Which fields are visible for the currently logged in user?
Search Guard ships with many predefined permission sets, like READ, WRITE, SEARCH or CREATE_INDEX. If you need more fine grained permissions, simply define and use your own permission set. Want to restrict the execution of bulk operations to DevOps only? Want to exclude certain users from creating an index alias? Search Guard gives you full control over all permitted activities, down to the single action level.
Audit logging – stay compliant
The audit log module keeps track of all user activity in your cluster, and lets you configure which events you want to record. From tracking failed login attempts only to record everything that’s going on in your cluster, just configure what you want to see and let Search Guard do the rest.
The audit events can be stored in the same or a separate Elasticsearch cluster for further analysis. You can also use an off-site service such as Logsene, so malicious hackers won’t be able to cover their tracks. Do you already have a SIEM system in place? No problem, Search Guard can ship the audit events to any external system that supports webhooks, too. And it even has a public API so that you can create your own storage implementation if necessary.
Bonus: Kibana Multitenancy
Kibana does not support multi tenancy out of the box. This means that all saved objects, like visualizations and dashboards, are stored globally and are potentially accessible by any user. This is where the Search Guard multi tenancy module comes to the rescue!
Define one or more tenants for each Search Guard role, and enjoy true separation of saved searches, visualizations and dashboards in Kibana. Create dedicated dashboards for each department, and perhaps share other dashboards company wide. The multi tenancy module integrates deeply into Elasticsearch itself and uses the same battle-proven access control as Search Guard. So even if someone tries to access your sensitive dashboards by circumventing Kibana, your data is always safe.
Configuration management simplified
The complete user, role and permission configuration is stored in a dedicated Search Guard index in Elasticsearch itself. You can use the sgadmin command line tool, or the REST management API to apply changes.
This approach simplifies the configuration management in many aspects:
- Config hot reloading – no restarts required
- Any changes to the configuration are propagated to all nodes in the cluster automatically. They take effect immediately without requiring a node restart. Add and remove roles, change permissions or activate document level security, all while you’re cluster is running.
- Single place for configuration
- Since the configuration is kept in an Elasticsearch index, there’s no need anymore to place sensitive configuration files on each node physically. Manage the complete Search Guard configuration from a single place.
- Update from any machine
- You can change the configuration from any machine that has access to the transport port of your cluster.
Security means Open Source by definition
When talking about security solutions, then closed source software is a no go. If you cannot inspect the code, you cannot be sure that the implementation is sound, solid and does what it’s supposed to do. You can’t even make sure that the software does not call home, or that it does not contain backdoors.
We strongly believe that if you are serious about security, you need to have the option to inspect the code, run your own security audits, and build the software yourself if required. Search Guard is completely Open Source, so you have full access to the source code, including all enterprise modules. Don’t just take our word for granted, and audit our code yourself, like many major companies already did.
Where to go next?
Read our post on how to secure Kibana for free by using the Community edition of Search Guard:
Explore other alternatives to X-Pack components
Head over to the Search Guard GitHub repository and check the quick start guide:
https://github.com/floragunncom/search-guard
Deep-dive into Search Guard by reading the official documentation:
https://github.com/floragunncom/search-guard-docs
Ask questions on the Search Guard Google Group:
https://groups.google.com/forum/#!forum/search-guard
Read about our fair, flexible and affordable enterprise license model:
https://floragunn.com/searchguard/searchguard-license-support/
Follow us on Twitter to stay up-to-date with new releases and features:
https://twitter.com/searchguard