Advanced authentication for Data Grid in Red Hat OpenShift 4: LDAP and LDAPS

This is the 2nd part of our series on securing Red Hat Data Grid. While part 1 explored centralized single sign-on (SSO) with Keycloak, this guide focuses on direct directory integration. Whether you are validating directory authentication against a local OpenLDAP test instance or connecting Data Grid directly to corporate Active Directory, this guide walks through the operator configuration and TLS certificate setup directly in the Infinispan custom resource using the spec.configMapName field. 

For background architectures and reference files, see the Red Hat Knowledgebase guide on integrating LDAP and LDAPS with Red Hat Data Grid 8.4 on OpenShift Container Platform 4.

Configure directory integration

To integrate your directory service, complete 3 core steps:

1. Install the Data Grid operator: Deploy the operator to manage your cluster in Red Hat OpenShift.
2. Create the Infinispan custom resource: Define your cluster deployment specifications.
3. Configure LDAP realm settings: Reference a ConfigMap in spec.configMapName containing your LDAP server URL, principal credentials, search DN, and user role mappings.

When you require encrypted communications using LDAPS, complete the base LDAP setup and configure Transport Layer Security (TLS):

1. Obtain the LDAP server TLS certificate: Export the certificate from your directory server or issuing certificate authority.
2. Import the certificate into Data Grid pods: Reference a secret containing the TLS certificate using spec.security.endpointEncryption.clientCertSecretName on the Infinispan custom resource.
3. Define the client verification strategy: Set clientCert to Validate or Authenticate if you want to enforce client certificate authentication. Otherwise, set the value to None while still providing the server certificate to the truststore.

1. Deploy OpenLDAP

For local testing and validation, deploy a lightweight OpenLDAP instance into a dedicated namespace using the community Helm chart:

#!/bin/bash

#Assumes is already logged in OCP cluster
oc new-project openldap
oc create secret generic openldap --from-literal=adminpassword=adminpassword --from-literal=users=user01,user02 --from-literal=passwords=password01,password02

#Assumes has already installed helm cli in the environment
helm install openldap openldap-ocp

The following example values file configures OpenLDAP using the OpenLDAP Helm chart:

# Default values for openldap-ocp.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

replicaCount: 1
image:
  repository: docker.io/bitnami/openldap
  pullPolicy: IfNotPresent
  # Overrides the image tag whose default is the chart appVersion.
  tag: "latest"
imagePullSecrets: []
nameOverride: ""
fullnameOverride: ""
serviceAccount:
  # Specifies whether a service account should be created
  create: true
  # Annotations to add to the service account
  annotations: {}
  name: ""
podAnnotations: {}
podSecurityContext: {}
  # fsGroup: 2000
service:
  type: ClusterIP
  port: 1389

ingress:
  enabled: false
  className: ""
  annotations: {}
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
  hosts:
    - host: chart-example.local
      paths:
        - path: /
          pathType: ImplementationSpecific
  tls: []

resources: {}
autoscaling:
  enabled: false
  minReplicas: 1
  maxReplicas: 100
  targetCPUUtilizationPercentage: 80
nodeSelector: {}
tolerations: []
affinity: {}
securityContext:
  capabilities:
    drop:
    - ALL
    add:
    - NET_BIND_SERVICE
env:
  - name: LDAP_ADMIN_USERNAME
    value: "admin"
  - name: LDAP_ADMIN_PASSWORD
    valueFrom:
      secretKeyRef:
        key: adminpassword
        name: openldap
  - name: LDAP_USERS
    valueFrom:
      secretKeyRef:
        key: users
        name: openldap
  - name: LDAP_PASSWORDS
    valueFrom:
      secretKeyRef:
        key: passwords
        name: openldap

2. Configure the Data Grid operator for LDAP

For the Data Grid operator, custom configuration is provided through the ConfigMap specified in spec.configMapName on the Infinispan custom resource:

oc get infinispan example-infinispan-realm -o yaml
apiVersion: infinispan.org/v1
kind: Infinispan
metadata:
  annotations:
    infinispan.org/monitoring: "true"
    infinispan.org/operatorPodTargetLabels: rht.comp,rht.comp_ver,rht.prod_name,rht.prod_ver,rht.subcomp_t
  labels:
    rht.comp: Data_Grid
    rht.comp_ver: 8.5.3
  name: example-infinispan-realm
  namespace: dg-custom-realm
spec:
  configListener:
    enabled: true
    logging:
      level: info
  configMapName: security-config
  container:
    memory: 1Gi
  expose:
    type: Route
  jmx: {}
  logging:
    categories:
      org.infinispan.SERVER: debug
      org.wildfly.security: trace
  replicas: 1
  scheduling:
    affinity:
      podAntiAffinity:
        preferredDuringSchedulingIgnoredDuringExecution:
        - podAffinityTerm:
            labelSelector:
              matchLabels:
                app: infinispan-pod
                clusterName: example-infinispan-realm
                infinispan_cr: example-infinispan-realm
            topologyKey: kubernetes.io/hostname
          weight: 100
  security:
    endpointAuthentication: true
    endpointEncryption:
      clientCert: None
      type: None
    endpointSecretName: example-infinispan-realm-generated-secret
  service:
    container:
      livenessProbe:
        failureThreshold: 5
        initialDelaySeconds: 0
        periodSeconds: 10
        successThreshold: 1
        timeoutSeconds: 1
      readinessProbe:
        failureThreshold: 5
        initialDelaySeconds: 0
        periodSeconds: 10
        successThreshold: 1
        timeoutSeconds: 1
      startupProbe:
        failureThreshold: 600
        initialDelaySeconds: 3
        periodSeconds: 1
        successThreshold: 1
        timeoutSeconds: 1
      storage: 1Gi
    type: DataGrid
  upgrades:
    type: Shutdown
  version: 8.5.3-2

Following the operator custom configuration pattern, define your LDAP connection details inside the data section of the ConfigMap resource, which is referenced by the Infinispan custom resource.

$ oc get cm security-config -o yaml
apiVersion: v1
data:
  infinispan-config.xml: |
    <infinispan>
      <server>
        <security>
          <credential-stores>
             <credential-store name="credentials" path="credentials.pfx">
                <clear-text-credential clear-text="secret"/>
             </credential-store>
          </credential-stores>
          <security-realms>
           <security-realm name="default">
             <!-- Specifies connection properties - this is the LDAP's service (SVC) -->
             <ldap-realm url="ldap://openldap-openldap-ocp.openldap.svc.cluster.local:1389"
                        principal="cn=admin,dc=example,dc=org"
                        credential="adminpassword"
                        connection-timeout="3000"
                        read-timeout="30000"
                        connection-pooling="true"
                        referral-mode="ignore"
                        page-size="30"
                        direct-verification="true">
              <!-- Defines how principals are mapped to LDAP entries. -->
              <identity-mapping rdn-identifier="uid"
                                search-dn="ou=users,dc=example,dc=org"
                                search-recursive="false">
                <!-- Retrieves all the groups of which the user is a member. -->
                <attribute-mapping>
                  <attribute from="cn" to="readers"
                             filter="(&(objectClass=groupOfNames)(member={1}))"
                             filter-dn="ou=readers,dc=example,dc=org"/>
                </attribute-mapping>
                <user-password-mapper from="userPassword"/>
              </identity-mapping>
            </ldap-realm>
           </security-realm>
          </security-realms>
        </security>
      </server>
    </infinispan>
immutable: false
kind: ConfigMap
metadata:
  name: security-config
  namespace: dg-custom-realm

Verify the Infinispan custom resource has the correct ConfigMap settings and then log into Data Grid with the LDAP user details.

$ oc get infinispan
NAME                 AGE
example-infinispan-realm   17m
...
apiVersion: infinispan.org/v1
kind: Infinispan
metadata:
  name: example-infinispan-realm
  namespace: dg-custom-realm
spec:
  replicas: 1
  configMapName: security-config <---- Config Map above

3. Configure TLS encryption for LDAPS

The LDAPS configuration builds on base LDAP by introducing Transport Layer Security (TLS) to encrypt traffic between Data Grid and your directory service.

1. Obtain the LDAP server TLS certificate: Export the root CA or server certificate from your directory server.
2. Create an OpenShift secret: Store the certificate in a secret within the Data Grid namespace (for example, named ldap-tls-secret).
3. Reference the secret in the Infinispan CR: Configure spec.security.endpointEncryption with clientCertSecretName and choose your verification strategy:
   • clientCert: None: Data Grid imports the secret into its truststore to validate the remote LDAPS server certificate, without enforcing client certificates for incoming connections.
   • clientCert: Validate or Authenticate: Enforces mutual TLS (mTLS), validating incoming client certificates against the certificates provided in clientCertSecretName.
4. Update the connection URL: In your security-config ConfigMap, change the LDAP protocol and port to secure LDAPS (for example, ldaps://...:1636 or ldaps://...:636).

Summary of directory authentication

When deciding between plain LDAP and LDAPS in Red Hat OpenShift, remember that internal cluster traffic between pods is unencrypted by default unless you enable LDAPS or rely on OpenShift Service CA encryption.

• LDAP: Best suited for isolated dev/test environments where traffic remains strictly internal to the cluster network.
• LDAPS: Essential for production workloads to protect credentials in transit and verify identity using mutual TLS.

Keycloak SSO vs. direct LDAP: Which should you choose?

Both methods secure access to Data Grid clusters, but they address different architectural requirements:

Next steps and resources

Binding Data Grid directly to your directory service keeps your architecture lean. If your team does not need the extra operational surface area of a full SSO identity provider, direct LDAP binding gives you centralized access control with minimal operational overhead.

With LDAP/LDAPS authentication established, your next step is defining authorization roles to govern cache access. Explore the Red Hat Data Grid documentation to configure role mapping and cache-level authorization, or learn how to automate certificate rotation for LDAPS endpoints.

To continue hardening your deployment, explore these guides:

• Review the first article in this series if you prefer a centralized OpenID Connect (OIDC) or SSO architecture: Advanced authentication for Data Grid in Red Hat OpenShift 4: Keycloak and SSO
• For Data Grid deployment in Helm charts, see How to use Helm charts to deploy Data Grid on OpenShift.

Running into snags while configuring your realm? Reach out through the Red Hat customer portal or connect with our community on the Data Grid forums to share your architecture and get feedback. Special thanks to Santoshi Atmakuru, Will Russell, and the security team for their collaboration, testing, and feedback on this architecture.