Usuários locais à imagem

Registros de usuário ficam em os.users. Criam contas dentro da imagem; não se relacionam a contas do site OpenFactory nem papéis de organização.

Formato canônico


{
  "os": {
    "users": [
      {
        "username": "deploy",
        "full_name": "Deployment Operator",
        "groups": ["sudo"],
        "shell": "/bin/bash"
      }
    ]
  }
}

Campos suportados incluem username, password opcional, full_name, groups, shell e level específico de alvo usado em imagens Elster/Vyatta. Exemplos antigos com home ou comment não correspondem ao modelo canônico e podem ser ignorados.

Nomes de usuário e grupo são restritos a caracteres seguros de conta Linux e comprimento. O shell deve ser caminho absoluto sem whitespace ou metacaracteres shell.

Comportamento de senha

Deixar password unset cria conta com senha bloqueada. Esse é o estado preferido na receita para SSH só com chave, enrollment no first boot ou integração de identidade na hora do deployment.

Se senha em texto claro for incluída, torna-se entrada sensível de build e pode aparecer em receitas salvas, logs ou exports. Não use credencial real de produção na receita. Receitas por telefone devem coletar credenciais no dispositivo em vez de embuti-las na imagem.

Antes de desabilitar autenticação SSH por senha, confirme que chave pública aprovada ou outro método de acesso está presente e testado. Caso contrário uma imagem corretamente hardened pode ficar inacessível.

Grupos e privilégio

sudo e wheel podem conceder autoridade administrativa dependendo da distribuição.
docker comumente concede controle equivalente a root via socket do daemon.
kvm concede acesso a dispositivos de virtualização onde presentes.
adm pode expor logs sensíveis.

Trate estes como grupos privilegiados e conceda só o que a conta precisa. Nomes de grupo específicos de distribuição não são portáveis.

Contas de serviço

Para conta de serviço não interativa, selecione shell no-login disponível no alvo e omita grupos administrativos. Confirme que gerador e unit de serviço preservam a identidade pretendida; default da receita pode adicionar sudo se groups for omitido, então forneça lista de grupos vazia explícita quando adequado.

Verificação

Teste as propriedades exatas que importam:

conta existe com faixa de UID esperada;
grupos primário e suplementares estão corretos;
shell de login e estado de bloqueio de senha estão corretos;
home e ownership de arquivo, se gerados em outro lugar, estão corretos;
sudo e acesso a serviço não autorizados são negados; e
caminho de login ou enrollment aprovado succeede.

Não infira menor privilégio só pela criação de conta.