Security

The Druid cluster can be secured and protected in multiple ways.

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 Stackable Druid cluster is always encrypted per default i.e. spec.clusterConfig.tls.serverAndInternalSecretClass: tls in the above example does not need to be specified as it will be 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 will be used for encryption and authentication.
2	If no client `SecretClass` is provided in the `AuthenticationClass`, the `spec.clusterConfig.tls.serverAndInternalSecretClass` will be used for encryption and authentication. It cannot be explicitly set to null in this case.

LDAP

Druid supports authentication of users against 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.

Using an LDAP server without bind credentials is not supported. This limitation is due to Druid not supporting this scenario. See our issue for details.

Authorization is done using the allowAll authorizer. Support for memberOf and OPA authorization is planned.

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 cluster (`simple-opa` in this case)
2	The RegoRule package to use for policy decisions. The package should contain an `allow` rule. This is optional and will default to the name of the Druid cluster.

Defining RegoRules

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

{
  "user": "someUsername", (1)
  "action": "READ", (2)
  "resource": {
    "type": "DATASOURCE", (3)
    "name": "myTable" (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	The resource type, one of `STATE`, `CONFIG` and `DATASOURCE`.
4	In case of a datasource this is the table name, for `STATE` this will simply be `STATE`, the same for `CONFIG`.

For more details consult the Druid Authentication and Authorization Model.