Technology7 min read

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

By · Published by Everything Blog

In short

Whether you validate against a local OpenLDAP test instance or connect directly to corporate Active Directory, this guide walks through operator configuration and TLS certificate setup directly in the Infinispan custom resource. **Configure LDAP Realm Settings:** Reference a ConfigMap in `spec.configMapName` containing your LDAP server URL, principal credentials, search DN, and user role mappings. ### When to Use LDAPS When you require encrypted communications using LDAPS, complete the base LDAP setup and conf…

Key points

  • Whether you validate against a local OpenLDAP test instance or connect directly to corpor…: Whether you validate against a local OpenLDAP test instance or connect directly to corporate Active Directory, this guide walks through operator configuration and TLS certificate setup directly in the Infinispan custom resource.
  • **Configure LDAP Realm Settings:** Reference a ConfigMap in `spec.configMapName` conta…: **Configure LDAP Realm Settings:** Reference a ConfigMap in `spec.configMapName` containing your LDAP server URL, principal credentials, search DN, and user role mappings.
  • ### When to Use LDAPS When you require encrypted communications using LDAPS, complete th…: ### When to Use LDAPS When you require encrypted communications using LDAPS, complete the base LDAP setup and configure Transport Layer Security (TLS): 1.

Sources checked by our analysis pipeline: 1

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:

- Install the Data Grid operator: Deploy the operator to manage your cluster in Red Hat OpenShift.

- Create the

Infinispan

custom resource: Define your cluster deployment specifications. - 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):

- Obtain the LDAP server TLS certificate: Export the certificate from your directory server or issuing certificate authority.

- Import the certificate into Data Grid pods: Reference a secret containing the TLS certificate using

spec.security.endpointEncryption.clientCertSecretName

on theInfinispan

custom resource. - Define the client verification strategy: Set

clientCert

toValidate

orAuthenticate

if you want to enforce client certificate authentication. Otherwise, set the value toNone

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.

Security caveat

While this example uses hardcoded plaintext credentials for local testing and proofs of concept (POCs), production deployments should rely on encrypted credential keystores or Red Hat OpenShift secrets to help protect LDAP bind passwords.

$ 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.

- Obtain the LDAP server TLS certificate: Export the root CA or server certificate from your directory server.

- Create an OpenShift secret: Store the certificate in a secret within the Data Grid namespace (for example, named

ldap-tls-secret

). - Reference the secret in the

Infinispan

CR: Configurespec.security.endpointEncryption

withclientCertSecretName

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

orAuthenticate

: Enforces mutual TLS (mTLS), validating incoming client certificates against the certificates provided inclientCertSecretName

.

- Update the connection URL: In your

security-config

ConfigMap, change the LDAP protocol and port to secure LDAPS (for example,ldaps://...:1636

orldaps://...: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:

Criteria | Red Hat build of Keycloak (part 1) | Direct LDAP / LDAPS (part 2) |

---|---|---|

Architecture | Centralized Identity Provider using OpenID Connect and OAuth2 | Direct directory integration |

Protocol | OAuth2 token introspection (RFC 7662) | Direct LDAP and LDAPS queries over TLS |

Credential handling | Handled entirely by Keycloak; credentials never touch Data Grid directly | Validated directly against directory servers using Data Grid security realms |

Primary use case | Centralized SSO and token lifecycle management across multiple distributed microservices | Direct binding to existing Active Directory or OpenLDAP infrastructure without deploying dedicated SSO services |

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.

Original source: developers.redhat.com

Technology

More in Technology