By default, Apache Druid® installed with most security features disabled. This provides a simple experience for developers to get started quickly and easily. For production environments, or any Druid cluster that is exposed to the Internet, security features should be configured and enabled.
Whenever any action is requested, Druid uses Authenticators to check if a credential is valid and mapped to a role and Authorizers to check if the role has the READ or WRITE permissions to execute the action requested. If approved, the action is executed and a final Sanity Check re-validates security permissions before returning the result to the client.
Druid Security Checklist
- Network Security
- Best Practices
Druid authorization is a combination of resources and actions, as a basis for role-based access control.
There are only 2 actions: READ and WRITE.
READ allows HTTP GET requests and SQL SELECT
The WRITE action does not include READ permissions, so a role that needs both READ and WRITE access to a resource needs to have both explicitly assigned.
There are several resources. Each Druid table is a DATASOURCE. The CONFIG, security, and STATE resources control access to various administrative endpoints. EXTERN controls the ability to use the SQL EXTERN function to include datasets in a query that are not ingested into Druid.
Resources and actions for Druid Role-based access control
Note that permissions cannot be assigned to users, only to roles (which are then assigned to one or more users). Of course, it’s possible to set up a role that is only mapped to a single user.
For most Druid installations, only two roles are required: an Administrator role with READ and WRITE access to all resources and a User role with READ access to each DATASOURCE and EXTERN.
There are also two system accounts that can be enabled: admin and druid_system. Each have full READ and WRITE privileges to all resources.
See the Druid Security Overview for instructions and examples on how to configure authorizers.
Druid used LDAP for user authentication. You’ll need to have an LDAP-compatible service running with defined users and groups.
Follow the steps in the Configure Druid for LDAP Authentication documentation to connect your Druid cluster with your LDAP service.
Once this is done, you can map LDAP groups that contain one or more users to Druid roles. Every user in that group will now have all the of READ and WRITE permissions granted to the associated role.
An example mapping LDAP users to an LDAP group to a Druid role
All network communications in Druid should be encrypted using TLS (Transport Layer Security). You will need an active certificate and keys.
Once you’re ready, follow the steps in this Enable TLS tutorial to encrypt your Druid network communications.
Once TLS is enabled, you can use the same certificate and keys to enable secure LDAP-over-SSL (LDAPS). Follow the steps in the Enable LDAP over TLS section of the Druid documentation.
Once you’ve configured authentication, authorization, and network security, there are a few additional best practices for a secure Druid cluster:
On the installation servers, always run Druid services using a user account. Never run Druid using a root account, as it may enable access to the operating system and privileged files.
Always grant users the minimum permissions needed to do their jobs. For non-administrators, this usually means READ access to the DATASOURCES they need (and, perhaps, to EXTERN).
The Druid console is a powerful tool. Make sure that only trusted users have access to run it. Don’t expose the interface to the Internet!
Avoid using plaintext passwords and keys in configuration files. Instead, store them as system environment variables.
Remember to periodically test your security configuration. Try to access Druid and execute queries or other actions without the right credentials – and make sure it fails!