Livrer votre SaaS on-premise ou en air gap : ce que le client va exiger

Un éditeur SaaS signe un client dont la politique de sécurité exclut le SaaS. Le contrat prévoit une installation dans le centre de données du client, parfois sur un réseau sans connexion à Internet. Ce qui fonctionnait parce que l'éditeur tenait toute la chaîne cesse de fonctionner, et l'équipe sécurité du client arrive avec des exigences que la plateforme SaaS n'a jamais eu à satisfaire.

Cet article s'adresse au CTO qui prépare cette première livraison : ce que le modèle SaaS suppose sans l'écrire, la chaîne d'approvisionnement que le client vérifiera, la plateforme cible, la manière de livrer, de mettre à jour et de diagnostiquer sans accès distant, puis le contrat qui sépare ce que l'éditeur garantit de ce que le client exploite. Cette lecture est établie sur RKE2 v1.36 et v1.37, Kubernetes 1.35 à 1.37, Harbor 2.15, cosign 3.1, Kyverno 1.19, Helm 4 (et Helm 3, dont le support des correctifs de sécurité s'arrête le 11 novembre 2026), Keycloak 26.7, CycloneDX 1.7 et SPDX 3.0 ; les pages officielles citées ont été vérifiées le 29 septembre 2026.

Pourquoi le premier client on-premise casse le modèle SaaS

Un SaaS repose sur des hypothèses vraies par construction, donc jamais écrites. Chez un client isolé, chacune devient fausse, et le produit doit fonctionner sans elles.

Les exigences décrites dans la suite sont des exemples de ce qu'une équipe sécurité peut formuler : chaque client a sa propre liste.

Recenser les dépendances sortantes avant le client

Un risque majeur d'une installation isolée est un appel sortant non recensé : télémétrie, suivi d'erreurs, feature flags, licence en ligne, plugin téléchargé au démarrage, sous-chart Helm sur un dépôt public, polices ou scripts chargés depuis un CDN, serveur NTP public. La méthode la plus sûre est empirique : installer le produit dans un cluster de laboratoire dont les espaces de noms refusent tout trafic sortant (la documentation Kubernetes donne le modèle « Default deny all egress traffic », qui suppose un plugin réseau appliquant les NetworkPolicies), ouvrir l'interface depuis un poste sans Internet et dérouler les tests fonctionnels. Chaque échec désigne une dépendance à rendre optionnelle, paramétrable ou interne. Ce laboratoire sert ensuite à reproduire les incidents du client.

Deux modèles de livraison

Soit le client exploite déjà Kubernetes et l'éditeur livre charts et images, sur une plateforme qu'il ne choisit pas ; soit l'éditeur livre l'application avec son cluster, sur des machines du client, et devient responsable du cycle de vie de Kubernetes, de ses certificats et de ses mises à jour. Ce choix structure le contrat opérationnel et s'écrit avant la première installation.

La chaîne d'approvisionnement : ce que le client vérifie à sa frontière

Le client ne voit pas la chaîne d'intégration de l'éditeur : il vérifie les artefacts à sa frontière.

Signer pour une vérification hors ligne

Le mode par défaut de cosign, la signature sans clé, repose sur un certificat Fulcio de courte durée et sur le journal de transparence public Rekor. Le README de cosign prévient (section signalée comme non à jour par le projet) : pour vérifier hors ligne une signature de l'instance publique, il faut récupérer le fichier trusted_root.json du dépôt TUF, dont le contenu change sans notification, et construire son propre mécanisme pour tenir cette copie à jour.

La signature par clé est plus simple chez un client isolé. La clé privée reste dans un KMS (service de gestion de clés) que cosign adresse par URI ; la clé publique est remise par un canal distinct du bundle. Depuis cosign 3.0.4, vérifier hors ligne avec une clé n'exige plus de racine de confiance.

Deux décisions s'écrivent avec le client. D'abord le journal de transparence : par défaut, cosign inscrit la signature dans Rekor, même avec une clé ; depuis cosign 3, on désactive cette inscription en signant avec un fichier de configuration de signature sans journal de transparence (--signing-config, créé par cosign signing-config create), l'ancienne option --tlog-upload=false étant dépréciée depuis cosign 3.0.3 et, en 3.1, refusée avec la configuration de signature par défaut. Un client peut refuser cette inscription pour les versions qu'il reçoit. Sans inscription, la vérification doit l'ignorer explicitement, et la sécurité repose entièrement sur la garde de la clé, procédure de rotation comprise. Ensuite la contre-signature : une image peut porter plusieurs signatures, et le client peut apposer la sienne après sa recette, son contrôle d'admission exigeant alors les deux.

Transporter l'image avec ses signatures

Depuis cosign 3.0, les signatures sont stockées comme artefacts référents au sens d'OCI Image 1.1 : copier l'image seule perd signatures et attestations, et cosign copy est déprécié depuis la 3.0.5. Restent cosign save et cosign load, qui écrivent puis rechargent une image signée sur disque, et oras cp -r, qui copie un artefact et ses référents (option en préversion chez ORAS) ; oras cp sait aussi écrire dans un répertoire au format OCI avec --to-oci-layout.

# Poste de préparation de l'éditeur : image et signatures vers le bundle
cosign save --dir ./bundle/images/api \
  harbor.editeur.example/produit/api@sha256:<digest>

# Zone d'import du client, sans Internet. --insecure-ignore-tlog seulement
# si la signature n'a pas été inscrite dans un journal de transparence.
cosign verify --key cosign.pub --insecure-ignore-tlog --local-image ./bundle/images/api

# Chargement dans le registre interne
cosign load --dir ./bundle/images/api harbor.interne.example/produit/api

Harbor gère les signatures cosign depuis la version 2.5 et, entre instances Harbor, les réplique avec l'artefact signé, en déclenchement manuel ou planifié seulement. Les notes de version de Harbor 2.15.0 annoncent la prise en charge du format de signature en bundle de cosign v3. Au 29 septembre 2026, le ticket 23210 du projet Harbor, toujours ouvert, signale que la réplication vers Harbor depuis un registre tiers (cas signalé : JFrog Artifactory) ne recopie pas les référents OCI 1.1 (signatures, attestations et SBOM de cosign v3), alors qu'oras cp -r les copie. La règle pratique : jouer la chaîne complète, de la signature à l'admission, avec les versions exactes du registre et du contrôleur du client, avant la première livraison. Si la pile du client ne lit pas encore les référents, cosign 3 permet de revenir aux anciens formats.

Contrôle d'admission : vérifier la clé de l'éditeur

Avec Kyverno 1.19, une politique minimale peut ressembler à l'exemple fictif ci-dessous, non testé en laboratoire, à valider sur un cluster de test avant toute mise en application ; mutateDigest, actif par défaut, ajoute le digest à toute référence d'image qui n'en porte pas. Pour des signatures cosign 3 au format bundle (référents OCI 1.1), Kyverno 1.19 exige type: SigstoreBundle ; le type par défaut Cosign lit l'ancien format.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: signature-editeur
spec:
  webhookConfiguration:
    failurePolicy: Fail
    timeoutSeconds: 30
  background: false
  rules:
    - name: images-editeur-signees
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        - type: SigstoreBundle
          imageReferences:
            - "harbor.interne.example/produit/*"
          failureAction: Enforce
          attestors:
            - count: 1
              entries:
                - keys:
                    publicKeys: |-
                      -----BEGIN PUBLIC KEY-----
                      <clé publique remise par l'éditeur>
                      -----END PUBLIC KEY-----
                    rekor:
                      ignoreTlog: true
                    ctlog:
                      ignoreSCT: true

Depuis Kyverno 1.19.1, le type ClusterPolicy (kyverno.io/v1) est signalé comme déprécié au profit d'ImageValidatingPolicy (policies.kyverno.io) ; il reste fonctionnel, mais une nouvelle livraison gagne à prévoir la migration.

La documentation de Kyverno présente ignoreTlog et ignoreSCT comme des réglages de test : sans journal joignable, les activer est le prix de l'isolement, et ce choix s'écrit. Elle cite aussi failurePolicy: Ignore pour les registres hors ligne, qui laisse passer un pod quand l'appel au registre échoue : avec un registre interne joignable, Fail reste la bonne valeur. Enfin, Kyverno cherche les signatures dans le registre OCI, et sa documentation prévoit qu'une règle de mutation remplace l'adresse du registre avant la vérification ; un miroir déclaré dans le fichier registries.yaml de RKE2 sert, lui, à containerd au moment du tirage, l'image gardant son nom d'origine. Le plus lisible est donc que les manifestes désignent directement le registre interne, et que le registre soit un paramètre du chart.

SBOM : un par digest, dans le format que le client lit

Un SBOM (Software Bill of Materials) est l'inventaire des composants d'un logiciel. CycloneDX, en version 1.7, est publié comme norme Ecma sous la référence ECMA-424 et couvre aussi les déclarations VEX (Vulnerability Exploitability eXchange), qui indiquent si une vulnérabilité est exploitable dans le produit ; SPDX est normalisé ISO/IEC 5962:2021, et sa spécification la plus récente relève de la version 3.0. Le bon format est celui qu'ingère l'outil du client, question à poser dès la première réunion. Le SBOM est produit à partir du digest livré, rattaché à lui par une attestation signée, et fourni aussi en fichier.

Un seuil de vulnérabilités : un engagement qui vieillit

Une image sans vulnérabilité connue au-dessus du seuil convenu le jour de la livraison peut en afficher quelques semaines plus tard, parce que la base aura été mise à jour. L'exigence ne tient qu'avec trois précisions : la référence (scanner, base, date) ; le traitement des vulnérabilités non exploitables, que Trivy accepte sous forme de déclarations VEX aux formats CycloneDX, OpenVEX et CSAF, le statut not_affected retirant la vulnérabilité des résultats ; le délai de correction, fixé au contrat, le correctif empruntant la même chaîne que toute version. Le client refait le scan avec sa propre base, importée comme le reste : dans Harbor, l'option skip_update du scanner Trivy impose de télécharger à la main l'archive de base hors ligne et de la monter dans le conteneur. Deux bases de dates différentes peuvent expliquer des écarts entre rapports.

La plateforme cible : cluster, identité et certificats du client

Profil durci du cluster : les contraintes pour les charts

La documentation de RKE2 décrit des réglages pour passer le benchmark CIS Kubernetes v1.12 ou v1.11 avec une intervention minimale, un mode conforme à FIPS 140-2 par le module BoringCrypto (parmi les plugins réseau, seul Canal, le défaut, est reconstruit pour FIPS) et une analyse de ses composants avec Trivy ; elle présente la distribution comme proche de Kubernetes amont. Pour l'éditeur, cette posture se traduit en contraintes sur ses charts.

Quand l'éditeur livre le cluster, une autorité issue de la PKI du client doit donc être en place avant le premier démarrage ; et le renouvellement ayant lieu au démarrage, l'échéance des certificats entre dans la procédure d'exploitation périodique.

PKI du client : émettre et faire confiance

1. Les certificats que présente le produit sont émis par la PKI du client : fournis en Secrets TLS avec une procédure de renouvellement écrite, ou demandés par cert-manager à un émetteur relié à cette PKI. L'émetteur CA de cert-manager, qui garde la clé de l'autorité dans un Secret Kubernetes, est présenté par sa documentation comme destiné aux démonstrations ou aux utilisateurs outillés pour exploiter une PKI, et suppose de planifier la rotation : il peut ne pas convenir à l'équipe PKI du client.
2. Les autorités auxquelles le produit fait confiance pour joindre l'identité, la messagerie ou une base internes doivent être injectables. trust-manager assemble des autorités depuis des ConfigMaps, des Secrets ou un texte en ligne et les distribue dans les espaces de noms choisis, en PEM et en PKCS#12 (sa référence d'API annonce le retrait à venir du format JKS). Une autorité intégrée à l'image ou une option qui désactive la vérification TLS exposent à un refus à la recette.

Identité : accepter SAML sans réécrire l'application

Le fournisseur d'identité du client peut ne parler que SAML 2.0, quand l'application a été construite en OIDC (OpenID Connect). Keycloak peut servir de courtier : il accepte des fournisseurs SAML v2.0, OpenID Connect v1.0 et OAuth v2, importe une configuration SAML depuis des métadonnées et valide la signature des assertions. L'application reste en OIDC face à Keycloak, qui fédère le fournisseur du client et fait confiance à sa PKI par l'option truststore-paths. Restent à documenter la correspondance entre groupes SAML et rôles, la déconnexion et le compte de secours. La gestion déclarative de Keycloak est traitée dans l'article « Piloter la configuration Keycloak en GitOps : adoption, dérive et suppression de champs ».

Livrer, mettre à jour et diagnostiquer sans accès distant

Trois niveaux d'isolement

Le bundle : ce qu'une version contient

Le bundle est l'unité de livraison et de support : un seul numéro de version, vérifiable sans l'outillage de l'éditeur.

• Les images par digest, avec signatures et attestations, exportées par cosign save ou oras cp -r.
• Les charts Helm. Le support OCI est activé par défaut depuis Helm 3.8.0 et reste en place dans Helm 4, version majeure actuelle ; Helm 3 ne reçoit plus que des correctifs de sécurité, jusqu'au 11 novembre 2026 : helm push publie le chart dans le registre interne, et helm install accepte une référence par digest, immuable. Pour signer un chart OCI, la documentation Helm cite le plugin helm-sigstore.
• La liste des images et digests, les SBOM, les déclarations VEX, le rapport de scan daté et un fichier de sommes SHA-256 signé.
• Les notes de version : migrations de schéma, étapes irréversibles, chemins de mise à jour supportés, compatibilité Kubernetes.
• Si l'éditeur livre le cluster, les artefacts RKE2 de la version cible (rke2-images.linux-amd64.tar.zst, rke2.linux-amd64.tar.gz, sha256sum-amd64.txt, install.sh), que la documentation installe par INSTALL_RKE2_ARTIFACT_PATH.

Des outils dédiés existent : Hauler, outil libre, stocke images, charts et fichiers comme artefacts OCI et les sert par un registre et un serveur de fichiers intégrés, et la documentation isolée de RKE2 en fait l'une de ses méthodes ; Zarf, outil libre, crée des paquets déclaratifs pour environnements isolés et génère les SBOM. L'outil compte moins que le contrat du bundle : le client doit pouvoir tout vérifier avec des outils standard, ou accepter l'outil lui-même à sa recette.

Mettre à jour sans sauter d'étape

Un client isolé met à jour à son rythme, parfois plusieurs versions d'un coup : l'éditeur déclare les chemins de mise à jour supportés et les teste chacun. Après une migration de schéma irréversible, la seule marche arrière fiable est la restauration de la sauvegarde prise juste avant, procédure livrée et jouée au moins une fois.

Si l'éditeur livre le cluster, Kubernetes ajoute sa contrainte : la politique de décalage de versions interdit à kube-apiserver de sauter une version mineure, et la documentation de RKE2 demande de ne pas sauter de version mineure intermédiaire. Le projet Kubernetes maintient les trois versions mineures les plus récentes, 1.37, 1.36 et 1.35 au 29 septembre 2026, avec environ un an de correctifs. Un client resté trois versions en arrière demande trois montées successives, et le bundle doit contenir les artefacts RKE2 intermédiaires. Hors ligne, RKE2 prévoit de déposer les nouvelles archives d'images dans /var/lib/rancher/rke2/agent/images/, de supprimer les anciennes, puis de mettre à jour les serveurs un par un avant les agents ; les mises à jour automatisées supposent les images rancher/rke2-upgrade, system-upgrade-controller et kubectl dans le registre interne.

Diagnostiquer sans accès

Sans accès, le diagnostic se prépare dans le produit, pas pendant l'incident.

• Ce que le produit expose : points de contrôle d'état, journaux structurés, métriques et règles d'alerte livrées en fichiers.
• Le support bundle : le projet Troubleshoot, maintenu par Replicated, fournit kubectl support-bundle, qui collecte journaux et informations du cluster et exécute des commandes déclarées, avec expurgation des données sensibles ; des analyseurs encodent les pannes connues. Depuis sa version 0.47.0, --load-cluster-specs lit les spécifications rangées dans des Secrets et ConfigMaps : le chart peut livrer la sienne, versionnée avec le produit.
• L'expurgation : les expurgateurs intégrés masquent notamment les variables d'environnement commençant par password ou token, les clés AWS et les chaînes de connexion contenant un identifiant et un mot de passe ; depuis la version 0.49.0, les adresses IPv4 ne sont plus masquées par défaut et demandent un expurgateur par expression régulière. Noms d'hôtes, adresses, domaines internes et identifiants d'utilisateurs appellent des expurgateurs propres au produit ; l'archive reste lisible pour que le client la relise.
• Le laboratoire : flux sortants refusés, autorité de certification et fournisseur d'identité de test, registre interne, même version et même profil de durcissement de la distribution ; les incidents propres à l'environnement peuvent s'y reproduire.
• La session à distance : seulement si le client l'autorise et à ses conditions, jamais comme hypothèse du modèle de support.

Le contrat opérationnel : ce que l'éditeur garantit, ce que le client exploite

Sans frontière écrite, chaque incident devient une négociation. L'annexe technique du contrat se rédige avant la première installation et se relit à chaque version majeure.

Le délai de correction et la fenêtre de versions supportées sont des engagements à chiffrer au contrat, pas à promettre en réunion.

Tester la documentation d'exploitation

Une documentation d'exploitation se teste : un opérateur qui n'a jamais vu le produit doit pouvoir l'installer, le mettre à jour, le restaurer, renouveler ses certificats et produire un support bundle avec la seule documentation. Le test le plus simple : confier une installation complète, dans le laboratoire isolé, à une personne extérieure à l'équipe produit. Chaque question posée désigne une page manquante.

Elle nourrit aussi, lorsque le client y est soumis, l'homologation de sécurité, que l'ANSSI (Agence nationale de la sécurité des systèmes d'information) décrit comme l'acceptation formelle des risques par une autorité, réglementaire dans un grand nombre de cas (guide publié en avril 2025). Architecture, matrice des flux, comptes et privilèges, mécanismes cryptographiques et procédure de correction sont des pièces qu'un éditeur peut s'attendre à fournir : autant les livrer dès la première version.

Liste de contrôle avant la première livraison

1. Les dépendances sortantes sont recensées dans un laboratoire à sortie refusée.
2. Le modèle de livraison, application seule ou avec son cluster, est écrit au contrat.
3. Chaque pod passe le profil Restricted ; registre, classe d'entrée et autorités sont des paramètres du chart.
4. La chaîne signature, export, import, réplication et admission a été jouée avec les versions du client.
5. La clé de signature est dans un KMS, la clé publique remise par un canal distinct, la rotation documentée.
6. La politique de journal de transparence est décidée avec le client, et la vérification configurée en conséquence.
7. Les chemins de mise à jour sont testés, et une restauration a été jouée.
8. La spécification de support bundle et ses expurgateurs sont livrés avec le chart.
9. Le format de SBOM attendu est confirmé, et chaque digest livré a son SBOM attesté.
10. Une personne extérieure à l'équipe produit a installé le produit avec la seule documentation.

Ce que la livraison on-premise change ailleurs

Le règlement (UE) 2024/2847 sur la cyberrésilience, dit CRA (Cyber Resilience Act), vise les produits comportant des éléments numériques mis à disposition sur le marché de l'Union. Son article 14, sur le signalement des vulnérabilités activement exploitées et des incidents graves, s'applique depuis le 11 septembre 2026, et l'ensemble du règlement s'appliquera le 11 décembre 2027. Savoir si une version livrée on-premise entre dans son champ, et à quel titre, relève d'une qualification juridique propre à chaque produit.

La page Éditeurs SaaS : livrer on-premise et vendre via AWS Marketplace décrit notre appui aux éditeurs qui livrent en environnement contrôlé ; la page Mise en production Kubernetes : ouvrir par étapes couvre la préparation de la plateforme.

Sources officielles et limites de lecture

Trois points bougent vite : la prise en charge des signatures cosign 3 par les registres et contrôleurs d'admission (ticket Harbor 23210 ouvert à la date de lecture), la copie récursive d'ORAS, en préversion, et le retrait d'ingress-nginx dans RKE2. L'article ne couvre pas la qualification juridique d'un produit au titre du CRA. Les exigences décrites sont des exemples : elles ne remplacent pas la lecture de la liste propre à chaque client.

Sources

1. Air-Gap Install, RKE2, https://docs.rke2.io/install/airgap, consulté le 29/09/2026.
2. Private Registry Configuration, RKE2, https://docs.rke2.io/install/private_registry, consulté le 29/09/2026.
3. Introduction, RKE2, https://docs.rke2.io/, consulté le 29/09/2026.
4. CIS Hardening Guide, RKE2, https://docs.rke2.io/security/hardening_guide, consulté le 29/09/2026.
5. FIPS 140-2 Enablement, RKE2, https://docs.rke2.io/security/fips_support, consulté le 29/09/2026.
6. Certificate Management, RKE2, https://docs.rke2.io/security/certificates, consulté le 29/09/2026.
7. Manual Upgrades, RKE2, https://docs.rke2.io/upgrades/manual, consulté le 29/09/2026.
8. v1.36.X release notes, RKE2, https://docs.rke2.io/release-notes/v1.36.X, consulté le 29/09/2026.
9. Release v1.37.0+rke2r1, projet RKE2, https://github.com/rancher/rke2/releases/tag/v1.37.0%2Brke2r1, consulté le 29/09/2026.
10. Releases, Kubernetes, https://kubernetes.io/releases/, consulté le 29/09/2026.
11. Version Skew Policy, Kubernetes, https://kubernetes.io/releases/version-skew-policy/, consulté le 29/09/2026.
12. Pod Security Standards, Kubernetes, https://kubernetes.io/docs/concepts/security/pod-security-standards/, consulté le 29/09/2026.
13. Network Policies, Kubernetes, https://kubernetes.io/docs/concepts/services-networking/network-policies/, consulté le 29/09/2026.
14. Create a Replication Rule, Harbor 2.15.0, https://goharbor.io/docs/2.15.0/administration/configuring-replication/create-replication-rules/, consulté le 29/09/2026.
15. Configure Proxy Cache, Harbor, https://goharbor.io/docs/main/administration/configure-proxy-cache/, consulté le 29/09/2026.
16. Sign Artifacts with Cosign or Notation, Harbor 2.15.0, https://goharbor.io/docs/2.15.0/working-with-projects/working-with-images/sign-images/, consulté le 29/09/2026.
17. Configure the Harbor YML File, Harbor 2.15.0, https://goharbor.io/docs/2.15.0/install-config/configure-yml-file/, consulté le 29/09/2026.
18. Release v2.15.0, projet Harbor, https://github.com/goharbor/harbor/releases/tag/v2.15.0, consulté le 29/09/2026.
19. OCI 1.1 referrers (Cosign v3 signatures/SBOMs) are not replicated from Artifactory to Harbor, ticket 23210, projet Harbor, https://github.com/goharbor/harbor/issues/23210, consulté le 29/09/2026.
20. README, projet cosign (Sigstore), https://github.com/sigstore/cosign/blob/main/README.md, consulté le 29/09/2026.
21. CHANGELOG, projet cosign (Sigstore), https://github.com/sigstore/cosign/blob/main/CHANGELOG.md, consulté le 29/09/2026.
22. Releases, projet cosign (Sigstore), https://github.com/sigstore/cosign/releases, consulté le 29/09/2026.
23. cosign sign, référence de commande, projet cosign, https://github.com/sigstore/cosign/blob/main/doc/cosign_sign.md, consulté le 29/09/2026.
24. cosign verify, référence de commande, projet cosign, https://github.com/sigstore/cosign/blob/main/doc/cosign_verify.md, consulté le 29/09/2026.
25. cosign save, référence de commande, projet cosign, https://github.com/sigstore/cosign/blob/main/doc/cosign_save.md, consulté le 29/09/2026.
26. Sigstore (verifyImages), Kyverno, https://kyverno.io/docs/policy-types/cluster-policy/verify-images/sigstore/, consulté le 29/09/2026.
27. Verify Images Overview, Kyverno, https://kyverno.io/docs/policy-types/cluster-policy/verify-images/overview/, consulté le 29/09/2026.
28. Releases, projet Kyverno, https://github.com/kyverno/kyverno/releases, consulté le 29/09/2026.
29. oras cp, ORAS, https://oras.land/docs/commands/oras_cp/, consulté le 29/09/2026.
30. Specification Overview, CycloneDX, https://cyclonedx.org/specification/overview/, consulté le 29/09/2026.
31. Overview, SPDX, https://spdx.dev/learn/overview/, consulté le 29/09/2026.
32. Local VEX Files, Trivy, https://trivy.dev/docs/latest/guide/supply-chain/vex/file/, consulté le 29/09/2026.
33. Use OCI-based registries (documentation Helm 4, docs/topics/registries.mdx), dépôt helm/helm-www, https://github.com/helm/helm-www/blob/main/docs/topics/registries.mdx, consulté le 29/09/2026.
34. README, Hauler, https://github.com/hauler-dev/hauler, consulté le 29/09/2026.
35. README, Zarf, https://github.com/zarf-dev/zarf, consulté le 29/09/2026.
36. Collecting a Support Bundle, Troubleshoot, https://troubleshoot.sh/docs/support-bundle/collecting/, consulté le 29/09/2026.
37. Redacting Data, Troubleshoot, https://troubleshoot.sh/docs/redact/, consulté le 29/09/2026.
38. IP Addresses, Troubleshoot, https://troubleshoot.sh/docs/redact/ip-addresses/, consulté le 29/09/2026.
39. Server Administration Guide, Keycloak, https://www.keycloak.org/docs/latest/server_admin/index.html, consulté le 29/09/2026.
40. Configuring trusted certificates, Keycloak, https://www.keycloak.org/server/keycloak-truststore, consulté le 29/09/2026.
41. CA Issuer, cert-manager, https://cert-manager.io/docs/configuration/ca/, consulté le 29/09/2026.
42. trust-manager, cert-manager, https://cert-manager.io/docs/trust/trust-manager/, consulté le 29/09/2026.
43. Homologation de sécurité, ANSSI, https://cyber.gouv.fr/securisation/homologation-de-securite/, consulté le 29/09/2026.
44. Le guide de l'homologation de sécurité des systèmes d'information (avril 2025), ANSSI, https://cyber.gouv.fr/sites/default/files/document/guide-homologation-securite-web-04-2025.pdf, consulté le 29/09/2026.
45. Règlement (UE) 2024/2847 du 23 octobre 2024 (cyberrésilience), EUR-Lex, https://eur-lex.europa.eu/eli/reg/2024/2847/oj/fra, consulté le 29/09/2026.
46. trust-manager API Reference, cert-manager, https://cert-manager.io/docs/trust/trust-manager/api-reference/, consulté le 29/09/2026.
47. options/sign.go, v3.1.3, projet cosign, https://github.com/sigstore/cosign/blob/v3.1.3/cmd/cosign/cli/options/sign.go, consulté le 29/09/2026.
48. signcommon/common.go, v3.1.3, projet cosign, https://github.com/sigstore/cosign/blob/v3.1.3/cmd/cosign/cli/signcommon/common.go, consulté le 29/09/2026.
49. image_verification_types.go, v1.19.1, projet Kyverno, https://github.com/kyverno/kyverno/blob/v1.19.1/api/kyverno/v1/image_verification_types.go, consulté le 29/09/2026.
50. Helm 4 Released (section Helm v3 Support), blog Helm, https://helm.sh/blog/helm-4-released/, consulté le 29/09/2026.
51. clusterpolicy_types.go, v1.19.1, projet Kyverno, https://github.com/kyverno/kyverno/blob/v1.19.1/api/kyverno/v1/clusterpolicy_types.go, consulté le 29/09/2026.
52. Use OCI-based registries (documentation Helm 3), Helm, https://helm.sh/docs/v3/topics/registries/, consulté le 29/09/2026.
53. Helm 4 Overview (section Enhanced OCI Support), Helm, https://helm.sh/docs/overview/, consulté le 29/09/2026.