Certificats TLS

Scrydon expose le trafic navigateur et API via des objets Kubernetes Gateway API — une Gateway et une HTTPRoute par application activée. Le chart utilise par défaut la GatewayClass traefik et appose cert-manager.io/cluster-issuer: letsencrypt-prod sur la Gateway, mais la responsabilité du certificat dépend de l'endroit où TLS se termine.

Choisir votre chemin

Responsabilités des certificats

Si l'équilibreur en amont termine TLS et transmet du HTTP à Traefik, le certificat public appartient à cet équilibreur. Traefik doit tout de même faire confiance aux en-têtes transférés ; suivez Déchargement TLS.

Si l'équilibreur en amont re-chiffre vers Traefik, ou si les utilisateurs se connectent directement à Traefik en HTTPS, Traefik a besoin d'un certificat pour le nom d'hôte public.

DNS public et Let's Encrypt

Let's Encrypt ne peut émettre que pour des noms sous DNS publiquement délégué. HTTP-01 exige aussi que le nom d'hôte résolve publiquement vers un ingress capable de servir /.well-known/acme-challenge/... sur le port 80.

DNS-01 n'exige pas que l'enregistrement A soit public, mais exige toujours un domaine publiquement délégué où Let's Encrypt peut interroger le serveur DNS faisant autorité pour les enregistrements TXT _acme-challenge. Par exemple :

Option 1 : ACME interne avec step-ca

Pour les domaines strictement privés où vous voulez quand même l'émission et le renouvellement automatiques, exécutez une CA ACME interne comme Smallstep step-ca et pointez cert-manager vers elle.

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: internal-acme-issuer
spec:
  acme:
    server: https://step-ca.cert-manager.svc.cluster.local/acme/acme/directory
    email: admin@yourcompany.local
    privateKeySecretRef:
      name: internal-acme-account-key
    solvers:
      - http01:
          gatewayHTTPRoute:
            parentRefs:
              - kind: Gateway
                name: gateway-frontdoor
                namespace: scrydon-platform

Utilisez ensuite cet issuer dans vos valeurs Scrydon :

gateway:
  tls:
    enabled: true
    clusterIssuer: internal-acme-issuer
routing:
  host: app.yourcompany.local

cert-manager remplit tls-frontdoor dans l'espace de noms de la plateforme, là où vit la Gateway. Il n'y a jamais qu'une seule demande de certificat par nom d'hôte, dans les deux modes de routage et que vous répartissiez ou non les espaces de noms — le chart porte une unique annotation cert-manager.io/cluster-issuer sur la Gateway, et cert-manager regroupe les listeners par Secret de certificat.

Cela nécessite la prise en charge Gateway API de cert-manager (config.enableGatewayAPI=true) ; voir Prérequis TLS.

Option 2 : apporter vos certificats statiques

Si votre équipe IT ou sécurité émet les certificats via une PKI d'entreprise, créez des Secrets TLS Kubernetes avec les noms référencés par les listeners de la Gateway Scrydon. Définissez gateway.tls.certManager.enabled: false pour que cert-manager ne mette pas votre certificat en concurrence avec une commande ACME, ou pointez tous les listeners vers un seul Secret avec gateway.tls.existingSecret.

Pour le routage sous-chemin par défaut :

kubectl create secret tls tls-frontdoor \
  --cert=path/to/corporate-cert.crt \
  --key=path/to/corporate-key.key \
  -n scrydon-platform

Conservez ce Secret dans scrydon-platform même si vous remplacez namespaces.agentic, namespaces.analytics ou namespaces.cortex. La Gateway possède tous les listeners : les certificateRefs sont donc résolus uniquement depuis l'espace de noms de la Gateway — il n'y a rien à recopier dans les autres espaces de noms, quelle que soit l'implémentation.

Pour le routage sous-domaine, créez également les secrets par application dans l'espace de noms de la Gateway — tous les listeners vivent sur l'unique Gateway :

for name in tls-auth tls-platform tls-cortex tls-agentic tls-agentic-realtime tls-analytics; do
  kubectl create secret tls "$name" \
    --cert=path/to/corporate-wildcard-or-host-cert.crt \
    --key=path/to/corporate-key.key \
    -n scrydon-platform
done

Si vous voulez aussi que Traefik ait un certificat de secours pour les noms d'hôte que les listeners de la Gateway ne couvrent pas, configurez son TLSStore par défaut :

apiVersion: traefik.io/v1alpha1
kind: TLSStore
metadata:
  name: default
  namespace: traefik
spec:
  defaultCertificate:
    secretName: traefik-public-tls

Créez ce Secret traefik-public-tls dans le namespace traefik si vous utilisez ce certificat de secours.

Exigence de confiance côté client

Les certificats issus d'une CA privée ne sont pas automatiquement approuvés par les navigateurs ou clients API. Chaque poste utilisateur, serveur et automatisation qui se connecte à l'endpoint public Scrydon doit faire confiance à la CA racine ou intermédiaire émettrice.

Distribuez la CA racine d'entreprise via votre canal normal de gestion des terminaux, par exemple MDM, Active Directory Group Policy, Jamf, Intune ou votre image Linux de base. Sans cette racine installée, les clients verront des erreurs d'autorité de certification même si Traefik est correctement configuré.

Vérifier

kubectl get gateway -n scrydon-platform
kubectl describe gateway gateway-frontdoor -n scrydon-platform   # un bloc de conditions par listener
kubectl get certificate -A
kubectl -n scrydon-platform get secret tls-frontdoor
openssl s_client -connect app.example.com:443 -servername app.example.com </dev/null

Vérifiez que le sujet/SAN du certificat présenté couvre le nom d'hôte public et que son émetteur chaîne vers une CA approuvée par vos clients.