Auth0 dans un environnement Kubernetes : configuration et secrets

Comment intégrer Auth0 dans votre cluster Kubernetes ? Gestion des secrets, sidecars d'injection de tokens et configuration des services.

Par Auth0.Expert · 2025-03-12 · 11 min de lecture

Kubernetes DevOps Containers

Auth0 dans Kubernetes : guide complet

TL;DR

Kubernetes et Auth0 s'intègrent naturellement : secrets via External Secrets Operator, tokens M2M dans les Pods, et sidecar de validation JWT. Ce guide présente les patterns de production.

---

Avant d’aborder les exemples, voici comment gérer les secrets Auth0 dans Kubernetes grâce à External Secrets Operator, pour synchroniser vos informations d'identification de façon sécurisée.

Pattern 1 : Secrets Auth0 via External Secrets Operator

Ce code montre comment installer l’External Secrets Operator et configurer la synchronisation de secrets Auth0 depuis AWS Secrets Manager vers Kubernetes. Cela permet de garder vos credentials toujours à jour et sécurisés.

# Installation External Secrets Operator
helm repo add external-secrets https://charts.external-secrets.io
helm install external-secrets external-secrets/external-secrets

---
# ClusterSecretStore (AWS Secrets Manager)
apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
  name: aws-secretsmanager
spec:
  provider:
    aws:
      service: SecretsManager
      region: eu-west-1
      auth:
        jwt:
          serviceAccountRef:
            name: external-secrets-sa
            namespace: external-secrets

---
# ExternalSecret : synchroniser les secrets Auth0
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: auth0-m2m-secrets
  namespace: backend
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secretsmanager
    kind: ClusterSecretStore
  target:
    name: auth0-m2m-secrets
    creationPolicy: Owner
  data:
    - secretKey: AUTH0_CLIENT_ID
      remoteRef:
        key: prod/auth0/m2m
        property: client_id
    - secretKey: AUTH0_CLIENT_SECRET
      remoteRef:
        key: prod/auth0/m2m
        property: client_secret
    - secretKey: AUTH0_DOMAIN
      remoteRef:
        key: prod/auth0/m2m
        property: domain

Ce bloc configure la synchronisation automatique des secrets Auth0 depuis AWS Secrets Manager vers Kubernetes.

---

Après avoir provisionné les secrets, vous devez les injecter dans vos applications. Voici comment un déploiement standard consomme ces secrets.

Pattern 2 : Déploiement avec secrets Auth0

Ce manifeste montre comment rendre les secrets Auth0 disponibles dans un conteneur d’application via des variables d’environnement, pour accéder à Auth0 en toute sécurité.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-backend
  namespace: backend
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: api
          image: yourapp/api:latest
          env:
            - name: AUTH0_DOMAIN
              valueFrom:
                secretKeyRef:
                  name: auth0-m2m-secrets
                  key: AUTH0_DOMAIN
            - name: AUTH0_CLIENT_ID
              valueFrom:
                secretKeyRef:
                  name: auth0-m2m-secrets
                  key: AUTH0_CLIENT_ID
            - name: AUTH0_CLIENT_SECRET
              valueFrom:
                secretKeyRef:
                  name: auth0-m2m-secrets
                  key: AUTH0_CLIENT_SECRET
            - name: AUTH0_AUDIENCE
              value: "https://api.yourapp.com"
          resources:
            requests:
              memory: "256Mi"
              cpu: "250m"
            limits:
              memory: "512Mi"
              cpu: "500m"

---

Lorsque vous avez besoin de protéger un service derrière une authentification forte, le pattern sidecar est très utilisé. Voici comment ajouter un sidecar qui valide les tokens JWT Auth0.

Pattern 3 : Sidecar de validation JWT (OAuth2-Proxy)

Ce fichier déploie un service principal et un conteneur sidecar oauth2-proxy, qui filtre le trafic et valide les tokens JWT émis par Auth0 grâce à OpenID Connect.

# oauth2-proxy comme sidecar pour valider les tokens Auth0
apiVersion: apps/v1
kind: Deployment
metadata:
  name: protected-service
spec:
  template:
    spec:
      containers:
        # Service principal
        - name: app
          image: yourapp/service:latest
          ports:
            - containerPort: 8080

        # Sidecar oauth2-proxy
        - name: oauth2-proxy
          image: quay.io/oauth2-proxy/oauth2-proxy:v7.6.0
          args:
            - --provider=oidc
            - --oidc-issuer-url=https://YOUR_DOMAIN.auth0.com/
            - --upstream=http://localhost:8080
            - --http-address=:4180
            - --email-domain=*
            - --skip-provider-button=true
            - --cookie-secure=true
          env:
            - name: OAUTH2_PROXY_CLIENT_ID
              valueFrom:
                secretKeyRef:
                  name: auth0-oauth2-proxy
                  key: client_id
            - name: OAUTH2_PROXY_CLIENT_SECRET
              valueFrom:
                secretKeyRef:
                  name: auth0-oauth2-proxy
                  key: client_secret
            - name: OAUTH2_PROXY_COOKIE_SECRET
              valueFrom:
                secretKeyRef:
                  name: auth0-oauth2-proxy
                  key: cookie_secret
          ports:
            - containerPort: 4180

Ce déploiement offre une couche de sécurité supplémentaire en validant les accès à votre application avec Auth0.

---

Pour gérer l’authentification sur vos services internes via OIDC, il est courant de configurer l’Ingress NGINX pour fédérer l’accès via Auth0.

Pattern 4 : OIDC dans Ingress NGINX

Voici comment forcer l’authentification via Auth0 sur une route NGINX, pour sécuriser l’accès à vos outils internes exposés sur Kubernetes.

# Nginx Ingress avec Auth0 pour les services internes
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: internal-tool
  annotations:
    nginx.ingress.kubernetes.io/auth-url: "https://oauth2-proxy.auth.svc.cluster.local/oauth2/auth"
    nginx.ingress.kubernetes.io/auth-signin: "https://auth.yourapp.com/oauth2/start?rd=$escaped_request_uri"
    nginx.ingress.kubernetes.io/auth-response-headers: "X-Auth-Request-User,X-Auth-Request-Email"
spec:
  rules:
    - host: internal-tool.yourapp.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: internal-tool
                port:
                  number: 80

---

Pour les workloads ponctuels, comme les scripts de migration, il est possible d’utiliser des tokens Auth0 en Machine-to-Machine dans les Jobs Kubernetes.

Token M2M dans les Jobs Kubernetes

Ce manifeste Job permet à un script d’obtenir son token Auth0 en toute sécurité, via des secrets injectés, pour consommer des APIs protégées.

# Job Kubernetes qui s'authentifie en M2M pour accéder à l'API
apiVersion: batch/v1
kind: Job
metadata:
  name: data-migration-job
spec:
  template:
    spec:
      serviceAccountName: migration-job-sa
      containers:
        - name: migration
          image: yourapp/migration:latest
          command: ["python", "migrate.py"]
          env:
            - name: AUTH0_CLIENT_ID
              valueFrom:
                secretKeyRef:
                  name: auth0-m2m-secrets
                  key: AUTH0_CLIENT_ID
            - name: AUTH0_CLIENT_SECRET
              valueFrom:
                secretKeyRef:
                  name: auth0-m2m-secrets
                  key: AUTH0_CLIENT_SECRET
      restartPolicy: OnFailure

---

La rotation régulière des secrets Auth0 est cruciale : vous pouvez automatiser cela avec des CronJob Kubernetes.

CronJob : rotation des secrets Auth0

Ce CronJob exécute un script de rotation des secrets Auth0 chaque semaine, pour garantir la sécurité de votre infrastructure.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: rotate-auth0-secrets
spec:
  schedule: "0 2 * * 1"  # Tous les lundis à 2h
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: rotate
              image: yourapp/secret-rotator:latest
              command: ["python", "rotate_auth0_secret.py"]
              env:
                - name: AUTH0_MGMT_TOKEN
                  valueFrom:
                    secretKeyRef:
                      name: auth0-mgmt-token
                      key: token

Ce CronJob automatise et fiabilise la gestion du cycle de vie des secrets Auth0 dans votre cluster.

---

La sécurité réseau est essentielle : restreignez les flux sortants des pods vers Auth0 uniquement.

Network Policy : restreindre les appels Auth0

Cette policy Kubernetes autorise seulement les pods disposant du label approprié à joindre Auth0 en HTTPS, réduisant ainsi la surface d’exposition.

# Permettre uniquement aux pods autorisés d'appeler Auth0
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-auth0-egress
  namespace: backend
spec:
  podSelector:
    matchLabels:
      auth0-enabled: "true"
  policyTypes:
    - Egress
  egress:
    - ports:
        - port: 443
          protocol: TCP
      to:
        - ipBlock:
            cidr: 0.0.0.0/0  # Auth0 IPs dynamiques

---

> ☸️ Auth0 + Kubernetes : nous déployons votre infrastructure d'authentification Auth0 sur Kubernetes avec haute disponibilité et rotation automatique des secrets.

📧 [email protected]

Autres articles