Identité immuable
Les résumés SHA-256 garantissent que l'artefact promu est identique en octets à l'artefact analysé et approuvé.
Digest-First Versioning
Identité de version immuable par hachage de contenu
Une version est un ensemble de OCI résumés résolus au moment de la création. Les balises sont des alias lisibles par l'homme ; les résumés sont une vérité cryptographique.
Pourquoi Digest-First ?
Les balises mutables créent une ambiguïté. La même balise peut pointer vers un contenu différent au fil du temps. La gestion des versions Digest-first élimine cette incertitude.
Détection de falsification
Toute modification de l'artefact modifie son résumé. Inadéquation du temps d'extraction = échec du déploiement. La falsification est impossible à dissimuler.
Piste d'audit
Sachez exactement quel artefact a été déployé, où, quand et pourquoi, grâce à une preuve cryptographique reliant l'analyse, l'approbation et le déploiement.
Retour en arrière significatif
La restauration revient aux résumés exacts connus, et non à « quels que soient les derniers points à ce jour ». Mêmes octets, garantis.
Structure de la version
Une version dans Stella regroupe plusieurs composants, chacun identifié par son résumé OCI. La version elle-même a une version sémantique pour une lisibilité humaine.
Exemple de version groupée
Release : myapp-v2.3.1
Composants :
api: sha256:abc123...
worker: sha256:def456...
frontend: sha256:789ghi...
Créez et gérez des versions à partir du CLI
$ stella release create --name myapp-v2.3.1 --components api:v2.3.1,worker:v2.3.1
stella release list --environment production\nstella release show myapp-v2.3.1 --componentsRésolution de type tag-to-digest
Lorsque vous créez une version, Stella résout immédiatement toutes les balises dans leurs résumés actuels. À partir de ce moment, la version est immuable.
- Les balises telles que :v2.3.1 sont résolues en sha256:abc123... au moment de la création
- Si quelqu'un envoie une nouvelle image vers la même balise, votre libération est non affecté
- Les requêtes de registre utilisent toujours la syntaxe @sha256:digest — pas de re-résolution de balise
Garantie d'immuabilité
Une fois qu'une version est créée, son ensemble de résumés ne peut pas changer. Les mêmes octets seront déployés dans chaque environnement, à chaque fois.
Artefacts générés
Chaque déploiement génère des artefacts immuables qui permettent la reproductibilité, l'audit et la restauration.
compose.stella.lock.yml
Docker Compose avec toutes les références d'images épinglées à des résumés spécifiques. Comprend des étiquettes de métadonnées Stella pour la traçabilité.
image: registry.example.com/myapp/api@sha256:abc123...
labels:
stella.release.id: "rel-uuid"
stella.digest: "sha256:abc123..."
stella.version.json
Fichier de métadonnées JSON placé sur les cibles de déploiement indiquant la version actuelle, les composants, la stratégie de déploiement et la version précédente pour la restauration.
"release": { "name": "myapp-v2.3.1" }
"deployment": { "strategy": "rolling" }
"previous": { "digest": "sha256:789..." }
"signature": "base64-encoded-signature"
Liaison de preuves
Chaque version lie les preuves de sécurité aux résumés exacts en cours de déploiement. Les preuves voyagent de la version à la promotion.
| Champ de preuves | Contenu |
|---|---|
| sbomDigest | SHA-256 du SBOM généré pour ce résumé |
| scanVerdict | Résultat réussite/échec de la politique évaluation avec des références de preuves |
| reachabilityProof | URI CAS du graphique d'accessibilité signé pour ce résumé |
| policyHash | Hash de la version de la stratégie utilisée pour l'évaluation |
Replay déterministe : avec la même version et la même politique hachage, la réévaluation produit des verdicts identiques. Les auditeurs peuvent vérifier les décisions des mois plus tard.
Prêt pour une identité de version immuable ?
Installez Stella Ops et démarrez la gestion des versions par hachage de contenu avec liaison de preuves complètes.