Security

Secure your Apache Druid Stacklet by enabling TLS encryption, user authentication and authorization.

Encryption

TLS encryption is supported for internal cluster communication (e.g. between Broker and Coordinator) as well as for external communication (e.g. between the browser and the Router web UI).

spec:
  clusterConfig:
    tls:
      serverAndInternalSecretClass: tls (1)

1	Name of the SecretClass that is used to encrypt internal and external communication.

A Druid Stacklet is always encrypted per default i.e. spec.clusterConfig.tls.serverAndInternalSecretClass: tls in the above example does not need to be specified as it is applied by default: in order to disable this default behavior you can set spec.clusterConfig.tls.serverAndInternalSecretClass: null.

Authentication

TLS

The access to the Druid cluster can be limited by configuring client authentication (mutual TLS) for all participants. This means that processes acting as internal clients (e.g. a Broker) or external clients (e.g. a Browser) have to authenticate themselves with valid certificates in order to communicate with the Druid cluster.

spec:
  clusterConfig:
    authentication:
      - authenticationClass: druid-tls-auth (1)

1	Name of the AuthenticationClass that is used to encrypt and authenticate communication.

The AuthenticationClass may or may not have a SecretClass configured:

---
apiVersion: authentication.stackable.tech/v1alpha1
kind: AuthenticationClass
metadata:
  name: druid-mtls-authentication-class
spec:
  provider:
    # Option 1
    tls:
      clientCertSecretClass: druid-mtls (1)
    # Option 2
    tls: {} (2)

1	If a client SecretClass is provided in the AuthenticationClass (here `druid-mtls`), these certificates are used for encryption and authentication.
2	If no client SecretClass is provided in the AuthenticationClass, the `spec.clusterConfig.tls.serverAndInternalSecretClass` is used for encryption and authentication. It cannot be explicitly set to null in this case.

LDAP

Druid supports authentication of users via an LDAP server. This requires setting up an AuthenticationClass for the LDAP server:

apiVersion: authentication.stackable.tech/v1alpha1
kind: AuthenticationClass
metadata:
  name: ldap-auth
spec:
  [...]

You can follow the Authentication with OpenLDAP tutorial to learn how to create an AuthenticationClass for an LDAP server.

Reference the AuthenticationClass in your DruidCluster resource:

apiVersion: druid.stackable.tech/v1alpha1
kind: DruidCluster
metadata:
  name: druid
spec:
  clusterConfig:
    authentication:
      - authenticationClass: ldap-auth
  [...]

Check out the Authentication with OpenLDAP tutorial to see a complete example of how to set LDAP authentication for another Stackable operator. You can also consult the AuthenticationClass reference, or the LDAP test suite.

OIDC

Druid supports authentication of users of the web console against a OIDC provider. This requires setting up a AuthenticationClass for the OIDC provider:

apiVersion: authentication.stackable.tech/v1alpha1
kind: AuthenticationClass
metadata:
  name: oidc-auth
spec:
  provider:
    oidc:
  [...]

Reference the AuthenticationClass and a secret containing OIDC client credentials in your DruidCluster resource:

apiVersion: druid.stackable.tech/v1alpha1
kind: DruidCluster
metadata:
  name: druid
spec:
  clusterConfig:
    authentication:
      - authenticationClass: oidc-auth
        oidc:
          clientCredentialsSecret: druid-oidc-client
  [...]

The secret containing the OIDC client credentials should be structured like this:

apiVersion: v1
kind: Secret
metadata:
  name: druid-oidc-client
stringData:
  clientId: <client-id>
  clientSecret: <client-secret>

Current Limitations and Upcoming Work

At the moment you can either use TLS, LDAP or OIDC authentication but not a combination of authentication methods.

Druid doesn’t support LDAP authentication without bind credentials. See our issue for details.

Authorization is done using the allowAll authorizer or OPA (see below).

Authorization with Open Policy Agent (OPA)

Druid can connect to an Open Policy Agent (OPA) instance for authorization policy decisions. You need to run an OPA instance to connect to: for this, please refer to the OPA Operator docs. A short explanation of how to write RegoRules for Druid is given below.

Once you have defined your rules, you need to configure the OPA cluster name and endpoint to use for Druid authorization requests. Add a section to the spec for OPA:

spec:
  clusterConfig:
    authorization:
      opa:
        configMapName: simple-opa (1)
        package: my-druid-rules (2)

1	The name of your OPA Stacklet (`simple-opa` in this case)
2	The RegoRule package to use for policy decisions. The package needs to contain an `allow` rule. This is optional and defaults to the name of the Druid Stacklet.

Defining RegoRules

For a general explanation of how rules are written, please refer to the OPA documentation. Inside your rule you have access to input from Druid. Druid provides this data to you to base your policy decisions on:

{
  "authenticationResult": {
    "identity": <String>, (1)
    "authorizerName": <String>,
    "authenticatedBy": <String>,
    "context": Map<String, Object>,
  }
  "action": <String: READ|WRITE> (2)
  "resource": {
    "name": <String>, (3)
    "type": <String> (4)
  }
}

1	The authenticated identity of the user that wants to perform the action
2	The action type, can be either `READ` or `WRITE`.
3	In case of a datasource this is the table name, for `STATE` this is simply `STATE`, the same for `CONFIG`.
4	The resource type, one of `STATE`, `CONFIG` and `DATASOURCE`.

For more details consult the Druid Authentication and Authorization Model.