Skip to content

security.adoc

Latest commit

 

History

History
167 lines (131 loc) · 6.67 KB

security.adoc

File metadata and controls

167 lines (131 loc) · 6.67 KB

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.

Important
 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:

link:example$druid-ldap-authentication.yaml[role=include]
Tip
 You can follow the tutorials:authentication_with_openldap.adoc tutorial to learn how to create an AuthenticationClass for an LDAP server.

Reference the AuthenticationClass in your DruidCluster resource:

link:example$druid-ldap-authentication.yaml[role=include]

Check out the tutorials:authentication_with_openldap.adoc 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:

link:example$druid-oidc-authentication.yaml[role=include]

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

link:example$druid-oidc-authentication.yaml[role=include]

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

link:example$druid-oidc-authentication.yaml[role=include]
Note
 OIDC authentication may fail since Druid versions 35.x.x and 36.x.x due to a change in how the authentication method is selected when connecting to an OIDC provider. If your OIDC provider (e.g. Keycloak) advertises private_key_jwt as a supported client authentication method, Druid may attempt to use it, which causes authentication to fail.

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.