Déploiement en environnement isolé (Air Gap)

Utilisez ce guide si votre cluster Kubernetes n'a pas accès à Internet en sortie — par exemple, des réseaux gouvernementaux classifiés, des environnements industriels isolés ou des environnements soumis à des exigences de conformité strictes. Si votre cluster peut accéder à Internet, consultez Helm à la place.

Qu'est-ce que Zarf ?

Zarf est un outil open source (Apache 2.0) conçu spécifiquement pour livrer des applications Kubernetes dans des environnements isolés et déconnectés. Scrydon utilise Zarf pour regrouper toutes les images de conteneurs, les charts Helm et les manifests en une seule archive .tar.zst autonome pouvant être transférée physiquement (USB, DVD, passerelle inter-domaines) ou via une diode de données unidirectionnelle.

Capacité	Comment Zarf le gère
Chargement des images	Pousse automatiquement toutes les images vers un registre interne au cluster
Réécriture des références d'images	Un webhook mutant réécrit les références d'images — aucun remplacement manuel d'`imageRegistry` nécessaire
Gestion du registre	Zarf déploie et gère le registre interne au cluster
Vérification des signatures	Vérification Cosign intégrée
SBOM	Intégré (Syft, avec visionneuse)

Vous n'avez pas besoin de Harbor, Artifactory ou d'un registre externe. Zarf fournit tout.

Prérequis

Cluster Kubernetes 1.28+ (isolé)
CLI zarf installée — un binaire statique unique, disponible sur zarf.dev/releases ou livré avec votre package
Bundle de licence ({ jwt, publicKey } fichier JSON) reçu via un canal sécurisé — voir Licences. Les fichiers .jwt seuls ne sont plus acceptés ; le bundle contient la clé publique RSA correspondante pour que la plateforme puisse vérifier les signatures sans appel réseau.

Étape 1 : Recevoir le package

Scrydon livre les packages en environnement isolé sous forme d'archive .tar.zst signée, publiée dans un registre OCI :

# Récupérer le package Zarf depuis le registre OCI (sur une machine connectée)
zarf package pull oci://ghcr.io/scrydon/scrydon:<version>

# Sortie : zarf-package-scrydon-amd64-<version>.tar.zst

Transférez ce fichier dans votre environnement isolé via les moyens approuvés (USB chiffré, DVD, passerelle inter-domaines, diode de données unidirectionnelle). Le package est une archive tar standard et est compatible avec la plupart des équipements de passerelle inter-domaines.

Étape 2 : Vérifier le package

Avant le déploiement, vérifiez l'intégrité et l'authenticité du package.

Vérifier la signature Cosign

zarf package inspect zarf-package-scrydon-amd64-<version>.tar.zst \
  --key scrydon-cosign-public-key.pem

La clé publique Scrydon (scrydon-cosign-public-key.pem) est livrée avec le package. Contactez votre représentant commercial Scrydon si vous avez besoin d'une nouvelle copie.

Vérifier la somme de contrôle SHA-256

sha256sum -c SHA256SUMS

Le fichier SHA256SUMS est inclus dans le bundle de livraison. Les deux vérifications doivent réussir avant le déploiement.

Inspecter le SBOM

zarf package inspect zarf-package-scrydon-amd64-<version>.tar.zst --sbom

Cela ouvre la visionneuse SBOM intégrée, listant tous les composants logiciels et leurs licences inclus dans le package.

Étape 3 : Déployer le package

zarf package deploy zarf-package-scrydon-amd64-<version>.tar.zst --confirm

Zarf va :

Créer un registre OCI interne au cluster (s'il n'en existe pas déjà un)
Charger toutes les images de conteneurs depuis l'archive dans le registre interne au cluster
Déployer un webhook mutant qui réécrit les références d'images pour pointer vers le registre interne au cluster
Exécuter helm install avec le chart Helm et les valeurs regroupés dans le package
Attendre que tous les déploiements soient prêts

Pour passer une configuration personnalisée lors du déploiement :

zarf package deploy zarf-package-scrydon-amd64-<version>.tar.zst \
  --confirm \
  --set DOMAIN=scrydon.yourdomain.mil

Étape 4 : Appliquer le bundle de licence

Après le déploiement, appliquez votre bundle de licence. Le bundle est un fichier JSON livré séparément via un canal sécurisé ({ "jwt": "…", "publicKey": "-----BEGIN PUBLIC KEY-----…" }) et n'est PAS inclus dans le package Zarf. Il n'y a pas de Secret Kubernetes scrydon-license — le bundle est stocké dans la ligne platform_config DB de la plateforme après sa première utilisation, et est renouvelé via l'interface de la plateforme.

Vous avez deux façons d'appliquer le bundle lors d'une nouvelle installation :

Option A — assistant /setup (par défaut). Ouvrez https://app.yourdomain.com/platform/setup (ou /setup si vous avez monté platform à la racine) dans un navigateur et collez/déposez le bundle à l'Étape 1. L'assistant analyse le bundle, vérifie le JWT par rapport à la clé publique du bundle et les persiste à l'Étape 2.

Option B — pré-configuration via les valeurs Helm. Définissez auth.secrets.LICENSE (le jwt du bundle) et auth.secrets.LICENSE_PUBLIC_KEY (la publicKey du bundle) lors du déploiement du package Zarf, puis passez directement à l'étape Admin dans /setup :

zarf package deploy zarf-package-scrydon-amd64-<version>.tar.zst \
  --confirm \
  --set LICENSE_JWT="$(jq -r .jwt license.bundle.json)" \
  --set LICENSE_PUBLIC_KEY="$(jq -r .publicKey license.bundle.json)"

Quelle que soit la méthode choisie, la licence est persistée dans la base de données lors de la première lecture et les entrées de valeurs ne sont plus consultées par la suite.

Étape 5 : Vérifier le déploiement

Vérifier l'état des pods

La mise en page par défaut du chart place tous les services dans scrydon-platform. Les installations multi-espaces de noms sont optionnelles via les remplacements namespaces.*.

kubectl get pods -n scrydon-platform
# Si vous avez divisé les espaces de noms via namespaces.agentic / namespaces.analytics,
# vérifiez également ces espaces de noms.

Tous les pods doivent atteindre Running 2/2 (conteneur applicatif + sidecar Dapr). Si les pods restent à 1/1, l'injection Dapr a échoué — vérifiez kubectl get pod -l app=dapr-sidecar-injector -A.

Si un pod est bloqué en Init:0/1, le conteneur init wait-for-db n'a pas terminé — confirmez que le Postgres intégré (kubectl get pod -l app=db -n scrydon-platform) est en Running.

Vérifier l'Ingress

kubectl get ingress -n scrydon-platform

Toutes les options

Le package Zarf enveloppe le même chart Helm. Toute valeur du chart peut être définie au moment du déploiement avec --set <KEY>=<VALUE> (comme indiqué pour DOMAIN et la licence ci-dessus), ou intégrée dans la superposition de valeurs du bundle. Chaque valeur exposée par le chart — routage, BYO database, StarRocks/SeaweedFS, planification, ajustements pour ressources limitées — est documentée dans la référence Helm. Les installations en environnement isolé définissent également license.mode: offline pour que la plateforme ne se connecte jamais à l'extérieur.

Considérations de sécurité

Les environnements isolés ont des exigences de sécurité supplémentaires :

Aucune résolution DNS externe : Le mode de licence hors ligne de Scrydon ne passe aucun appel réseau sortant. Le JWT de licence est validé localement à l'aide de la clé publique intégrée.
Aucune télémétrie : Dans les déploiements en environnement isolé, aucune donnée de télémétrie ou d'analyse ne quitte le cluster.
Intégrité des images : Toutes les images sont épinglées par digest. Le webhook mutant réécrit les références vers le registre interne au cluster tout en préservant les épingles de digest.
Secrets : Le JWT de licence et tous les identifiants que vous fournissez sont stockés uniquement sous forme de Secrets Kubernetes dans votre cluster. Zarf ne retient ni ne transmet ces valeurs.

Suivant : Voir Licences pour les détails sur la validation des licences, les périodes de grâce et le renouvellement.

Déploiement en environnement isolé (Air Gap)

Sur cette page