Usuarios locales en la imagen

Los registros de usuario viven en os.users. Crean cuentas dentro de la imagen; no tienen relación con cuentas del sitio web OpenFactory ni roles de organización.

Forma canónica

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

Los campos admitidos incluyen username, password opcional, full_name, groups, shell y un level específico del destino usado por imágenes Elster/Vyatta. Ejemplos antiguos con home o comment no coinciden con el modelo canónico y pueden ignorarse.

Los nombres de usuario y grupo están restringidos a caracteres seguros de cuenta Linux y longitud. El shell debe ser una ruta absoluta sin espacios ni metacaracteres de shell.

Comportamiento de contraseña

Dejar password sin definir crea una cuenta bloqueada por contraseña. Es el estado preferido de receta para SSH solo con clave, inscripción en first-boot o integración de identidad en tiempo de despliegue.

Si se incluye contraseña en texto plano, pasa a ser entrada sensible de compilación y puede exponerse mediante recetas guardadas, logs o exportaciones. No uses una credencial real de producción en una receta. Las recetas por teléfono deben recoger credenciales en el dispositivo en lugar de hornearlas en la imagen.

Antes de deshabilitar autenticación SSH por contraseña, confirma que hay una clave pública aprobada u otro método de acceso presente y probado. Si no, una imagen endurecida correctamente puede quedar inaccesible.

Grupos y privilegio

• sudo y wheel pueden conceder autoridad administrativa según la distribución.
• docker suele conceder control equivalente a root mediante el socket del daemon.
• kvm concede acceso a dispositivos de virtualización donde existan.
• adm puede exponer logs sensibles.

Trata estos como grupos privilegiados y concede solo lo que la cuenta necesita. Los nombres de grupo específicos de distribución no son portables.

Cuentas de servicio

Para una cuenta de servicio no interactiva, selecciona un shell sin login disponible en el destino y omite grupos administrativos. Confirma que el generador y la unidad de servicio conservan la identidad prevista; un valor por defecto de receta puede añadir sudo si se omite groups, así que proporciona una lista de grupos vacía explícita cuando corresponda.

Verificación

Prueba las propiedades exactas que importan:

• la cuenta existe con el rango de UID esperado;
• grupos primarios y suplementarios son correctos;
• shell de login y estado de bloqueo por contraseña son correctos;
• home y propiedad de archivos, si se generan en otro sitio, son correctos;
• sudo y acceso a servicios no autorizados se deniegan; y
• la ruta de login o inscripción aprobada tiene éxito.

No infieras mínimo privilegio solo por la creación de cuenta.