Exécuter Keyright auto-hébergé totalement isolé (air-gapped), sans internet sortant

Certains réseaux ne touchent jamais internet, par politique et par conception — une enclave classifiée, un système de contrôle isolé, la zone de production cloisonnée d’une banque, un site sécurisé où un officier de sécurité inspecte chaque octet qui franchit la coupure sur une clé USB. Si vous diffusez du logiciel sous licence vers ces environnements, « notre licence appelle la maison » est rédhibitoire d’emblée. La bonne nouvelle, c’est que Keyright auto-hébergé a été conçu précisément pour cela : rien sur son chemin d’exécution n’a besoin d’internet. Cet article est le mode d’emploi concret — ce que « isolé » signifie pour chaque pièce, comment installer et renouveler l’auto-licence sous forme de fichier, comment arrêter la seule chose qui sortirait, et comment la licence à l’usage fonctionne à travers la coupure.

À retenir : Keyright auto-hébergé n’a besoin d’aucun internet sortant à l’exécution. Il vérifie sa propre auto-licence hors ligne contre la clé publique embarquée de Delta1 (sans appel maison, fail-closed en cas d’altération), les applications de vos clients valident hors ligne entre les activations, et pour la licence à l’usage vous déplacez des blocs de crédit isolés signés par fichier. L’exploitation hors ligne de base fonctionne sur Standard et Pro ; les blocs de crédit isolés sont une fonction Enterprise.

Ce que « isolé » (air-gapped) signifie pour les trois parties

Il y a trois pièces à considérer, et chacune est hors ligne de manière indépendante.

L’instance Keyright. C’est l’image ghcr.io/delta1-labs/keyright — un service ASP.NET Core sans état sur le port 8080, sans base de données à l’intérieur. Au démarrage et à chaque balayage, elle contrôle sa propre licence, et ce contrôle est de la pure cryptographie locale contre une clé publique cuite dans la build. Aucun appel à un serveur de licences Delta1, aucune poignée de main d’activation, aucune télémétrie qui conditionne l’exécution. Une fois l’image et la clé à l’intérieur de votre réseau, l’instance n’a jamais besoin de ressortir.

Votre PostgreSQL. Tout l’état — licences, activations, sièges, soldes de crédit et leur grand livre, le journal d’audit, vos clés de signature chiffrées au repos — vit dans une base de données que vous exploitez, pointée avec la chaîne de connexion KEYRIGHT_DB. C’est un Postgres interne au réseau, sur votre propre infrastructure. Aucun magasin de données géré par nos soins n’intervient ; les données ne quittent jamais votre périmètre.

Les applications de vos clients. Comme expliqué dans la validation de licences hors ligne expliquée, une licence signée se vérifie localement contre la clé publique que vous embarquez au moment de la compilation, et une activation en ligne renvoie un bail signé de courte durée que l’application met en cache et revérifie hors ligne. Vos clients valident donc hors ligne entre les activations — et dans une flotte totalement déconnectée, vous émettez des fichiers hors ligne signés et évitez entièrement l’aller-retour d’activation, exactement comme l’expose la licence pour les environnements isolés.

Mis bout à bout : l’instance s’auto-licencie hors ligne, elle ne parle qu’à une base de données que vous hébergez, et les applications de vos clients n’ont pas besoin de la joindre pour continuer à fonctionner. Rien sur ce chemin ne franchit la coupure.

L’instance se licencie elle-même hors ligne, et échoue vers l’état bloqué

Keyright se licencie avec une licence hors ligne Keyright ordinaire, et votre instance la vérifie hors ligne contre la clé publique embarquée de Delta1 — sans appel maison. Cette même asymétrie qui protège vos clients protège votre déploiement : la clé publique peut vérifier l’auto-licence signée mais ne peut jamais en forger une, le contrôle est donc du calcul local, et altérer un champ quelconque casse la signature.

C’est fail-closed. Sans clé, avec une clé invalide, un essai expiré ou une licence payante au-delà de sa fenêtre de grâce, l’instance est bloquée (gated) : chaque requête client renvoie 402. Une poignée de points de terminaison reste joignable pour que vous puissiez toujours diagnostiquer l’arrêt sans internet — /health, /health/ready, /admin/self-license, /admin/self-diagnostics, /branding et le tableau de bord — mais l’exécution est coupée tant qu’une clé valide n’est pas en place. Dans un réseau isolé, cela signifie que la seule chose à ne pas rater, c’est la clé : traitez-la avec le même soin que vous accordez à la démarche de sauvegarde et restauration de votre base de données.

Installer et renouveler l’auto-licence sous forme de fichier

Voici le point qui déroute ceux qui attendent un téléversement web : il n’y a pas de point de terminaison « téléverser la licence ». Vous fournissez la clé par la configuration et vous (re)démarrez. C’est un atout dans un réseau isolé — la clé arrive comme tout le reste, sous forme de fichier sur votre canal de transfert approuvé.

Deux façons de la fournir :

• Sous forme de fichier (le choix par défaut en isolé) : réglez KEYRIGHT_SELF_LICENSE_FILE sur un chemin à l’intérieur du conteneur et montez-y le JSON de la licence. Sur Kubernetes, c’est un Secret via --set-file secrets.selfLicense=license.json.
• En ligne (inline) : réglez KEYRIGHT_SELF_LICENSE sur le JSON de la licence en une seule ligne (compactez-le si votre copie comporte des sauts de ligne) — le plus simple pour un hôte Compose unique.

Un renouvellement ou un changement d’édition est le même geste : remplacer le fichier et redémarrer. Pas de redéploiement, pas de migration, aucun point de terminaison à appeler. Vérifiez ensuite la prise en compte :

curl -H "X-Admin-Token: $KEYRIGHT_ADMIN_TOKEN" http://localhost:8080/admin/self-license

/admin/self-license indique votre edition, isTrial, phase (active / expiring / grace / gated), daysUntilExpiry et si l’exécution est bloquée — et c’est l’un des rares points de terminaison qui répondent même lorsque l’instance est bloquée. Branchez son décompte d’expiration sur votre propre supervision, car dans un réseau déconnecté aucun courriel de renouvellement ne viendra vous trouver ; l’instance avertit dans le tableau de bord, mais vous devriez surveiller la phase vous-même. Le cycle de vie complet de l’état de la clé figure dans la référence de licence.

Désactivez le seul appel sortant : GeoIP

Le tableau de bord possède une recherche optionnelle de localisation de machine qui résout les IP d’activation vers une localisation approximative. C’est la seule chose, dans une configuration d’usine, qui tenterait une requête sortante. Désactivez-la pour une exécution isolée en la laissant vide :

KEYRIGHT_GEOIP_URL=

Avec ce réglage non défini, le tableau de bord omet simplement la colonne de localisation et ne tente rien vers l’extérieur. Tout le reste — activation, validation, sièges, crédits, le portail — était déjà local.

Importer l’image dans votre registre privé

L’image réside sur un registre public que vous ne pouvez pas joindre depuis l’intérieur de la coupure : déplacez-la donc comme n’importe quel artefact — téléchargez-la sur un hôte connecté, exportez-la et chargez-la de l’autre côté.

# Sur un hôte connecté :
docker save ghcr.io/delta1-labs/keyright:2.2.2 -o keyright-2.2.2.tar
# (sauvegardez aussi postgres:16 si vous utilisez la BD intégrée pour une petite installation)

# Transportez l'archive par votre canal approuvé, puis à l'intérieur du réseau :
docker load -i keyright-2.2.2.tar

Réétiquetez et poussez vers votre propre registre interne au réseau si vous en exploitez un, et épinglez la version (image.tag=2.2.2 sur Helm) pour des déploiements reproductibles. Pointez KEYRIGHT_DB vers votre PostgreSQL interne au réseau — une base de données sur votre propre infrastructure, TLS exigé — et l’instance crée et migre son schéma au premier démarrage, sans SQL à exécuter à la main. Les mises à jour sont le même import-puis-redémarrage, les migrations s’appliquant automatiquement au démarrage.

Licence à l’usage à travers la coupure : les blocs de crédit isolés

Si vous vendez au crédit ou à l’usage, la connectivité est généralement la façon dont vous réconciliez la consommation — et c’est précisément ce qu’un réseau isolé ne peut pas fournir. Les blocs de crédit isolés résolvent cela avec la même confiance par signature qu’une licence. Vous émettez un bloc signé de crédit pour une machine déconnectée, il y est consommé hors ligne, et vous réconciliez l’usage lorsque le bloc revient franchir la coupure. Comme chaque bloc est signé par la clé de votre instance et vérifié localement, aucune étape n’a besoin du réseau — la licence au crédit fonctionne entièrement en déplaçant des fichiers dans un sens puis dans l’autre.

Les blocs de crédit isolés sont une fonction Enterprise. Le reste de cet article — vérification de l’auto-licence, validation hors ligne du client, exécution sans trafic sortant — fonctionne tout aussi bien sur Standard et Pro ; seule la capacité des blocs de crédit est réservée à Enterprise.

Quelle édition, et où cela s’inscrit

Keyright auto-hébergé est facturé par déploiement entre Standard, Pro et Enterprise. L’exécution totalement hors ligne décrite ici n’est pas une fonction d’édition — c’est le fonctionnement du produit à tous les niveaux. Standard couvre un seul nœud de production ; Pro et Enterprise couvrent jusqu’à trois (utile si votre réseau isolé veut aussi de la haute disponibilité) ; et Enterprise ajoute le SSO, la marque en marque blanche et les blocs de crédit isolés ci-dessus. Consultez les tarifs pour les chiffres actuels.

Comme Keyright est un seul produit dans les deux modes de déploiement, rien dans votre intégration ne change entre une évaluation sur portable et une enclave de production scellée. Quand vous serez prêt à en dresser une derrière la coupure, le guide d’exploitation contient la liste de vérification isolée, les commandes de déplacement d’image et la discipline de sauvegarde qui transforment une instance en marche en une instance sur laquelle vous pouvez compter sans aucun moyen d’appeler l’extérieur.