Features de build

Um feature é um módulo de build nomeado. Sua entrada no registry pode declarar pacotes para uma ou mais famílias de distribuição e também incluir hooks de build, aliases, metadados de capacidade e asserções no guest.

Adicionar um feature expressa intenção. Por si só não prova que todo pacote estava disponível, todo hook rodou ou o comportamento resultante funciona na imagem alvo. Validação de receita, conclusão de build e verificação no guest são gates separados.

Encontre o conjunto atual de features

Use o seletor de features ou a API de catálogo de features na release OpenFactory implantada. Essa saída é autoritativa para a versão em execução. Listas estáticas envelhecem rápido, e algumas entradas do registry ficam ocultas porque suportam fixtures internos ou integrações incompletas.

Antes de escolher um feature, verifique:

• se está visível e habilitado para sua conta;
• se declara pacotes para a família de distribuição da receita;
• se suas fontes externas estão fixadas e recuperáveis;
• se tem asserções que provam o comportamento que você precisa; e
• se conflita com outro módulo solicitado.

Categorias representativas

O registry inclui atualmente módulos em categorias como:

Os exemplos não são matriz de compatibilidade. Um nome de feature pode existir enquanto a implementação para uma distribuição particular permanece parcial.

Feature, pacote e serviço são diferentes

• os.features seleciona módulos de build registrados.
• os.packages pede ao gerenciador de pacotes nativo pacotes específicos.
• os.services fornece intenção de enablement e configuração nomeada.

Por exemplo:

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

Uma config de serviço válida ainda pode conter chave que o gerador não consome. Inspecione a receita normalizada e teste o guest gerado.

Rótulos de segurança e conformidade

security-hardening instala e configura uma baseline geral de hardening. Não é sinônimo de perfil CIS. O hardening_level da receita é rótulo de configuração interpretado por geradores específicos de alvo; não é certificação nem mapeamento universal para CIS Level 1 ou Level 2.

O feature cis-benchmarks tem caminho de remediação Level 1 mais específico para Ubuntu 24.04. Outras bases não recebem o mesmo role. Veja Evidência de benchmark CIS para o limite exato.

Da mesma forma, habilitar um feature nomeado para GxP, HIPAA, SOC 2, PCI DSS, NIST ou DISA não estabelece conformidade organizacional. Pode adicionar pacotes, configuração e testes que contribuem evidência para uma avaliação governada separadamente.

Combinar features com segurança

1. Comece com o conjunto menor que expressa o comportamento solicitado.
2. Valide a receita e inspecione a saída normalizada por campos descartados ou inferidos.
3. Revise o plano expandido de pacotes e hooks.
4. Construa uma vez e siga seu ID de build durável.
5. Rode asserções específicas do feature em guest inicializado.
6. Registre falhas e exceções intencionais explicitamente.
7. Adicione outro feature só depois de entender a baseline atual.

Para o formato JSON canônico, veja Recipe Schema.