User info fetcher

This feature is experimental, and subject to change.

The User info fetcher allows for additional information to be obtained from the configured backend (for example, Keycloak). You can then write Rego rules for OpenPolicyAgent which make an HTTP request to the User info fetcher and make use of the additional information returned for the username or user id.

You can enable the User info fetcher sidecar as follows:

apiVersion: opa.stackable.tech/v1alpha1
kind: OpaCluster
metadata:
  name: opa
spec:
  image:
    productVersion: 0.67.1
  clusterConfig:
    userInfo: (1)
      backend:
        keycloak:
          hostname: keycloak.my-namespace.svc.cluster.local
          port: 8443
          tls:
            verification:
              server:
                caCert:
                  secretClass: tls (2)
          clientCredentialsSecret: user-info-fetcher-client-credentials (3)
          adminRealm: master (4)
          userRealm: master (4)
      cache: # optional, enabled by default
        entryTimeToLive: 60s # optional, defaults to 60s
  servers:
    roleGroups:
      default: {}
---
apiVersion: v1
kind: Secret
metadata:
  name: user-info-fetcher-client-credentials
stringData:
  clientId: user-info-fetcher (3)
  clientSecret: user-info-fetcher-client-secret (3)
1 Enable the user-info-fetcher sidecar
2 Enable TLS verification using the CA from the tls SecretClass.
3 Obtain Keycloak API credentials from the specified secret. The Secret must have clientId and clientSecret entries.
4 Refer to the applicable realm in your Keycloak server.

Currently the following backends are supported:

Backends

The user info fetcher can fetch data from a few different backends. We currently recommend the Keycloak backend.

Keycloak

Fetch groups and extra credentials, but not roles.

The OAuth2 Client in Keycloak must be given the view-users Service Account Role for the realm that the users are in.

Active Directory

The Active Directory backend is experimental, and subject to change.

Fetches user attributes and groups over LDAP.

For this to work user-info-fetcher needs to be provided with a Kerberos keytab that enables it to access Active Directory. This is provided by a configurable SecretClass.

spec:
  clusterConfig:
    userInfo:
      backend:
        experimentalActiveDirectory: (1)
          ldapServer: sble-addc.sble.test (2)
          baseDistinguishedName: DC=sble,DC=test (3)
          customAttributeMappings: (4)
            country: c (5)
          kerberosSecretClassName: kerberos-ad (6)
          tls:
            verification:
              server:
                caCert:
                  secretClass: tls-ad (7)
      cache: # optional, enabled by default
        entryTimeToLive: 60s # optional, defaults to 60s
1 Enables the Active Directory backend
2 The hostname of the domain controller
3 The distinguished name to search, users and groups outside of this will not be seen
4 Arbitrary LDAP attributes can be requested to be fetched
5 c stores the ISO-3166 country code of the user
6 The name of the SecretClass that knows how to create Kerberos keytabs trusted by Active Directory
7 The name of the SecretClass that contains the Active Directory’s root CA certificate(s)

User info fetcher API

User information can be retrieved from regorules using the functions userInfoByUsername(username) and userInfoById(id) in data.stackable.opa.userinfo.v1.

An example of the returned structure:

{
  "id": "af07f12c-a2db-40a7-93e0-874537bdf3f5",
  "username": "alice",
  "groups": [
    "/admin"
  ],
  "customAttributes": {}
}
The exact formats of id and groups will vary depending on the backend in use. This example is using the Keycloak backend.

For example, the following rule allows access for users in the /admin group:

package test

import rego.v1

default allow := false

allow if {
    user := data.stackable.opa.userinfo.v1.userInfoById(input.userId)
    "/admin" in user.groups
}