Certificats TLS

Les certificats TLS doivent être définis afin que le domaine référençant votre instance GitGuardian soit correctement authentifié et sécurisé. Le Common Name du certificat TLS doit correspondre au domaine défini comme nom d'hôte 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 les certificats TLS pour :

1. KOTS Admin Console : utilisé pour l'accès utilisateur à la KOTS Admin Console.
2. GitGuardian Application : utilisé pour l'accès utilisateur à l'application GitGuardian (parfois aussi appelé 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é, quel que soit son statut d'expiration, afin de maintenir la sécurité du système.

KOTS Admin Console

Pour mettre à jour le certificat TLS de la KOTS Admin Console, suivez ces instructions.

attention

L'ajout de 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 refermée.

Version courte :

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

Si nécessaire, spécifiez un autre namespace Kubernetes (le namespace par défaut est utilisé si non spécifié).

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

GitGuardian Application

attention

Lorsque vous utilisez des certificats auto-signés ou CA personnalisée, veillez à désactiver la vérification SSL pour le webhook GitHub.

Installation basée sur 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 les annotations de votre Ingress ou Service, selon les exigences spécifiques de votre fournisseur cloud.

Pour téléverser de nouveaux certificats, remplacez les fichiers précédemment téléversés dans la KOTS Admin Console.

Après avoir mis à jour la configuration, déployez la nouvelle version qui n'inclut que les modifications de configuration :

Installation basée sur 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

Lorsque vous utilisez l'authentification par certificat, la configuration TLS se trouve dans tls.clientAuth.

Utilisation de cert-manager

Dans une installation Helm, vous pouvez utiliser cert-manager pour émettre automatiquement les certificats TLS. 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 valeurs 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 valeurs 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 plus d'informations détaillées sur la configuration du SAML SSO, consultez la page Configurer SAML SSO.

Si vous installez GitGuardian avec Helm, générez un nouveau certificat SSO, puis modifiez votre fichier de valeurs Helm. Pour plus de détails, consultez la page Gestion des informations sensibles Helm.

Générer un certificat auto-signé

Pour effectuer 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 de 2048 bits à l'aide d'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 pendant 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, spécifiez le namespace Kubernetes avec --namespace (le namespace par défaut est utilisé si non spécifié).

Se connecter à la KOTS Admin Console

Pour appliquer les modifications, connectez-vous à la KOTS admin console :

kubectl kots --namespace <namespace> admin-console

Si nécessaire, spécifiez le namespace Kubernetes avec --namespace (le namespace par défaut est utilisé si non spécifié).

Déployer la nouvelle version

Après avoir mis à jour la configuration, déployez la nouvelle version qui n'inclut que les modifications 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.