url: ldap://10.0.0.0:389 (1)
bindDN: cn=admin,dc=example,dc=com (2)
bindPassword: password (3)
insecure: false (4)
ca: my-ldap-ca-bundle.crt (5)
As an administrator, you can use groups to manage users, change their permissions, and enhance collaboration. Your organization may have already created user groups and stored them in an LDAP server. OpenShift Container Platform can sync those LDAP records with internal OpenShift Container Platform records, enabling you to manage your groups in one place. OpenShift Container Platform currently supports group sync with LDAP servers using three common schemas for defining group membership: RFC 2307, Active Directory, and augmented Active Directory.
For more information on configuring LDAP, see Configuring an LDAP identity provider.
You must have |
Before you can run LDAP sync, you need a sync configuration file. This file contains the following LDAP client configuration details:
Configuration for connecting to your LDAP server.
Sync configuration options that are dependent on the schema used in your LDAP server.
An administrator-defined list of name mappings that maps OpenShift Container Platform group names to groups in your LDAP server.
The format of the configuration file depends upon the schema you are using: RFC 2307, Active Directory, or augmented Active Directory.
The LDAP client configuration section of the configuration defines the connections to your LDAP server.
The LDAP client configuration section of the configuration defines the connections to your LDAP server.
url: ldap://10.0.0.0:389 (1)
bindDN: cn=admin,dc=example,dc=com (2)
bindPassword: password (3)
insecure: false (4)
ca: my-ldap-ca-bundle.crt (5)
1 | The connection protocol, IP address of the LDAP server hosting your
database, and the port to connect to, formatted as scheme://host:port . |
2 | Optional distinguished name (DN) to use as the Bind DN. OpenShift Container Platform uses this if elevated privilege is required to retrieve entries for the sync operation. |
3 | Optional password to use to bind. OpenShift Container Platform uses this if elevated privilege is necessary to retrieve entries for the sync operation. This value may also be provided in an environment variable, external file, or encrypted file. |
4 | When false , secure
LDAP (ldaps:// ) URLs connect using TLS, and insecure LDAP (ldap:// ) URLs are
upgraded to TLS. When true , no TLS connection is made to the server and you cannot use ldaps:// URL schemes. |
5 | The certificate bundle to use for validating server certificates for the
configured URL. If empty, OpenShift Container Platform uses system-trusted roots. This only applies
if insecure is set to false . |
Sync configurations consist of LDAP query definitions for the entries that are required for synchronization. The specific definition of an LDAP query depends on the schema used to store membership information in the LDAP server.
baseDN: ou=users,dc=example,dc=com (1)
scope: sub (2)
derefAliases: never (3)
timeout: 0 (4)
filter: (objectClass=person) (5)
pageSize: 0 (6)
1 | The distinguished name (DN) of the branch of the directory where all searches will start from. It is required that you specify the top of your directory tree, but you can also specify a subtree in the directory. |
2 | The scope of the search. Valid values are base , one , or sub . If this
is left undefined, then a scope of sub is assumed. Descriptions of the scope
options can be found in the table below. |
3 | The behavior of the search with respect to aliases in the LDAP tree. Valid
values are never , search , base , or always . If this is left undefined,
then the default is to always dereference aliases. Descriptions of the
dereferencing behaviors can be found in the table below. |
4 | The time limit allowed for the search by the client, in seconds. A value of
0 imposes no client-side limit. |
5 | A valid LDAP search filter. If this is left undefined, then the default is
(objectClass=*) . |
6 | The optional maximum size of response pages from the server, measured in LDAP
entries. If set to 0 , no size restrictions will be made on pages of responses.
Setting paging sizes is necessary when queries return more entries than the
client or server allow by default. |
LDAP search scope | Description |
---|---|
|
Only consider the object specified by the base DN given for the query. |
|
Consider all of the objects on the same level in the tree as the base DN for the query. |
|
Consider the entire subtree rooted at the base DN given for the query. |
Dereferencing behavior | Description |
---|---|
|
Never dereference any aliases found in the LDAP tree. |
|
Only dereference aliases found while searching. |
|
Only dereference aliases while finding the base object. |
|
Always dereference all aliases found in the LDAP tree. |
A user-defined name mapping explicitly maps the names of OpenShift Container Platform groups to unique identifiers that find groups on your LDAP server. The mapping uses normal YAML syntax. A user-defined mapping can contain an entry for every group in your LDAP server or only a subset of those groups. If there are groups on the LDAP server that do not have a user-defined name mapping, the default behavior during sync is to use the attribute specified as the OpenShift Container Platform group’s name.
groupUIDNameMapping:
"cn=group1,ou=groups,dc=example,dc=com": firstgroup
"cn=group2,ou=groups,dc=example,dc=com": secondgroup
"cn=group3,ou=groups,dc=example,dc=com": thirdgroup
The RFC 2307 schema requires you to provide an LDAP query definition for both user and group entries, as well as the attributes with which to represent them in the internal OpenShift Container Platform records.
For clarity, the group you create in OpenShift Container Platform should use attributes other than the distinguished name whenever possible for user- or administrator-facing fields. For example, identify the users of an OpenShift Container Platform group by their e-mail, and use the name of the group as the common name. The following configuration file creates these relationships:
If using user-defined name mappings, your configuration file will differ. |
rfc2307_config.yaml
kind: LDAPSyncConfig
apiVersion: v1
url: ldap://LDAP_SERVICE_IP:389 (1)
insecure: false (2)
rfc2307:
groupsQuery:
baseDN: "ou=groups,dc=example,dc=com"
scope: sub
derefAliases: never
pageSize: 0
groupUIDAttribute: dn (3)
groupNameAttributes: [ cn ] (4)
groupMembershipAttributes: [ member ] (5)
usersQuery:
baseDN: "ou=users,dc=example,dc=com"
scope: sub
derefAliases: never
pageSize: 0
userUIDAttribute: dn (6)
userNameAttributes: [ mail ] (7)
tolerateMemberNotFoundErrors: false
tolerateMemberOutOfScopeErrors: false
1 | The IP address and host of the LDAP server where this group’s record is stored. |
2 | When false , secure
LDAP (ldaps:// ) URLs connect using TLS, and insecure LDAP (ldap:// ) URLs are
upgraded to TLS. When true , no TLS connection is made to the server and you cannot use ldaps:// URL schemes. |
3 | The attribute that uniquely identifies a group on the LDAP server.
You cannot specify groupsQuery filters when using DN for groupUIDAttribute .
For fine-grained filtering, use the whitelist / blacklist method. |
4 | The attribute to use as the name of the group. |
5 | The attribute on the group that stores the membership information. |
6 | The attribute that uniquely identifies a user on the LDAP server. You
cannot specify usersQuery filters when using DN for userUIDAttribute. For
fine-grained filtering, use the whitelist / blacklist method. |
7 | The attribute to use as the name of the user in the OpenShift Container Platform group record. |
The Active Directory schema requires you to provide an LDAP query definition for user entries, as well as the attributes to represent them with in the internal OpenShift Container Platform group records.
For clarity, the group you create in OpenShift Container Platform should use attributes other than the distinguished name whenever possible for user- or administrator-facing fields. For example, identify the users of an OpenShift Container Platform group by their e-mail, but define the name of the group by the name of the group on the LDAP server. The following configuration file creates these relationships:
active_directory_config.yaml
kind: LDAPSyncConfig
apiVersion: v1
url: ldap://LDAP_SERVICE_IP:389
activeDirectory:
usersQuery:
baseDN: "ou=users,dc=example,dc=com"
scope: sub
derefAliases: never
filter: (objectclass=person)
pageSize: 0
userNameAttributes: [ mail ] (1)
groupMembershipAttributes: [ memberOf ] (2)
1 | The attribute to use as the name of the user in the OpenShift Container Platform group record. |
2 | The attribute on the user that stores the membership information. |
The augmented Active Directory schema requires you to provide an LDAP query definition for both user entries and group entries, as well as the attributes with which to represent them in the internal OpenShift Container Platform group records.
For clarity, the group you create in OpenShift Container Platform should use attributes other than the distinguished name whenever possible for user- or administrator-facing fields. For example, identify the users of an OpenShift Container Platform group by their e-mail, and use the name of the group as the common name. The following configuration file creates these relationships.
augmented_active_directory_config.yaml
kind: LDAPSyncConfig
apiVersion: v1
url: ldap://LDAP_SERVICE_IP:389
augmentedActiveDirectory:
groupsQuery:
baseDN: "ou=groups,dc=example,dc=com"
scope: sub
derefAliases: never
pageSize: 0
groupUIDAttribute: dn (1)
groupNameAttributes: [ cn ] (2)
usersQuery:
baseDN: "ou=users,dc=example,dc=com"
scope: sub
derefAliases: never
filter: (objectclass=person)
pageSize: 0
userNameAttributes: [ mail ] (3)
groupMembershipAttributes: [ memberOf ] (4)
1 | The attribute that uniquely identifies a group on the LDAP server. You
cannot specify groupsQuery filters when using DN for groupUIDAttribute. For
fine-grained filtering, use the whitelist / blacklist method. |
2 | The attribute to use as the name of the group. |
3 | The attribute to use as the name of the user in the OpenShift Container Platform group record. |
4 | The attribute on the user that stores the membership information. |
Once you have created a sync configuration file, you can begin to sync. OpenShift Container Platform allows administrators to perform a number of different sync types with the same server.
You can sync all groups from the LDAP server with OpenShift Container Platform.
Create a sync configuration file.
To sync all groups from the LDAP server with OpenShift Container Platform:
$ oc adm groups sync --sync-config=config.yaml --confirm
By default, all group synchronization operations are dry-run, so you
must set the |
You can sync all groups already in OpenShift Container Platform that correspond to groups in the LDAP server specified in the configuration file.
Create a sync configuration file.
To sync OpenShift Container Platform groups with the LDAP server:
$ oc adm groups sync --type=openshift --sync-config=config.yaml --confirm
By default, all group synchronization operations are dry-run, so you
must set the |
You can sync a subset of LDAP groups with OpenShift Container Platform using whitelist files, blacklist files, or both.
You can use any combination of blacklist files, whitelist files, or whitelist literals. Whitelist and blacklist files must contain one unique group identifier per line, and you can include whitelist literals directly in the command itself. These guidelines apply to groups found on LDAP servers as well as groups already present in OpenShift Container Platform. |
Create a sync configuration file.
To sync a subset of LDAP groups with OpenShift Container Platform, use any the following commands:
$ oc adm groups sync --whitelist=<whitelist_file> \
--sync-config=config.yaml \
--confirm
$ oc adm groups sync --blacklist=<blacklist_file> \
--sync-config=config.yaml \
--confirm
$ oc adm groups sync <group_unique_identifier> \
--sync-config=config.yaml \
--confirm
$ oc adm groups sync <group_unique_identifier> \
--whitelist=<whitelist_file> \
--blacklist=<blacklist_file> \
--sync-config=config.yaml \
--confirm
$ oc adm groups sync --type=openshift \
--whitelist=<whitelist_file> \
--sync-config=config.yaml \
--confirm
By default, all group synchronization operations are dry-run, so you
must set the |
An administrator can also choose to remove groups from OpenShift Container Platform records if the records on the LDAP server that created them are no longer present. The prune job will accept the same sync configuration file and whitelists or blacklists as used for the sync job.
For example:
$ oc adm prune groups --sync-config=/path/to/ldap-sync-config.yaml --confirm
$ oc adm prune groups --whitelist=/path/to/whitelist.txt --sync-config=/path/to/ldap-sync-config.yaml --confirm
$ oc adm prune groups --blacklist=/path/to/blacklist.txt --sync-config=/path/to/ldap-sync-config.yaml --confirm
You can automatically sync LDAP groups on a periodic basis by configuring a cron job.
You have access to the cluster as a user with the cluster-admin
role.
You have configured an LDAP identity provider (IDP).
This procedure assumes that you created an LDAP secret named ldap-secret
and a config map named ca-config-map
.
Create a project where the cron job will run:
$ oc new-project ldap-sync (1)
1 | This procedure uses a project called ldap-sync . |
Locate the secret and config map that you created when configuring the LDAP identity provider and copy them to this new project.
The secret and config map exist in the openshift-config
project and must be copied to the new ldap-sync
project.
Define a service account:
ldap-sync-service-account.yaml
kind: ServiceAccount
apiVersion: v1
metadata:
name: ldap-group-syncer
namespace: ldap-sync
Create the service account:
$ oc create -f ldap-sync-service-account.yaml
Define a cluster role:
ldap-sync-cluster-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: ldap-group-syncer
rules:
- apiGroups:
- ''
- user.openshift.io
resources:
- groups
verbs:
- get
- list
- create
- update
Create the cluster role:
$ oc create -f ldap-sync-cluster-role.yaml
Define a cluster role binding to bind the cluster role to the service account:
ldap-sync-cluster-role-binding.yaml
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: ldap-group-syncer
subjects:
- kind: ServiceAccount
name: ldap-group-syncer (1)
namespace: ldap-sync
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: ldap-group-syncer (2)
1 | Reference to the service account created earlier in this procedure. |
2 | Reference to the cluster role created earlier in this procedure. |
Create the cluster role binding:
$ oc create -f ldap-sync-cluster-role-binding.yaml
Define a config map that specifies the sync configuration file:
ldap-sync-config-map.yaml
kind: ConfigMap
apiVersion: v1
metadata:
name: ldap-group-syncer
namespace: ldap-sync
data:
sync.yaml: | (1)
kind: LDAPSyncConfig
apiVersion: v1
url: ldaps://10.0.0.0:389 (2)
insecure: false
bindDN: cn=admin,dc=example,dc=com (3)
bindPassword:
file: "/etc/secrets/bindPassword"
ca: /etc/ldap-ca/ca.crt
rfc2307: (4)
groupsQuery:
baseDN: "ou=groups,dc=example,dc=com" (5)
scope: sub
filter: "(objectClass=groupOfMembers)"
derefAliases: never
pageSize: 0
groupUIDAttribute: dn
groupNameAttributes: [ cn ]
groupMembershipAttributes: [ member ]
usersQuery:
baseDN: "ou=users,dc=example,dc=com" (6)
scope: sub
derefAliases: never
pageSize: 0
userUIDAttribute: dn
userNameAttributes: [ uid ]
tolerateMemberNotFoundErrors: false
tolerateMemberOutOfScopeErrors: false
1 | Define the sync configuration file. |
2 | Specify the URL. |
3 | Specify the bindDN . |
4 | This example uses the RFC2307 schema; adjust values as necessary. You can also use a different schema. |
5 | Specify the baseDN for groupsQuery . |
6 | Specify the baseDN for usersQuery . |
Create the config map:
$ oc create -f ldap-sync-config-map.yaml
Define a cron job:
ldap-sync-cron-job.yaml
kind: CronJob
apiVersion: batch/v1
metadata:
name: ldap-group-syncer
namespace: ldap-sync
spec: (1)
schedule: "*/30 * * * *" (2)
concurrencyPolicy: Forbid
jobTemplate:
spec:
backoffLimit: 0
ttlSecondsAfterFinished: 1800 (3)
template:
spec:
containers:
- name: ldap-group-sync
image: "registry.redhat.io/openshift4/ose-cli:latest"
command:
- "/bin/bash"
- "-c"
- "oc adm groups sync --sync-config=/etc/config/sync.yaml --confirm" (4)
volumeMounts:
- mountPath: "/etc/config"
name: "ldap-sync-volume"
- mountPath: "/etc/secrets"
name: "ldap-bind-password"
- mountPath: "/etc/ldap-ca"
name: "ldap-ca"
volumes:
- name: "ldap-sync-volume"
configMap:
name: "ldap-group-syncer"
- name: "ldap-bind-password"
secret:
secretName: "ldap-secret" (5)
- name: "ldap-ca"
configMap:
name: "ca-config-map" (6)
restartPolicy: "Never"
terminationGracePeriodSeconds: 30
activeDeadlineSeconds: 500
dnsPolicy: "ClusterFirst"
serviceAccountName: "ldap-group-syncer"
1 | Configure the settings for the cron job. See "Creating cron jobs" for more information on cron job settings. |
2 | The schedule for the job specified in cron format. This example cron job runs every 30 minutes. Adjust the frequency as necessary, making sure to take into account how long the sync takes to run. |
3 | How long, in seconds, to keep finished jobs. This should match the period of the job schedule in order to clean old failed jobs and prevent unnecessary alerts. For more information, see TTL-after-finished Controller in the Kubernetes documentation. |
4 | The LDAP sync command for the cron job to run. Passes in the sync configuration file that was defined in the config map. |
5 | This secret was created when the LDAP IDP was configured. |
6 | This config map was created when the LDAP IDP was configured. |
Create the cron job:
$ oc create -f ldap-sync-cron-job.yaml
This section contains examples for the RFC 2307, Active Directory, and augmented Active Directory schemas.
These examples assume that all users are direct members of their respective groups. Specifically, no groups have other groups as members. See the Nested Membership Sync Example for information on how to sync nested groups. |
For the RFC 2307 schema, the following examples synchronize a group named admins
that has two
members: Jane
and Jim
. The examples explain:
How the group and users are added to the LDAP server.
What the resulting group record in OpenShift Container Platform will be after synchronization.
These examples assume that all users are direct members of their respective groups. Specifically, no groups have other groups as members. See the Nested Membership Sync Example for information on how to sync nested groups. |
In the RFC 2307 schema, both users (Jane and Jim) and groups exist on the LDAP
server as first-class entries, and group membership is stored in attributes on
the group. The following snippet of ldif
defines the users and group for this
schema:
rfc2307.ldif
dn: ou=users,dc=example,dc=com
objectClass: organizationalUnit
ou: users
dn: cn=Jane,ou=users,dc=example,dc=com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Jane
sn: Smith
displayName: Jane Smith
mail: jane.smith@example.com
dn: cn=Jim,ou=users,dc=example,dc=com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Jim
sn: Adams
displayName: Jim Adams
mail: jim.adams@example.com
dn: ou=groups,dc=example,dc=com
objectClass: organizationalUnit
ou: groups
dn: cn=admins,ou=groups,dc=example,dc=com (1)
objectClass: groupOfNames
cn: admins
owner: cn=admin,dc=example,dc=com
description: System Administrators
member: cn=Jane,ou=users,dc=example,dc=com (2)
member: cn=Jim,ou=users,dc=example,dc=com
1 | The group is a first-class entry in the LDAP server. |
2 | Members of a group are listed with an identifying reference as attributes on the group. |
Create the configuration file.