Fonctionnalités de build

Une fonctionnalité est un module de build nommé. Son entrée de registre peut déclarer des paquets pour une ou plusieurs familles de distribution et inclure aussi des hooks de build, alias, métadonnées de capacité et assertions invité.

Ajouter une fonctionnalité exprime une intention. Cela ne prouve pas à lui seul que chaque paquet était disponible, que chaque hook a tourné ou que le comportement résultant fonctionne sur l’image cible. Validation de recette, achèvement du build et vérification invité sont des portes distinctes.

Trouver l’ensemble de fonctionnalités courant

Utilisez le sélecteur de fonctionnalités ou l’API catalogue de fonctionnalités dans la version OpenFactory déployée. Cette sortie fait autorité pour la version en cours. Les listes statiques deviennent vite obsolètes, et certaines entrées de registre sont masquées car elles supportent des fixtures internes ou des intégrations incomplètes.

Avant de choisir une fonctionnalité, vérifiez :

• si elle est visible et activée pour votre compte ;
• si elle déclare des paquets pour la famille de distribution de la recette ;
• si ses sources externes sont épinglées et récupérables ;
• si elle a des assertions qui prouvent le comportement dont vous avez besoin ; et
• si elle entre en conflit avec un autre module demandé.

Catégories représentatives

Le registre inclut actuellement des modules dans des catégories telles que :

Les exemples ne forment pas une matrice de compatibilité. Un nom de fonctionnalité peut exister alors qu’une implémentation particulière pour une distribution reste partielle.

Fonctionnalité, paquet et service diffèrent

• os.features sélectionne des modules de build enregistrés.
• os.packages demande au gestionnaire de paquets natif des paquets précis.
• os.services fournit une intention d’activation et de configuration nommée.

Par exemple :

{
  "os": {
    "features": ["ssh", "firewall"],
    "packages": ["curl", "jq"],
    "services": [
      {
        "name": "ssh",
        "enabled": true,
        "config": {
          "port": 22,
          "disable_password_auth": true
        }
      }
    ]
  }
}

Une config de service valide peut encore contenir une clé que le générateur ne consomme pas. Inspectez la recette normalisée et testez l’invité généré.

Libellés sécurité et conformité

security-hardening installe et configure une baseline de durcissement générale. Ce n’est pas synonyme d’un profil CIS. Le hardening_level de la recette est un libellé de configuration interprété par des générateurs propres à la cible ; ce n’est pas une certification ni un mapping universel vers CIS Level 1 ou Level 2.

La fonctionnalité cis-benchmarks a un chemin de remédiation Level 1 Ubuntu 24.04 plus spécifique. Les autres bases ne reçoivent pas le même rôle. Voir Preuves benchmark CIS pour la frontière exacte.

De même, activer une fonctionnalité nommée pour GxP, HIPAA, SOC 2, PCI DSS, NIST ou DISA n’établit pas la conformité organisationnelle. Elle peut ajouter paquets, configuration et tests qui contribuent à une évaluation gouvernée séparément.

Combiner les fonctionnalités en sécurité

1. Commencez par le plus petit ensemble qui exprime le comportement demandé.
2. Validez la recette et inspectez la sortie normalisée pour champs abandonnés ou inférés.
3. Relisez le plan étendu de paquets et hooks.
4. Construisez une fois et suivez son ID de build durable.
5. Exécutez des assertions propres à la fonctionnalité dans un invité démarré.
6. Enregistrez explicitement échecs et exceptions intentionnelles.
7. Ajoutez une autre fonctionnalité seulement après avoir compris la baseline courante.

Pour la forme JSON canonique, voir Schéma de recette.