GLAuth is a lightweight LDAP server for development, home use, or CI.

This Helm chart allows you to deploy GLAuth in a Kubernetes cluster with your backend of choice, either as internal cluster infrastructure (e.g., mated to Keycloak in an OIDC environment) or exposed outside your cluster as a high availability authentication server.

helm repo add glauth https://nnstd.github.io/helm-glauth
helm install my-glauth glauth/glauth

This chart bootstraps a GLAuth deployment on a Kubernetes cluster using the Helm package manager.

• Kubernetes 1.19+
• Helm 3.2.0+
• PV provisioner support in the underlying infrastructure (if persistence is enabled)

• Added support of PostgresOperator for database creation and secret management.
• Refactored the chart to cover all the configuration options.

To install the chart with the release name my-glauth:

helm install my-glauth glauth/glauth

The command deploys GLAuth on the Kubernetes cluster in the default configuration. The Parameters section lists the parameters that can be configured during installation.

Tip: List all releases using helm list

To uninstall/delete the my-glauth deployment:

helm delete my-glauth

The command removes all the Kubernetes components associated with the chart and deletes the release.

The current configuration philosophy is to remain fully compatible with the config files already supported by GLAuth. In the future, GLAuth may be adapted to read Kubernetes secrets, etc. However, this would grow the project's code base quite significantly.

GLAuth supports two main backend types:

1. Config Backend: Uses a simple configuration file with embedded users and groups
2. Database Backend: Uses SQLite or PostgreSQL for storing user and group data

When using the config backend, users and groups are defined directly in the values.yaml file:

config:
  backend:
    type: config
  users:
    - name: "johndoe"
      givenname: "John"
      sn: "Doe"
      mail: "[email protected]"
      uidnumber: 5001
      primarygroup: 5501
      passsha256: "6478579e37aff45f013e14eeb30b3cc56c72ccdc310123bcdf53e0333e3f416a"
      capabilities:
        - action: "search"
          object: "*"
  groups:
    - name: "users"
      gidnumber: 5501

User Configuration Options:

• name: Username (required)
• givenname: First name
• sn: Surname/last name
• mail: Email address
• uidnumber: Unique user ID number (required)
• primarygroup: Primary group ID (required)
• loginShell: User's login shell
• homeDir: User's home directory
• passsha256: SHA256 hashed password
• passappsha256: Array of SHA256 hashed application passwords
• passappbcrypt: Array of bcrypt hashed application passwords
• sshkeys: Array of SSH public keys
• otpsecret: OTP secret for 2FA
• yubikey: YubiKey identifier
• capabilities: Array of user capabilities (action and object)

Group Configuration Options:

• name: Group name (required)
• gidnumber: Unique group ID number (required)
• includegroups: Array of group IDs to include in this group

When using SQLite as the backend:

config:
  backend:
    type: database
  database:
    engine: sqlite
    sqlite:
      shell: true  # Enable shell pod for database management

Setting shell: true creates a companion pod that allows you to manage the SQLite database:

kubectl exec -it glauth-sqlite-client -- sqlite3 /root/db/gl.db

For PostgreSQL backend with external database:

config:
  backend:
    type: database
  database:
    engine: postgres
    postgres:
      connectionString: "host=my-postgres-host port=5432 dbname=glauth user=glauth password=secretpassword sslmode=require"
      createResources: false

For PostgreSQL backend with PostgreSQL Operator:

config:
  backend:
    type: database
  database:
    engine: postgres
    postgres:
      createResources: true
      secretName: "postgres-user"

GLAuth exposes three main ports:

• 3893: LDAP (unencrypted)
• 3894: LDAPS (encrypted)
• 5555: Web interface/API

The default service configuration uses NodePort:

service:
  type: NodePort
  ports:
    - name: ldap
      internal: 3893
      external: 3893
      node: 30389
    - name: ldaps
      internal: 3894
      external: 3894
      node: 30636
    - name: web
      internal: 5555
      external: 5555
      node: 30555

To enable LDAPS, you need to provide certificates:

config:
  ldaps:
    enabled: true
    cert: "/path/to/glauth.crt"
    key: "/path/to/glauth.key"

Generate a certificate with:

openssl req -x509 -newkey rsa:4096 -keyout glauth.key -out glauth.crt -days 365 -nodes -subj '/CN=`hostname`'

GLAuth uses persistent volumes to store:

• Configuration files
• SQLite databases (when using SQLite backend)
• SSL certificates for LDAPS

Configure persistence using the config.storage section:

config:
  storage:
    size: 20G
    className: "fast-ssd"
    accessMode: "ReadWriteOnce"

GLAuth includes built-in security features:

1. Failed Login Protection: Implements a "fail2ban" style mechanism
2. Rate Limiting: Configurable thresholds and ban durations
3. IP Address Management: Automatic cleanup of learned IP addresses

Configure these via the config.behaviors section.

For production deployments, consider:

• Using LDAPS (port 3894) instead of plain LDAP
• Configuring proper network policies
• Using secrets for database credentials
• Disabling the SQLite shell pod when not needed
• Enabling TLS for the API endpoint

1. Pod not starting: Check resource limits and node capacity
2. Database connection issues: Verify connection string and network policies
3. LDAP authentication failures: Check user configuration and base DN settings
4. Persistence issues: Verify storage class and PVC creation

# Check pod status
kubectl get pods -l app=glauth

# View logs
kubectl logs -l app=glauth

# Check service endpoints
kubectl get svc glauth

# Test LDAP connectivity (if using NodePort)
ldapsearch -x -H ldap://node-ip:30389 -b "dc=glauth,dc=com"

# Access SQLite shell (if enabled)
kubectl exec -it glauth-sqlite-client -- sqlite3 /root/db/gl.db

When upgrading, review the changelog and:

1. Check for breaking changes in configuration
2. Update your values.yaml if using custom configurations
3. Consider backup of your data before upgrading
4. Test in a non-production environment first

config:
  backend:
    type: config
  users:
    - name: "admin"
      givenname: "Administrator"
      sn: "User"
      mail: "[email protected]"
      uidnumber: 5001
      primarygroup: 5501
      passsha256: "6478579e37aff45f013e14eeb30b3cc56c72ccdc310123bcdf53e0333e3f416a"
      capabilities:
        - action: "search"
          object: "*"
    - name: "user1"
      givenname: "Regular"
      sn: "User"
      mail: "[email protected]"
      uidnumber: 5002
      primarygroup: 5502
      passsha256: "6478579e37aff45f013e14eeb30b3cc56c72ccdc310123bcdf53e0333e3f416a"
  groups:
    - name: "admins"
      gidnumber: 5501
    - name: "users"
      gidnumber: 5502

config:
  backend:
    type: database
  database:
    engine: sqlite
    sqlite:
      shell: true
  storage:
    size: 10Gi

config:
  backend:
    type: database
  database:
    engine: postgres
    postgres:
      connectionString: "host=postgres.example.com port=5432 dbname=glauth user=glauth password=secret sslmode=require"
      createResources: false

config:
  ldaps:
    enabled: true
    cert: "/app/config/tls.crt"
    key: "/app/config/tls.key"
  storage:
    size: 5Gi

Contributions are welcome! Please feel free to submit a Pull Request.

This Helm chart is licensed under the Apache 2.0 license.

For support and questions:

• GitHub Repository
• Helm Chart Repository