Feature di build

Una feature è un modulo di build nominato. La sua voce di registro può dichiarare pacchetti per una o più famiglie di distribuzione e può includere anche hook di build, alias, metadati capacità e asserzioni guest.

Aggiungere una feature esprime intento. Da sola non prova che ogni pacchetto fosse disponibile, ogni hook sia stato eseguito o il comportamento risultante funzioni sull’immagine target. Validazione ricetta, completamento build e verifica guest sono gate separati.

Trova il set feature corrente

Usa il selettore feature o l’API catalogo feature nella release OpenFactory deployata. Quell’output è autoritativo per la versione in esecuzione. Elenchi statici invecchiano in fretta, e alcune voci registro sono nascoste perché supportano fixture interne o integrazioni incomplete.

Prima di scegliere una feature, controlla:

• se è visibile e abilitata per il tuo account;
• se dichiara pacchetti per la famiglia distribuzione della ricetta;
• se le sue sorgenti esterne sono pin e recuperabili;
• se ha asserzioni che provano il comportamento che ti serve; e
• se entra in conflitto con un altro modulo richiesto.

Categorie rappresentative

Il registro include attualmente moduli in categorie come:

Gli esempi non sono una matrice di compatibilità. Un nome feature può esistere mentre un’implementazione per una distribuzione particolare resta parziale.

Feature, pacchetto e servizio sono diversi

• os.features seleziona moduli build registrati.
• os.packages chiede al package manager nativo pacchetti specifici.
• os.services fornisce intento di abilitazione e configurazione nominati.

Ad esempio:

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

Una config servizio valida può comunque contenere una chiave che il generatore non consuma. Ispeziona la ricetta normalizzata e testa il guest generato.

Etichette sicurezza e conformità

security-hardening installa e configura una baseline di hardening generale. Non è sinonimo di un profilo CIS. Il hardening_level della ricetta è un’etichetta di configurazione interpretata da generatori specifici per target; non è una certificazione né una mappatura universale a CIS Level 1 o Level 2.

La feature cis-benchmarks ha un percorso remediation Level 1 Ubuntu 24.04 più specifico. Altre basi non ricevono lo stesso ruolo. Vedi Evidenza benchmark CIS per il confine esatto.

Allo stesso modo, abilitare una feature nominata per GxP, HIPAA, SOC 2, PCI DSS, NIST o DISA non stabilisce conformità organizzativa. Può aggiungere pacchetti, configurazione e test che contribuiscono evidenza a una valutazione governata separatamente.

Combinare feature in sicurezza

1. Inizia con il set più piccolo che esprime il comportamento richiesto.
2. Valida la ricetta e ispeziona l’output normalizzato per campi scartati o inferiti.
3. Rivedi il piano pacchetti e hook espanso.
4. Builda una volta e segui il suo ID build durabile.
5. Esegui asserzioni specifiche per feature in un guest avviato.
6. Registra fallimenti ed eccezioni intenzionali esplicitamente.
7. Aggiungi un’altra feature solo dopo aver capito la baseline corrente.

Per la forma JSON canonica, vedi Schema ricetta.