Integrating FreeIPA (LDAP) with OpenShift + Automated Gro...

Managing users and groups centrally is critical in enterprise Kubernetes environments. In this guide, I’ll walk you through how I integrated FreeIPA (LDAP) with OpenShift and set up an automated CronJob to sync groups periodically.

This setup ensures:

Centralized authentication via FreeIPA
Automatic onboarding of users
Continuous group synchronization inside OpenShift

The Architecture:

And now, the subtitles for the Architecture!

User Login
- Developer logs in via OpenShift Console or CLI (oc login)
Authentication via LDAP/FreeIPA
- OpenShift OAuth server uses the configured LDAP Identity Provider
- Performs bind + search using the ldapbind service account
Group Sync Process
- oc adm groups sync queries LDAP periodically
- Fetches:
  - Users
  - Groups
  - Membership mapping
- Updates OpenShift Group objects
Automation
- CronJob runs the sync automatically every minute (in our setup)

The Integration:

Create a bind user (ldapbind in our case) to query LDAP/FreeIPA. Of course, you need to run this on the LDAP server. I have redacted some part of the output.

#ipa user-add ldapbind --first=ldap --last=bind --password
Password: 
Enter Password again to verify: 
---------------------
Added user "ldapbind"
---------------------
  User login: ldapbind
  First name: ldap
  Last name: bind
  Full name: ldap bind

Using the password you set, create a "secret" in openshift.

#oc create secret generic ldap-bind-password --from-literal=bindPassword='redhat' -n openshift-config

secret/ldap-bind-password created

Configure Oauth to use the LDAP/FreeIPA server. Basically, telling OAuth who's our LDAP server, where to search, the user who's allowed to search along with reference to the secret we created above, Yadda, Yadda, Yadda!! Here's the manifest and the command:

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
    - name: freeipa
      mappingMethod: claim
      type: LDAP
      ldap:
        url: "ldap://192.168.122.246/dc=example,dc=com?uid"
        bindDN: "uid=ldapbind,cn=users,cn=accounts,dc=example,dc=com"
        bindPassword:
          name: ldap-bind-password
        insecure: true
        attributes:
          id: [dn]
          name: [cn]
          email: [mail]
          preferredUsername: [uid]


#oc apply -f ldap.yaml 
oauth.config.openshift.io/cluster configured

Note: If you're too impatient, you can delete the pods in the "openshift-authentication" namespace so the integration is immediately picked up when the pods start back.

I created a user named "ashish" and Voila! I was able to login.

#oc login -u ashish api.snomaster.lab:6443 
Console URL: https://api.snomaster.lab:6443/console
Authentication required for https://api.snomaster.lab:6443 (openshift)
Username: ashish
Password: 
Login successful.

You don't have any projects. You can try to create a new project, by running

oc new-project <projectname>

Here's the tricky part. Whatever groups you create in LDAP/FreeIPA are not automatically imported by Openshift. This is where the second part of this article kicks in - _Automatic Group Sync. _

Automatic Group Sync - Part 1 ( The Manual way)

In this part we will create a manifest and run it to test if the manual sync works, if that works it's just a matter of creating a cron resource (Isolation is key!).This method is like a test that our manifest and group-sync works. So, here's the manifest

kind: LDAPSyncConfig
apiVersion: v1

url: ldap://192.168.122.246

bindDN: "uid=ldapbind,cn=users,cn=accounts,dc=example,dc=com"

bindPassword:
  file: "/etc/secrets/bindPassword"

insecure: true

rfc2307:
  groupsQuery:
    baseDN: "cn=groups,cn=accounts,dc=example,dc=com"
    scope: sub
    derefAliases: never
    filter: "(objectClass=groupofnames)"

  groupUIDAttribute: dn
  groupNameAttributes: [ cn ]

  groupMembershipAttributes: [ member ]

  usersQuery:
    baseDN: "cn=users,cn=accounts,dc=example,dc=com"
    scope: sub
    derefAliases: never

  userUIDAttribute: dn

  userNameAttributes: [ uid ]

Create a file that holds the "bind" password . These are the reasons why this is a bad method and should only be used for testing our sync. (These plain text passwords can give security guys an heart-attack!!)

#printf '%s' 'redhat' > /home/user/ldap-manifs/bindPassword

Time to test our group-sync. You might as well create some groups on your LDAP/FreeIPA server.

#oc adm groups sync --sync-config=group-sync.yaml --confirm
group/admins
group/ipausers
group/editors
group/trust admins
group/developers
group/platform-admins

We can also cross verify if they're actually visible in openshift.

#oc get groups
NAME              USERS
admins            admin
developers        bob
editors           
ipausers          ldapbind, ashish, bob
platform-admins   ashish
trust admins      admin

Why I call this automatic is, you can still add the oc adm groups sync command to cron and this will work just fine. The only bad part is the handling of password. There are ways to work around it, like ansible-ize your sync method and use ansible-vault to store the password or use Hashi Vault to store the password and fetch it using API's. We aren't going to touch base on those methods today. I will stick to the openshift-way of doing it. That brings us to part 2.

Automatic Group Sync - Part 2 ( The Openshift way)

The manifest remains the same, it's just that we will add the following resources to comply with production-grade standards:
We will create a secret to store the bind password. (Which we already did!).
Create a configMap that will store our group-sync manifest.
Create a CronJob Resource, this is the most interesting part.
Create a group-sync configMap
This is same group-sync manifest we used before, just we add it as a configMap resource this time. Here's the manifest

apiVersion: v1
kind: ConfigMap
metadata:
  name: ldap-group-sync-config
data:
  group-sync.yaml: |
    kind: LDAPSyncConfig
    apiVersion: v1

    url: ldap://192.168.122.246

    bindDN: "uid=ldapbind,cn=users,cn=accounts,dc=example,dc=com"

    bindPassword:
      file: "/etc/secrets/bindPassword"

    insecure: true

    rfc2307:
     groupsQuery:
       baseDN: "cn=groups,cn=accounts,dc=example,dc=com"
       scope: sub
       derefAliases: never
       filter: "(objectClass=groupofnames)"

     groupUIDAttribute: dn
     groupNameAttributes: [ cn ]

     groupMembershipAttributes: [ member ]

     usersQuery:
      baseDN: "cn=users,cn=accounts,dc=example,dc=com"
      scope: sub
      derefAliases: never

     userUIDAttribute: dn

     userNameAttributes: [ uid ]

The most interesting part of this process. We create a CronJob resource, this resource creates a temporary pod. This pod will mount our configMap and Secret inside the pod, run our job and terminate the pod. You're free to change the schedule.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: ldap-group-sync
spec:
  schedule: "* * * * *"
  jobTemplate:
    spec:
     template:
      spec:
       serviceAccountName: ldap-group-sync
       restartPolicy: OnFailure
       containers:
         - name: ldap-group-sync
           image: registry.redhat.io/openshift4/ose-cli
           command:
             - /bin/bash
             - -c 
             - |
             - oc adm groups sync --sync-config=/config/group-sync.yaml --confirm 
           volumeMounts:
             - name: sync-config
               mountPath: /config
           volumeMounts:
             - name: bind-secret
               mountPath: /etc/secrets
       volumes:
        - name: sync-config
          configMap:
           name: ldap-group-sync-config

        - name: bind-secret
          secret:
           secretName: ldap-bind-password

You can monitor the status under oc logs job/. You will see something to the tune of :

{"apiVersion":"v1","bindDN":"uid=ldapbind,cn=users,cn=accounts,dc=example,dc=com","bindPassword":{"file":"/etc/secrets/bindPassword"},"insecure":true,"kind":"LDAPSyncConfig","rfc2307":{"groupMembershipAttributes":["member"],"groupNameAttributes":["cn"],"groupUIDAttribute":"dn","groupsQuery":{"baseDN":"cn=groups,cn=accounts,dc=example,dc=com","derefAliases":"never","filter":"(objectClass=groupofnames)","scope":"sub"},"userNameAttributes":["uid"],"userUIDAttribute":"dn","usersQuery":{"baseDN":"cn=users,cn=accounts,dc=example,dc=com","derefAliases":"never","scope":"sub"}},"url":"ldap://192.168.122.246"}
group/admins
group/ipausers
group/editors
group/trust admins
group/developers
group/platform-admins
group/testers
group/hr

And just like that we have a fully automated Identity and Access management up and running.

推荐订阅源

DEV Community