Skip to main content

Manage users with a directory service

Manage SUNK user accounts with an external directory service

If you're using SUNK, you may want to manage user accounts using an external directory service. This guide will show you how to connect SUNK to a directory service for seamless user management.

Prerequisite: Set up a Kubernetes Secret​

Note

Google Secure LDAP users should skip this step and follow the instructions in that section to create the Secret using a TLS certificate instead.

Create a Kubernetes Secret​

Warning

CoreWeave strongly discourages including sensitive information, such as plaintext user credentials, directly in your values.yaml configuration. Instead, use a Kubernetes Secret for added security and manageability. CoreWeave provides encryption at rest for etcd data, which includes Secrets.

First, create a Kubernetes Secret that contains the configuration for your directory service.

The Secret must meet the following criteria:

  • The key name in the Secret must end with .conf.
  • The Secret's data should include a full and correct SSSD configuration snippet. This snippet must include the domain and ldap_default_authtok parameter. This is not a user password.

Here's an example of a Secret that meets these criteria:

Example
apiVersion: v1

kind: Secret

metadata:

  name: bind-user-sssd-config

type: Opaque

stringData:

  ldap-password.conf: |-

    [domain/default]

    ldap_default_authtok = YourCredentialsHere

Replace YourCredentialsHere with the actual credentials for your directory service.

Important

The ldap_default_authtok parameter contains the bind password that SSSD uses to connect to the LDAP server and perform lookups. This parameter should not contain individual user credentials.

In the example above, the name of the Secret is bind-user-sssd-config.

We also added a secret key with the ldap-password.conf parameter and inserted the SSSD configuration snippet within.

Reference the Secret in values.yaml​

Next, you'll need to update Slurm's values.yaml file to reference the Secret you just created.

Add the name of your Secret to the existingSecret field.

Add the secret key to the existingSecretFileName field.

Ensure that the values in these fields match your created Secret exactly.

The following example uses the Secret name and secret key that we created in the previous step:

Example
directoryService:

  directories:

  - name: default

    user:

      existingSecret: bind-user-sssd-config

      existingSecretFileName: ldap-password.conf

Create a Secret for Google Secure LDAP​

If you want to use Google Secure LDAP, follow Google's instructions to add a new LDAP client. You'll need to generate certificates and download them as part of the setup.

Then, run the following command to create a Kubernetes Secret of type tls using the certificate files you downloaded:

Example
kubectl create secret tls google-ldaps-cert \

--cert=<your-certificate>.crt \

--key=<your-private>.key

Replace <your-certificate>.crt and <your-private>.key with your downloaded certificate and key.

Modify values.yaml to include the Google Secure LDAP configuration in the directoryService section:

Example
directoryService:

  sudoGroups:

    - group1

  directories:

  - name: google-example

    enabled: true

    debugLevel: 0x0200

    ldapUri: ldaps://ldap.google.com:636

    user:

    defaultShell: "/bin/bash"

    fallbackHomeDir: "/home/%u"

    overrideHomeDir: /mnt/nvme/home/%u

    ldapsCert: google-ldaps-cert

    # For Google Secure LDAP, set schema: rfc2307bis

    schema: rfc2307bis

Enable SSH with Google Secure LDAP (Optional)​

To let users sign in using an SSH key, you'll need to add a multi-value attribute to your Google directory. Follow the Google guide to create a custom attribute named sshPublicKey.

For each user, enter their SSH public key into the sshPublicKey attribute field.

Note

Google's custom attribute values have a 500-character limit, so using a shorter key type like ssh-ed25519 is recommended.

By completing these steps, you've successfully integrated SUNK with Google Secure LDAP and users can authenticate via SSH keys tied to their Google accounts.

Example: Active Directory​

Example
directories:

  - name: active-directory-example

    enabled: true

    ldapUri: ldap://domaincontroller.tenant-my-tenant.coreweave.cloud

    user:

      bindDn: CN=binduser,CN=Users,DC=contoso,DC=com

      searchBase: DC=contoso,DC=com

      existingSecret: bind-user-sssd-config

      canary: binduser

    defaultShell: "/bin/bash"

    fallbackHomeDir: "/home/%u"

    schema: AD

Example: OpenLDAP​

Example
directories:

  - name: openldap-example

    enabled: true

    ldapUri: ldap://openldap

    user:

      bindDn: cn=admin,dc=coreweave,dc=cloud

      searchBase: dc=coreweave,dc=cloud

      existingSecret: bind-user-sssd-config

      canary: admin

    defaultShell: "/bin/bash"

    fallbackHomeDir: "/home/%u"

    schema: rfc2307

Example: Authentik​

Example
 directories:

  - name: authentik-example

    enabled: true

    ldapUri: ldap://authentik-outpost-ldap-outpost

    user:

      bindDn: cn=ldapsvc,dc=coreweave,dc=cloud

      searchBase: dc=coreweave,dc=cloud

      existingSecret: bind-user-sssd-config

      canary: ldapsvc

    startTLS: true

    userObjectClass: user

    groupObjectClass: group

    userNameAttr: cn

    groupNameAttr: cn

    schema: rfc2307bis

General Directory Service configuration​

For general configuration, see these keys in the directoryService section of values.yaml.

Directory Service-specific configuration​

Each named directory service has its own configuration section. See these keys in the directoryService.directories[*] section of values.yaml.

Last updated on