SSO in OpenShift: uitleg, inrichting en realisatie

Single Sign-On (SSO) betekent dat gebruikers zich één keer authenticeren bij een centrale identity provider, en daarna zonder opnieuw in te loggen toegang krijgen tot meerdere systemen — de OpenShift-console, oc login, en eventueel de eigen applicaties die op het cluster draaien. Dit artikel legt uit hoe OpenShift dit inricht, en hoe je het realiseert.

De basis: OpenShift heeft al een ingebouwde OAuth-server

In tegenstelling tot vanilla Kubernetes (waar je zelf authenticatie moet optuigen) heeft OpenShift een ingebouwde OAuth-server. Deze regelt zelf geen wachtwoorden — hij delegeert authenticatie naar een of meer geconfigureerde identity providers, en geeft na een geslaagde login een OpenShift-token terug waarmee de gebruiker verder kan.

Welke identity providers ondersteunt OpenShift?

Praktisch: LDAP integreren

Dit is de meest gebruikte keuze in enterprise-omgevingen. De configuratie gebeurt via de clusterbrede OAuth custom resource:

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
    - name: bedrijfs-ldap
      mappingMethod: claim
      type: LDAP
      ldap:
        attributes:
          id: ["dn"]
          email: ["mail"]
          name: ["cn"]
          preferredUsername: ["uid"]
        bindDN: "cn=admin,dc=voorbeeld,dc=nl"
        bindPassword:
          name: ldap-bind-wachtwoord
        ca:
          name: ldap-ca-bundel
        insecure: false
        url: "ldaps://ldap.voorbeeld.nl/ou=gebruikers,dc=voorbeeld,dc=nl?uid"

oc create secret generic ldap-bind-wachtwoord \n  --from-literal=bindPassword='HetWachtwoord' \n  -n openshift-config

Praktijktip: Gebruik altijd ldaps:// (versleuteld) in productie, nooit kaal ldap:// — en zorg dat het CA-certificaat van je LDAP-server als ConfigMap beschikbaar is (via ca: name: ldap-ca-bundel), anders weigert OpenShift de verbinding met een certificaatfout.

Praktisch: OIDC integreren (Keycloak, Azure AD, Okta)

Voor moderne identity providers via het OpenID Connect-protocol:

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
    - name: bedrijfs-oidc
      mappingMethod: claim
      type: OpenID
      openID:
        clientID: "openshift-console"
        clientSecret:
          name: oidc-client-secret
        issuer: "https://sso.voorbeeld.nl/realms/productie"
        claims:
          preferredUsername: ["preferred_username"]
          name: ["name"]
          email: ["email"]

oc create secret generic oidc-client-secret \n  --from-literal=clientSecret='HetClientSecret' \n  -n openshift-config

De issuer-URL moet exact overeenkomen met wat de identity provider zelf publiceert onder /.well-known/openid-configuration — een veelgemaakte fout is een afwijkend pad of een ontbrekende trailing slash.

Groepen synchroniseren voor RBAC

Alleen inloggen is niet genoeg — voor zinvolle autorisatie wil je LDAP/OIDC-groepen automatisch vertalen naar OpenShift-groepen, zodat RBAC-rollen aan hele teams gekoppeld kunnen worden in plaats van individuele gebruikers.

kind: LDAPSyncConfig
apiVersion: v1
url: ldaps://ldap.voorbeeld.nl
bindDN: "cn=admin,dc=voorbeeld,dc=nl"
bindPassword: "HetWachtwoord"
insecure: false
ca: /pad/naar/ca.crt
groupUIDNameMapping:
  "cn=platformteam,ou=groepen,dc=voorbeeld,dc=nl": platformteam
rfc2307:
  groupsQuery:
    baseDN: "ou=groepen,dc=voorbeeld,dc=nl"
    scope: sub
    filter: "(objectClass=groupOfNames)"
  groupUIDAttribute: dn
  groupNameAttributes: [ cn ]
  groupMembershipAttributes: [ member ]
  usersQuery:
    baseDN: "ou=gebruikers,dc=voorbeeld,dc=nl"
    scope: sub
  userUIDAttribute: dn
  userNameAttributes: [ uid ]

oc adm groups sync --sync-config=groep-sync.yaml --confirm

Praktijktip: Draai group sync eerst zónder --confirm — dat toont een dry-run van wat er zou gebeuren, zodat je een mapping-fout ontdekt vóórdat groepslidmaatschap daadwerkelijk wordt aangepast.

RBAC koppelen aan de gesynchroniseerde groepen

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: platformteam-admin
  namespace: productie-app
subjects:
  - kind: Group
    name: platformteam
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: admin
  apiGroup: rbac.authorization.k8s.io

SSO uitbreiden naar je eigen applicaties: het oauth-proxy-patroon

Tot nu toe ging het over inloggen bij OpenShift zelf (console, oc-CLI). Wil je dat een eigen applicatie die op het cluster draait ook meelift op dezelfde SSO, zonder zelf authenticatielogica te bouwen? Zet een oauth-proxy-sidecar vóór de applicatie:

spec:
  containers:
    - name: oauth-proxy
      image: quay.io/openshift/origin-oauth-proxy:latest
      args:
        - --https-address=:8443
        - --provider=openshift
        - --upstream=http://localhost:8080
        - --cookie-secret=SECRET
        - --openshift-service-account=mijn-app
      ports:
        - containerPort: 8443
    - name: mijn-app
      image: voorbeeld/mijn-app:latest
      ports:
        - containerPort: 8080

De applicatiecontainer zelf hoeft niets van authenticatie te weten — hij ontvangt alleen al gevalideerd verkeer via localhost:8080. Dit is hetzelfde principe als de Secretless Broker bij secrets management: verantwoordelijkheid weghouden bij de applicatiecode zelf.

Testen en verifiëren

oc login https://api.cluster.voorbeeld.nl:6443

Kies bij een geslaagde configuratie nu de nieuwe identity provider in het inlogscherm. Controleer daarna of groepslidmaatschap correct is doorgekomen:

oc get groupsnoc describe group platformteam

Veelgemaakte valkuilen

• Ontbrekend of verkeerd CA-certificaat — de meest voorkomende oorzaak van een mislukte LDAP/OIDC-verbinding, vooral bij zelfondertekende certificaten.
• mappingMethod verkeerd gekozen — claim is meestal correct (gebruikt de identiteit uit de provider als naam); add kan ongewenst meerdere identity providers aan hetzelfde account koppelen als namen toevallig overeenkomen.
• Group sync niet herhaald — group sync is geen doorlopend proces, maar een commando dat je periodiek (bijvoorbeeld via een CronJob) opnieuw moet uitvoeren om wijzigingen in de directory door te laten komen.
• Testen met een account dat toevallig al cluster-admin is — verifieer SSO altijd ook met een account dat bewust beperkte rechten hoort te hebben, om autorisatiefouten niet te missen.

Verder lezen

• OpenShift-architectuur → — voor de bredere context van OAuth-server, Routes en SCC.
• CyberArk Conjur → — voor machine-identiteit (in plaats van menselijke SSO) binnen dezelfde OpenShift-omgeving.