Certificats TLS

Les certificats TLS doivent être définis pour que le domaine référant à votre instance GitGuardian soit correctement authentifié et sécurisé. Le Common Name du certificat TLS doit correspondre au domaine défini pour le hostname de votre instance GitGuardian.

Vous pouvez utiliser des certificats auto-signés pour tester le déploiement de l'application, mais sachez que cela peut entraîner des problèmes d'intégration avec les VCS et n'est pas recommandé au-delà des tests initiaux.

Vous devez configurer des certificats TLS pour :

1. Console d'administration KOTS : utilisée pour l'accès utilisateur à la console d'administration KOTS.
2. Application GitGuardian : utilisée pour l'accès utilisateur à l'application GitGuardian (parfois aussi appelée NGINX).
3. SAML SSO : utilisé pour le Single Sign-On (ou SSO) afin de gérer l'ensemble des membres de votre organisation via un fournisseur tiers.

attention

Nous recommandons fortement de révoquer tout certificat remplacé, indépendamment de son statut d'expiration, pour maintenir la sécurité du système.

Console d'administration KOTS

Pour mettre à jour le certificat TLS de la console d'administration KOTS, suivez ces instructions.

attention

Ajouter l'annotation acceptAnonymousUploads crée temporairement une vulnérabilité permettant à un attaquant de téléverser des certificats TLS de manière malveillante. Une fois les certificats TLS téléversés, la vulnérabilité est de nouveau fermée.

Version courte :

NAMESPACE=default
kubectl --namespace "${NAMESPACE}" annotate secret kotsadm-tls acceptAnonymousUploads=1
kubectl --namespace "${NAMESPACE}" delete pod -l app=kurl-proxy-kotsadm

Si nécessaire, précisez un autre namespace Kubernetes (le namespace par défaut est utilisé sinon).

Une fois le pod redémarré, dirigez votre navigateur vers http://<ip>:8800/tls et suivez le processus de téléversement dans l'interface utilisateur.

Application GitGuardian

attention

Lors de l'utilisation de certificats auto-signés ou de CA personnalisée, veillez à désactiver la vérification SSL pour le webhook GitHub.

Installation via KOTS

Les certificats TLS sont configurés dans la section TLS certificates.

Vous avez la possibilité d'utiliser les certificats TLS auto-signés, ou vous pouvez fournir vos propres certificats comme indiqué ci-dessous. La méthode recommandée est d'utiliser un secret existant.

Pour les clusters existants, dans les scénarios où le certificat TLS est géré par l'infrastructure de votre fournisseur cloud, vous pouvez le référencer directement dans vos annotations Ingress ou Service, selon les exigences spécifiques de votre fournisseur cloud.

Pour téléverser de nouveaux certificats, remplacez les fichiers téléversés précédemment dans la console d'administration KOTS.

Après avoir mis à jour la configuration, déployez la nouvelle version qui inclut uniquement les changements de configuration :

Installation via Helm

Dans une installation Helm, le certificat peut être défini dans la section front.ingress.tls.

Vous pouvez fournir les certificats TLS sous forme de secret existant (recommandé) ou de certificat brut.

ingress:
  enabled: true
  ingressClassName: 'nginx'
  tls:
    enabled: true
    existingSecret: my-gitguardian-certificate

attention

Lors de l'utilisation de l'authentification basée sur les certificats, la configuration TLS est située dans tls.clientAuth.

Avec cert-manager

Dans une installation Helm, vous pouvez utiliser cert-manager pour émettre les certificats TLS automatiquement. Cert-manager doit être correctement installé et configuré dans votre cluster, avec une ressource Issuer ou ClusterIssuer.

Les certificats sont créés dans un secret Kubernetes, et peuvent être utilisés soit par Istio Ingress, soit par un Ingress classique.

La clé privée est PKCS#1 d'une longueur de 2048.

La configuration se fait dans le fichier de values local avec la section tls :

tls:
  certManager:
    enabled: true
    issuer:
      kind: ClusterIssuer
      name: my-cluster-issuer
    certificatesSecret: my-gitguardian-certificate

Si vous utilisez un ingress classique avec les values front.ingress, le nom du secret du certificat doit être spécifié dans front.ingress.tls.secretName.

SAML SSO

Ce guide décrit les étapes pour mettre à jour le certificat X509 SSO utilisé par GitGuardian pour l'authentification avec un fournisseur SSO tiers. Pour des informations plus détaillées sur la configuration SAML SSO, consultez la page Configurer SAML SSO.

Si vous installez GitGuardian via Helm, générez un nouveau certificat SSO, puis éditez votre fichier de values Helm. Pour plus de détails, consultez la page Helm Sensitive Information Management.

Générer un certificat auto-signé

Pour faire la rotation du certificat SSO, commencez par générer un nouveau certificat auto-signé :

1. Générez une nouvelle clé privée RSA :

Générez une nouvelle clé privée RSA 2048 bits via OpenSSL avec la commande suivante :

openssl genrsa -out gitguardian.key 2048

2. Créez une Certificate Signing Request (CSR) :

Utilisez la clé privée générée pour créer une CSR. Remplacez <hostname> par le Fully Qualified Domain Name de votre instance Self-Hosted.

openssl req -new -subj '/CN=<hostname>' \
  -key gitguardian.key \
  -out gitguardian.csr

3. Créez un certificat auto-signé :

Utilisez la CSR pour créer un certificat auto-signé valide pour 365 jours (ou selon vos besoins) :

openssl x509 -req -days 365 -in gitguardian.csr \
  -signkey gitguardian.key -out gitguardian.crt

Préparer le fichier de configuration KOTS

Créez ou mettez à jour votre config.yaml pour inclure le nouveau certificat et la nouvelle clé :

apiVersion: kots.io/v1beta1
kind: ConfigValues
spec:
  values:
    embedded_certificate:
      values: |
        <content_of_gitguardian.crt>

    embedded_key:
      values: |
        <content_of_gitguardian.key>

Mettre à jour les valeurs de configuration KOTS

Mettez à jour la configuration KOTS avec le nouveau certificat et la nouvelle clé privée :

kubectl kots set config gitguardian --namespace <namespace> \
  --config-file config.yaml \
  --merge

Si nécessaire, précisez le namespace Kubernetes avec --namespace (le namespace par défaut est utilisé sinon).

Se connecter à la console d'administration KOTS

Pour appliquer les changements, connectez-vous à la console d'administration KOTS :

kubectl kots --namespace <namespace> admin-console

Si nécessaire, précisez le namespace Kubernetes avec --namespace (le namespace par défaut est utilisé sinon).

Déployer la nouvelle version

Après avoir mis à jour la configuration, déployez la nouvelle version qui inclut uniquement les changements de configuration :

info

Si vous rencontrez des erreurs 403 après avoir tenté de « Login with Okta », vider le cache de votre navigateur web peut résoudre le problème.