Support bundle

Générer depuis l'admin area (in-cluster)

Pour les installations Helm, GitGuardian fournit une page Support Bundle intégrée dans l'admin area. Cela permet aux administrateurs de générer, télécharger et éventuellement uploader des support bundles directement depuis l'UI web — sans avoir besoin d'un accès kubectl ni du plugin Krew.

Configuration

La génération de support bundle in-cluster est activée par défaut avec toutes les ressources RBAC gérées par le chart. Aucune configuration supplémentaire n'est nécessaire pour un déploiement standard.

Clé	Défaut	Effet
rbac.enabled	true	Crée le rôle GIM avec les permissions de gestion des pods
replicated.supportBundle.rbac.createPodRole	true	Ajoute les règles create/get/delete des pods au rôle GIM
replicated.supportBundle.rbac.serviceAccount.create	true	Crée un ServiceAccount support-bundle dédié pour le pod collector
replicated.supportBundle.rbac.role.create	true	Crée le Role à portée de namespace pour le pod collector
replicated.supportBundle.rbac.clusterRole.create	true	Crée un ClusterRole pour les diagnostics à l'échelle du cluster (nodes, CRDs, etc.)
replicated.supportBundle.admissionPolicy.enabled	true	Déploie une ValidatingAdmissionPolicy restreignant la création de pods (nécessite Kubernetes 1.30+)

Scénarios courants :

• Désactiver entièrement la génération in-cluster — définissez replicated.supportBundle.rbac.createPodRole: false. Cela retire les permissions de gestion des pods du rôle GIM, empêchant l'application de créer des pods support-bundle. Vous pouvez toujours générer des bundles depuis la CLI.
• Gérer le SA support-bundle vous-même — créez le service account et ses bindings en dehors de Helm, puis référencez-le avec existingServiceAccountName et définissez role.create et clusterRole.create à false :

replicated:
  supportBundle:
    rbac:
      serviceAccount:
        create: false
        existingServiceAccountName: 'my-custom-support-bundle-sa'
      role:
        create: false
      clusterRole:
        create: false

• Désactiver la ValidatingAdmissionPolicy (nécessite Kubernetes 1.30+) — définissez replicated.supportBundle.admissionPolicy.enabled: false. Cela retire le garde-fou qui restreint ce que le SA GIM peut créer, ce qui signifie que toute compromission de l'application pourrait permettre la création arbitraire de pods dans le namespace. Ne désactivez ceci que si votre cluster ne prend pas en charge Kubernetes 1.30+, et envisagez de la remplacer par une politique équivalente via OPA/Gatekeeper, Kyverno ou tout autre admission controller.

Comment ça marche

Lorsque vous cliquez sur Generate new support bundle, l'application crée un pod à durée de vie courte dans le même namespace. Ce pod :

1. Exécute la commande kubectl support-bundle contre une spec prédéfinie pour collecter les logs, les ressources du cluster et les données de diagnostic.
2. Sert l'archive .tar.gz résultante via un endpoint HTTP interne pour que l'application puisse la streamer vers votre navigateur.
3. Upload optionnellement le bundle directement vers Replicated pour une analyse à distance par l'équipe support GitGuardian.

Le pod a une durée de vie fixe de 1 heure (activeDeadlineSeconds: 3600). Au-delà, Kubernetes le termine automatiquement.

Architecture de sécurité

La génération de bundle in-cluster utilise deux service accounts séparés avec des permissions strictement séparées :

Service account	Utilisé par	Objectif
GIM service account	Pods webapp-internal-api	Crée, surveille et supprime le pod support-bundle
support-bundle service account	Le pod support-bundle lui-même	Accès en lecture seule au namespace et (optionnellement) aux ressources cluster

Le SA GIM ne détient jamais les permissions de lecture étendues nécessaires au collector, et le collector ne détient jamais les permissions de gestion des pods.

Lorsque admissionPolicy.enabled est true, le chart déploie une ValidatingAdmissionPolicy (nécessite Kubernetes 1.30+) qui restreint ce que le SA GIM peut créer. Seul le pod attendu exact (nom, service account, images, commandes, variables d'environnement) est autorisé. Cela est fortement recommandé — désactivez uniquement si votre cluster ne le prend pas en charge.

Détails RBAC

La définition complète du rôle GIM (incluant les règles de gestion des pods) est documentée dans la section Kubernetes Application RBAC.

Le service account support-bundle nécessite :

Role (à portée de namespace, requis) :

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: support-bundle
  namespace: <gitguardian_namespace>
rules:
  - apiGroups: ['*']
    resources: ['*']
    verbs: ['get', 'list', 'watch']
  - apiGroups: ['']
    resources: ['pods/exec']
    verbs: ['create']

ClusterRole (à portée cluster, optionnel) — le nom est suffixé avec le namespace (support-bundle-<namespace>) pour éviter les collisions dans les clusters multi-tenant :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: support-bundle-<namespace>
rules:
  - apiGroups: ['']
    resources: ['namespaces', 'nodes']
    verbs: ['get', 'list', 'watch']
  - apiGroups: ['apiextensions.k8s.io']
    resources: ['customresourcedefinitions']
    verbs: ['get', 'list', 'watch']
  - apiGroups: ['storage.k8s.io']
    resources: ['storageclasses']
    verbs: ['get', 'list', 'watch']

RBAC auto-géré

Si votre organisation exige que le RBAC soit provisionné en dehors de Helm, désactivez les ressources gérées par le chart en utilisant les scénarios décrits dans la section Configuration et créez vous-même le service account, les rôles et les bindings en utilisant les définitions ci-dessus.

Identifiants d'upload

Pour activer Upload bundle directly to Replicated, le chart crée un secret support-bundle-credentials contenant l'identifiant de licence Replicated et le domaine d'upload. Pour gérer ce secret vous-même :

replicated:
  supportBundle:
    credentials:
      existingSecret: 'my-support-bundle-credentials'

Le secret doit contenir les clés license-id et upload-domain.

upload-domain devrait être replicated.app par défaut et peut être différent à l'avenir.

Limites de ressources

Vous pouvez configurer les requests et limits de ressources pour les deux conteneurs du pod support-bundle :

replicated:
  supportBundle:
    resources:
      initContainer:
        requests:
          cpu: 100m
          memory: 128Mi
        limits:
          cpu: 500m
          memory: 512Mi
      mainContainer:
        requests:
          cpu: 50m
          memory: 32Mi
        limits:
          cpu: 100m
          memory: 64Mi

Dimensionner l'init container

L'init container collecte et compresse le support bundle. Sa consommation mémoire évolue linéairement avec la taille du bundle — environ ~45 Mio par Mo de bundle généré (1 Mo → ~45 Mio, 4 Mo → ~175 Mio, 10 Mo → ~400 Mio). Si l'init container dépasse sa limite mémoire, il est OOMKilled (code de sortie 137) et la génération de bundle échoue.

Augmenter la limite CPU réduit le temps de compression mais n'affecte pas la mémoire. Les valeurs par défaut sont maintenues basses (500m) pour minimiser l'impact sur les autres workloads.

Pour déterminer les bonnes valeurs, générez d'abord un bundle depuis la CLI et vérifiez sa taille :

ls -lh support-bundle-*.tar.gz

Puis ajustez les ressources :

1. Limite mémoire : pic estimé (~45 Mio × taille du bundle en Mo) × 1,5 pour la marge.
2. Request mémoire : moitié de la limite (ratio request-to-limit de 1:2).
3. Limite CPU : augmentez si vous voulez une génération plus rapide et pouvez vous permettre le burst.

Par exemple, si votre bundle de test fait 8 Mo (pic estimé ~360 Mio) :

replicated:
  supportBundle:
    resources:
      initContainer:
        requests:
          cpu: 100m
          memory: 256Mi
        limits:
          cpu: 500m
          memory: 640Mi

astuce

Les bundles qui incluent des logs Loki ou applicatifs verbeux ont tendance à être significativement plus volumineux. Si vous augmentez replicated.supportBundle.logs.maxLines, régénérez un bundle de test pour réévaluer la taille avant d'ajuster les limites de ressources.

Générer depuis la CLI (kubectl)

Installation via Helm

Pour les installations Helm, vous pouvez aussi générer un support bundle depuis la ligne de commande en utilisant le package manager Krew :

1. Installez le plugin Krew.
2. Installez l'utilitaire support-bundle : kubectl krew install support-bundle.
3. Exécutez : kubectl support-bundle --load-cluster-specs --namespace <namespace>.

Cette commande créera un support bundle .tar.gz dans votre répertoire courant. Vous pourrez ensuite l'envoyer au support GitGuardian.

Pour personnaliser le nombre de lignes de logs capturées, définissez le paramètre maxLines comme indiqué ci-dessous. Ajustez la valeur pour capturer plus ou moins de logs selon les besoins :

replicated:
  supportBundle:
    logs:
      maxLines: 100000 # Maximum number of log lines

Si vous n'êtes pas cluster-admin dans votre cluster Kubernetes, vous devrez appliquer la configuration RBAC décrite dans la section Détails RBAC ci-dessus à votre namespace cible.

Installation via KOTS

attention

Si vous avez précédemment installé GitGuardian sur un cluster existant via KOTS et que vous n'avez pas de droits cluster-admin dans votre cluster Kubernetes ou que vous souhaitez limiter les permissions de la console d'administration KOTS, vous devez appliquer la configuration dans votre namespace cible comme décrit dans Kubernetes Application RBAC.

La console d'administration KOTS inclut un outil de diagnostic pour générer un support bundle afin d'identifier les problèmes courants. Les informations sensibles sont automatiquement caviardées. Vous pouvez aussi obtenir une commande pour générer manuellement un support bundle depuis une CLI.

Une fois généré, vous pouvez prévisualiser le contenu et l'envoyer directement à GitGuardian pour analyse.

Pour personnaliser le nombre de lignes de logs capturées dans le support bundle, allez dans la console d'administration KOTS et définissez le champ Maximum number of lines in logs dans la section Support Bundle de la section configuration.

Puis enregistrez la configuration et Déployez l'application pour appliquer la nouvelle configuration.

Générer un support bundle quand le cluster Kubernetes est down

Lors du debug d'un cluster Kubernetes hors ligne, vous pouvez utiliser des host collectors pour générer un support bundle même sans accès à la console d'administration.

Pour commencer, installez l'outil support bundle sur un hôte ayant accès au cluster que vous devez débugger :

curl -L https://github.com/replicatedhq/troubleshoot/releases/latest/download/support-bundle_linux_amd64.tar.gz | tar xzvf -

Ensuite, générez le support bundle avec la commande suivante :

./support-bundle --interactive=false https://raw.githubusercontent.com/replicatedhq/troubleshoot-specs/main/host/default.yaml

remarque

Si votre utilisateur actuel n'a pas l'accès nécessaire pour rassembler les informations pour un collector spécifique, vous devrez peut-être exécuter la commande ci-dessus avec sudo.

Pour les environnements airgap, téléchargez le fichier YAML et copiez-le sur la machine airgap.

Pour plus de détails, consultez la documentation Replicated.