Dex : fédérateur d'identité pour Sigstore privé

Quand vous utilisez Sigstore en mode keyless (signature sans clé privée), vous devez prouver votre identité. En production publique, GitHub ou Google font ce travail. Mais dans un environnement air-gapped (déconnecté d’Internet), comment authentifier vos développeurs ?

C’est là qu’intervient Dex : un serveur d’identité qui traduit vos systèmes d’authentification existants (Active Directory, LDAP, Okta…) en un protocole standard que Sigstore comprend.

Le problème : l’authentification en environnement isolé

Imaginons votre situation :

• Vous voulez utiliser Sigstore pour signer vos images de conteneurs
• Votre infrastructure est déconnectée d’Internet (air-gapped)
• Vous ne pouvez donc pas utiliser GitHub ou Google comme fournisseur d’identité
• Mais vos développeurs ont déjà des comptes dans votre Active Directory

Comment faire le lien entre votre annuaire d’entreprise et Sigstore ?

Ce que Sigstore attend

Fulcio (la CA de Sigstore) parle un protocole précis : OpenID Connect (OIDC). Il attend :

• Un endpoint de découverte (/.well-known/openid-configuration)
• Des tokens JWT signés contenant l’identité de l’utilisateur
• Des métadonnées standardisées (email, groupes, etc.)

Ce que vous avez

Votre entreprise utilise probablement :

• Active Directory ou LDAP pour les comptes utilisateurs
• SAML avec Okta, ADFS ou Azure AD pour le SSO
• GitLab ou GitHub Enterprise en interne

Ces systèmes ne parlent pas directement OIDC, ou pas de la façon attendue par Sigstore.

La solution : Dex comme traducteur

Dex est un fédérateur d’identité. Il se connecte à vos systèmes d’authentification et expose une interface OIDC standard.

L'analogie du traducteur universel

Pensez à Dex comme un interprète multilingue :

• Vos systèmes parlent différentes langues (LDAP, SAML, OAuth2…)
• Sigstore ne parle qu’OIDC
• Dex comprend toutes ces langues et les traduit en OIDC

Concepts fondamentaux

Avant de déployer Dex, comprenez ces concepts clés.

Qu’est-ce qu’OIDC ?

OpenID Connect est un protocole d’authentification construit sur OAuth 2.0. Il permet à une application de vérifier l’identité d’un utilisateur et d’obtenir des informations basiques sur son profil.

Le flux simplifié :

1. L’utilisateur veut signer un artefact avec Cosign
2. Cosign redirige vers Dex : « Qui est cet utilisateur ? »
3. Dex redirige vers Active Directory : « Connectez-vous »
4. L’utilisateur entre son login/mot de passe AD
5. AD confirme : « C’est bien jean.dupont@entreprise.fr »
6. Dex génère un token JWT avec cette identité
7. Cosign envoie ce token à Fulcio pour obtenir un certificat

Les composants de Dex

Composant	Rôle	Exemple
Issuer	URL publique de Dex, identifie le serveur	https://dex.mon-entreprise.internal
Connector	Pont vers une source d’identité	LDAP, SAML, GitLab…
Client	Application autorisée à utiliser Dex	Cosign, Kubernetes, votre app
Token JWT	Preuve d’identité signée et temporaire	Contient email, groupes, expiration

Le token JWT : au cœur du système

Quand Dex authentifie un utilisateur, il génère un token JWT (JSON Web Token). C’est un document signé contenant l’identité :

{
  "iss": "https://dex.mon-entreprise.internal",
  "sub": "Cg0wMDAwMDAwMDAwMDAw",
  "aud": "sigstore",
  "exp": 1735480800,
  "iat": 1735480200,
  "email": "jean.dupont@entreprise.fr",
  "email_verified": true,
  "groups": ["developers", "devops"],
  "name": "Jean Dupont"
}

Les champs importants :

• iss (issuer) : qui a émis ce token (Dex)
• sub (subject) : identifiant unique de l’utilisateur
• aud (audience) : pour qui ce token est destiné (Sigstore)
• exp : date d’expiration (le token est temporaire)
• email : l’identité qui sera dans le certificat Fulcio

Pourquoi un token temporaire ?

Le token JWT expire rapidement (10 minutes par défaut). C’est voulu :

• Si quelqu’un vole le token, il ne peut l’utiliser que brièvement
• Chaque signature nécessite une nouvelle authentification
• C’est cohérent avec les certificats éphémères de Fulcio

Choisir vos connecteurs

Dex supporte de nombreuses sources d’identité. Choisissez selon votre contexte.

Quel connecteur pour votre situation ?

Vous avez…	Connecteur	Complexité
Active Directory	ldap	⭐⭐
OpenLDAP	ldap	⭐⭐
Okta, Ping, OneLogin	saml	⭐⭐⭐
Azure AD (Entra ID)	microsoft ou saml	⭐⭐
GitLab interne	gitlab	⭐
GitHub Enterprise	github	⭐
Keycloak	oidc	⭐⭐
Rien (tests)	mockCallback	⭐

Commencez simple

Pour vos premiers tests, utilisez le connecteur mockCallback qui simule une authentification. Une fois le flux validé, passez à votre vrai connecteur.

Combiner plusieurs connecteurs

Dex peut agréger plusieurs sources. L’utilisateur choisit lors de la connexion :

C’est utile si vous avez :

• Des développeurs internes (AD) et des prestataires (GitLab)
• Un SSO d’entreprise (SAML) et un fallback local (LDAP)

Installation de Dex

Prérequis

Avant de commencer, vérifiez que vous avez :

• Un cluster Kubernetes (v1.25 ou plus récent)
• Helm 3.x installé
• cert-manager déployé (pour les certificats TLS)
• Un Ingress Controller (nginx, Traefik…)
• Les informations de connexion à votre annuaire (LDAP, etc.)

Déploiement pas à pas

1. Ajouter le repo Helm officiel

   helm repo add dex https://charts.dexidp.io
   helm repo update

   Vérifiez que le repo est bien ajouté :

   helm search repo dex
   # NAME      CHART VERSION  APP VERSION  DESCRIPTION
   # dex/dex   0.18.0         2.39.0       ...

2. Créer le namespace dédié

   kubectl create namespace dex

3. Préparer le fichier de configuration

   Créez un fichier dex-values.yaml. Nous allons le remplir progressivement dans les sections suivantes.

   dex-values.yaml

   # Configuration de base - on complète ensuite
   config:
     issuer: https://dex.votre-domaine.internal
   
     storage:
       type: kubernetes
       config:
         inCluster: true

4. Déployer Dex

   helm upgrade --install dex dex/dex \
     --namespace dex \
     --values dex-values.yaml \
     --wait

5. Vérifier le déploiement

   # Les pods doivent être Running
   kubectl get pods -n dex
   # NAME                   READY   STATUS    RESTARTS   AGE
   # dex-7d8f9b6c5d-xxxxx   1/1     Running   0          30s
   
   # Vérifier les logs
   kubectl logs -n dex deploy/dex

Configuration complète

Voici une configuration détaillée et commentée pour un environnement de production.

Structure du fichier dex-values.yaml

dex-values.yaml

# ══════════════════════════════════════════════════════════════════════════════
# CONFIGURATION PRINCIPALE
# ══════════════════════════════════════════════════════════════════════════════

config:
  # URL publique de Dex
  # IMPORTANT : doit correspondre EXACTEMENT à votre Ingress
  # Pas de slash final !
  issuer: https://dex.sigstore.internal

  # ────────────────────────────────────────────────────────────────────────────
  # Stockage des tokens et sessions
  # ────────────────────────────────────────────────────────────────────────────
  storage:
    # Pour un déploiement simple, utiliser le stockage Kubernetes (CRDs)
    type: kubernetes
    config:
      inCluster: true

  # ────────────────────────────────────────────────────────────────────────────
  # Serveur web
  # ────────────────────────────────────────────────────────────────────────────
  web:
    # Port HTTP interne (TLS géré par l'Ingress)
    http: 0.0.0.0:5556

  # ────────────────────────────────────────────────────────────────────────────
  # Clients autorisés (applications qui utilisent Dex)
  # ────────────────────────────────────────────────────────────────────────────
  staticClients:
    # Client pour Sigstore (Cosign/Fulcio)
    - id: sigstore
      name: "Sigstore"
      # Secret partagé - CHANGEZ-LE !
      # Générez avec : openssl rand -base64 32 | tr -d '/+=' | cut -c1-32
      secret: "CHANGEZ-MOI-secret-32-caracteres"

      # URIs de callback autorisées
      redirectURIs:
        # Callback local pour cosign CLI
        - "http://localhost:8080/callback"
        - "http://127.0.0.1:8080/callback"
        # Pour le flow "device code" (CI/CD)
        - "urn:ietf:wg:oauth:2.0:oob"

  # ────────────────────────────────────────────────────────────────────────────
  # Connecteurs d'identité (voir section suivante)
  # ────────────────────────────────────────────────────────────────────────────
  connectors: []
    # On remplit cette section selon votre source d'identité

  # ────────────────────────────────────────────────────────────────────────────
  # Expiration des tokens
  # ────────────────────────────────────────────────────────────────────────────
  expiry:
    # Durée de validité du token ID (court pour Sigstore)
    idTokens: "10m"
    # Durée avant expiration des refresh tokens inutilisés
    refreshTokens:
      validIfNotUsedFor: "168h"  # 7 jours

  # ────────────────────────────────────────────────────────────────────────────
  # Options OAuth2
  # ────────────────────────────────────────────────────────────────────────────
  oauth2:
    # Ne pas demander confirmation à chaque connexion
    skipApprovalScreen: true

# ══════════════════════════════════════════════════════════════════════════════
# INGRESS (exposition HTTPS)
# ══════════════════════════════════════════════════════════════════════════════

ingress:
  enabled: true
  className: nginx  # ou traefik, selon votre setup
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"  # ou votre issuer
  hosts:
    - host: dex.sigstore.internal
      paths:
        - path: /
          pathType: Prefix
  tls:
    - secretName: dex-tls
      hosts:
        - dex.sigstore.internal

# ══════════════════════════════════════════════════════════════════════════════
# RESSOURCES ET RÉPLICAS
# ══════════════════════════════════════════════════════════════════════════════

replicaCount: 2  # HA

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 256Mi

Générer un secret client sécurisé

Ne laissez pas le secret par défaut ! Générez-en un :

# Générer un secret aléatoire de 32 caractères
SECRET=$(openssl rand -base64 32 | tr -d '/+=' | cut -c1-32)
echo "Votre secret : $SECRET"
# Copiez-le dans dex-values.yaml

Configurer les connecteurs

Voici les configurations détaillées pour les sources d’identité les plus courantes.

Active Directory / LDAP

Le connecteur le plus courant en entreprise.

dex-values.yaml (section connectors)

config:
  connectors:
    - type: ldap
      id: activedirectory
      name: "Active Directory"
      config:
        # ──────────────────────────────────────────────────────────────────────
        # Connexion au serveur LDAP
        # ──────────────────────────────────────────────────────────────────────

        # Utilisez LDAPS (port 636) pour chiffrer la connexion
        host: ldap.entreprise.local:636

        # Certificat CA pour valider le serveur LDAP
        # Option 1 : chemin vers le fichier (monter un secret)
        rootCA: /etc/dex/ldap-ca/ca.crt
        # Option 2 : contenu encodé en base64
        # rootCAData: "LS0tLS1CRUdJTi..."

        # Pour les tests uniquement (JAMAIS en production !)
        # insecureSkipVerify: true

        # ──────────────────────────────────────────────────────────────────────
        # Compte de service pour les recherches LDAP
        # ──────────────────────────────────────────────────────────────────────

        # DN du compte de service
        bindDN: "CN=svc-dex,OU=Services,DC=entreprise,DC=local"
        # Mot de passe (utiliser une variable d'environnement)
        bindPW: "${LDAP_BIND_PASSWORD}"

        # ──────────────────────────────────────────────────────────────────────
        # Recherche des utilisateurs
        # ──────────────────────────────────────────────────────────────────────

        userSearch:
          # Où chercher les utilisateurs
          baseDN: "OU=Utilisateurs,DC=entreprise,DC=local"

          # Filtre LDAP (ici : comptes utilisateurs actifs)
          filter: "(&(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))"

          # Attribut utilisé comme login
          # Active Directory : sAMAccountName
          # OpenLDAP : uid
          username: sAMAccountName

          # Attribut unique identifiant l'utilisateur
          idAttr: DN

          # Attribut email (sera dans le certificat Fulcio)
          emailAttr: mail

          # Attribut nom complet
          nameAttr: displayName

        # ──────────────────────────────────────────────────────────────────────
        # Recherche des groupes (optionnel mais recommandé)
        # ──────────────────────────────────────────────────────────────────────

        groupSearch:
          # Où chercher les groupes
          baseDN: "OU=Groupes,DC=entreprise,DC=local"

          # Filtre (groupes de sécurité)
          filter: "(objectClass=group)"

          # Comment lier utilisateurs et groupes
          userMatchers:
            - userAttr: DN
              groupAttr: member

          # Attribut nom du groupe
          nameAttr: cn

Préparer le secret LDAP CA :

# Créer un secret avec le certificat CA de votre AD
kubectl create secret generic ldap-ca \
  --from-file=ca.crt=/chemin/vers/ca-ldap.crt \
  -n dex

Ajouter le montage dans values :

dex-values.yaml (ajouter)

# Monter le certificat CA LDAP
volumes:
  - name: ldap-ca
    secret:
      secretName: ldap-ca

volumeMounts:
  - name: ldap-ca
    mountPath: /etc/dex/ldap-ca
    readOnly: true

# Variable d'environnement pour le mot de passe
env:
  - name: LDAP_BIND_PASSWORD
    valueFrom:
      secretKeyRef:
        name: dex-ldap-credentials
        key: password

Créer le secret du mot de passe :

kubectl create secret generic dex-ldap-credentials \
  --from-literal=password='VotreMotDePasseAD' \
  -n dex

SAML (Okta, ADFS)

Pour les SSO d’entreprise utilisant SAML.

dex-values.yaml (section connectors)

config:
  connectors:
    - type: saml
      id: okta
      name: "Okta SSO"
      config:
        # ──────────────────────────────────────────────────────────────────────
        # Configuration SAML
        # ──────────────────────────────────────────────────────────────────────

        # URL de SSO de votre IdP
        # Trouvez-la dans la configuration de l'application SAML Okta
        ssoURL: https://votre-org.okta.com/app/xxxxx/sso/saml

        # Certificat pour vérifier les assertions SAML
        # Téléchargez-le depuis Okta > Applications > votre app > Sign On
        ca: /etc/dex/saml-ca/okta.crt

        # URI de callback (à configurer aussi dans Okta)
        redirectURI: https://dex.sigstore.internal/callback

        # EntityID de Dex (identifiant unique côté Okta)
        entityIssuer: https://dex.sigstore.internal

        # ──────────────────────────────────────────────────────────────────────
        # Mapping des attributs SAML → Claims OIDC
        # ──────────────────────────────────────────────────────────────────────

        # Attribut SAML contenant l'email
        usernameAttr: email
        emailAttr: email

        # Attribut SAML contenant les groupes (si configuré dans Okta)
        groupsAttr: groups

        # Filtrer les groupes (optionnel)
        # allowedGroups:
        #   - devops
        #   - developers

Configuration côté Okta :

1. Créer une nouvelle application SAML 2.0
2. Single Sign-On URL : https://dex.sigstore.internal/callback
3. Audience URI : https://dex.sigstore.internal
4. Télécharger le certificat X.509

GitLab

Pour un GitLab self-hosted.

dex-values.yaml (section connectors)

config:
  connectors:
    - type: gitlab
      id: gitlab
      name: "GitLab Interne"
      config:
        # URL de votre GitLab
        baseURL: https://gitlab.entreprise.local

        # Credentials OAuth2 (créés dans GitLab Admin > Applications)
        clientID: "${GITLAB_CLIENT_ID}"
        clientSecret: "${GITLAB_CLIENT_SECRET}"

        # URI de callback (doit être dans la config GitLab)
        redirectURI: https://dex.sigstore.internal/callback

        # Optionnel : restreindre à certains groupes GitLab
        groups:
          - devops
          - platform-team
        # Si vide, tous les utilisateurs GitLab peuvent se connecter

Créer l’application OAuth2 dans GitLab :

1. Admin Area → Applications → New Application
2. Name : Dex Sigstore
3. Redirect URI : https://dex.sigstore.internal/callback
4. Scopes : read_user, openid, email
5. Notez le Client ID et Secret

Tests (mockCallback)

Pour tester sans source d’identité réelle.

dex-values.yaml (section connectors)

config:
  connectors:
    # Connecteur de test - accepte n'importe quel login
    - type: mockCallback
      id: mock
      name: "Test Login"

  # Optionnel : utilisateurs avec mot de passe en dur
  # UNIQUEMENT pour les tests !
  enablePasswordDB: true
  staticPasswords:
    - email: testuser@example.com
      # Hash bcrypt du mot de passe "password"
      # Générer avec : htpasswd -nbBC 10 "" "votre-mot-de-passe" | tr -d ':\n'
      hash: "$2a$10$2b2cU8CPhOTaGrs1HRQuAueS7JTT5ZHsHSzYiFPm1leZck7Mc8T4W"
      username: testuser
      userID: "test-user-001"

Environnement de test uniquement

Les utilisateurs statiques et le connecteur mock ne doivent JAMAIS être utilisés en production. Ils n’offrent aucune sécurité réelle.

Intégration avec Fulcio

Une fois Dex déployé et fonctionnel, configurez Fulcio pour l’utiliser.

Vérifier que Dex fonctionne

Avant d’intégrer avec Fulcio, validez Dex seul :

# 1. Vérifier l'endpoint de découverte OIDC
curl -s https://dex.sigstore.internal/.well-known/openid-configuration | jq .

# Vous devez voir quelque chose comme :
# {
#   "issuer": "https://dex.sigstore.internal",
#   "authorization_endpoint": "https://dex.sigstore.internal/auth",
#   "token_endpoint": "https://dex.sigstore.internal/token",
#   "jwks_uri": "https://dex.sigstore.internal/keys",
#   ...
# }

# 2. Vérifier les clés de signature
curl -s https://dex.sigstore.internal/keys | jq .

Configurer Fulcio

Dans votre configuration Fulcio (ou scaffold values), ajoutez Dex comme issuer OIDC autorisé :

fulcio-values.yaml

fulcio:
  server:
    oidcIssuers:
      # Votre instance Dex
      - issuer: "https://dex.sigstore.internal"
        clientID: "sigstore"
        type: "email"

        # Claim contenant l'identité (sera dans le certificat)
        # "email" pour la plupart des cas
        # "sub" si vous voulez l'ID unique
        subjectClaim: "email"

L'issuer doit correspondre exactement

L’URL de l’issuer dans Fulcio doit correspondre exactement à celle dans Dex :

• ✅ https://dex.sigstore.internal
• ❌ https://dex.sigstore.internal/ (slash final)
• ❌ http://dex.sigstore.internal (http au lieu de https)

Tester la signature keyless

# Configurer Cosign pour utiliser votre Dex
export COSIGN_OIDC_ISSUER=https://dex.sigstore.internal
export COSIGN_FULCIO_URL=https://fulcio.sigstore.internal
export COSIGN_REKOR_URL=https://rekor.sigstore.internal

# Signer une image
# Dex va ouvrir le navigateur pour l'authentification
cosign sign --yes mon-registry.internal/mon-image:tag

Dépannage

Problèmes courants et solutions

invalid_client

Erreur : invalid_client lors de l’authentification

Cause : Le client ID ou le secret ne correspond pas

Solution :

# Vérifier la configuration des clients
kubectl get configmap dex -n dex -o yaml | grep -A 20 staticClients

# Le client ID dans Cosign doit correspondre
echo $COSIGN_OIDC_CLIENT_ID

redirect_uri_mismatch

Erreur : redirect_uri_mismatch

Cause : L’URI de callback n’est pas dans la liste autorisée

Solution : Ajouter toutes les variantes dans redirectURIs :

staticClients:
  - id: sigstore
    redirectURIs:
      - "http://localhost:8080/callback"
      - "http://127.0.0.1:8080/callback"   # Ajouter aussi 127.0.0.1
      - "http://[::1]:8080/callback"        # IPv6 localhost
      - "urn:ietf:wg:oauth:2.0:oob"         # Device code flow

LDAP connection failed

Erreur : Connexion LDAP échoue

Diagnostic :

# Tester depuis le pod Dex
kubectl exec -it deploy/dex -n dex -- sh

# Test de connexion LDAP
ldapsearch -x -H ldaps://ldap.entreprise.local:636 \
  -D "CN=svc-dex,OU=Services,DC=entreprise,DC=local" \
  -w "motdepasse" \
  -b "OU=Utilisateurs,DC=entreprise,DC=local" \
  "(sAMAccountName=testuser)"

Causes fréquentes :

• Certificat CA manquant ou incorrect
• Mauvais DN de bind
• Firewall bloquant le port 636
• Compte de service désactivé

Token rejected by Fulcio

Erreur : Fulcio rejette le token

Diagnostic :

# Vérifier les logs Fulcio
kubectl logs -n sigstore deploy/fulcio-server | grep -i "oidc\|issuer\|token"

Causes fréquentes :

• Issuer URL différente entre Dex et Fulcio
• Client ID non autorisé dans Fulcio
• Horloge désynchronisée entre serveurs (NTP)

Activer les logs détaillés

dex-values.yaml

config:
  logger:
    level: debug  # info, warn, error, debug
    format: json

Puis consultez les logs :

kubectl logs -n dex deploy/dex -f

Sécurité et bonnes pratiques

Checklist de production

Élément	Vérification
TLS	Dex accessible uniquement en HTTPS
Secrets	Stockés dans des Secrets Kubernetes, pas en clair
Connecteur	Pas de mockCallback ni staticPasswords
Expiration tokens	10 minutes max pour les ID tokens
Ingress	Accès restreint (IP whitelist si possible)
Logs	Centralisés et surveillés
Backup	Si PostgreSQL, backup de la base

Hardening recommandé

dex-values.yaml (production)

config:
  # Tokens courts
  expiry:
    idTokens: "10m"
    signingKeys: "6h"
    deviceRequests: "5m"

  # Pas d'authentification par mot de passe
  enablePasswordDB: false

  # Forcer HTTPS dans les redirections
  oauth2:
    skipApprovalScreen: true
    # responseTypes limités
    responseTypes: ["code"]

# Network policy
networkPolicy:
  enabled: true

# Pod Security
securityContext:
  runAsNonRoot: true
  runAsUser: 1000

À retenir

Concept	Résumé
Rôle de Dex	Fédère vos systèmes d’identité vers OIDC
Connecteur	Pont vers AD, LDAP, SAML, GitLab…
Client	Application autorisée (Sigstore = sigstore)
Token JWT	Preuve d’identité temporaire (10 min)
Issuer	URL unique, doit correspondre partout

Pour aller plus loin

Fulcio L'autorité de certification qui consomme les tokens Dex

Sigstore air-gapped Déploiement complet en environnement déconnecté

Cosign L'outil client qui utilise Dex pour s'authentifier

Ressources externes

• Documentation officielle Dex ↗
• Dex sur GitHub ↗
• Liste des connecteurs supportés ↗
• Helm Chart Dex ↗
• Spécification OpenID Connect ↗