Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt

Use this file to discover all available pages before exploring further.

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

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

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: 
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.
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: 
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: 
kubectl create secret tls google-ldaps-cert \
--cert=[YOUR-CERTIFICATE].crt \
--key=[YOUR-PRIVATE-KEY].key
Replace [YOUR-CERTIFICATE].crt and [YOUR-PRIVATE-KEY].key with your downloaded certificate and key. Modify values.yaml to include the Google Secure LDAP configuration in the directoryService section: 
directoryService:
  sudoGroups:
    - group1
  directories:
  - name: google-example
    enabled: true
    debugLevel: 0x0200
    ldapUri: ldaps://ldap.google.com:636
    user:
      canary: user@example.com
    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.
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

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

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

 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 modified on April 20, 2026