Utilisateurs locaux à l’image

Les enregistrements utilisateur vivent dans os.users. Ils créent des comptes dans l’image ; ils sont sans lien avec les comptes site OpenFactory ou les rôles d’organisation.

Forme canonique


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

Les champs supportés incluent username, password optionnel, full_name, groups, shell et un level propre à la cible utilisé par les images Elster/Vyatta. D’anciens exemples contenant home ou comment ne correspondent pas au modèle canonique et peuvent être ignorés.

Les noms d’utilisateur et de groupe sont limités à des caractères de compte Linux sûrs et à une longueur. Le shell doit être un chemin absolu sans espaces ni métacaractères shell.

Comportement des mots de passe

Laisser password non défini crée un compte verrouillé par mot de passe. C’est l’état de recette préféré pour SSH par clé seule, enrollment first-boot ou intégration d’identité au déploiement.

Si un mot de passe en clair est inclus, il devient une entrée de build sensible et peut être exposé via recettes enregistrées, journaux ou exports. N’utilisez pas un identifiant de production réel dans une recette. Les recettes téléphone doivent collecter les identifiants sur l’appareil plutôt que de les intégrer dans l’image.

Avant de désactiver l’authentification SSH par mot de passe, confirmez qu’une clé publique approuvée ou un autre moyen d’accès est présent et testé. Sinon une image correctement durcie peut être inaccessible.

Groupes et privilèges

sudo et wheel peuvent accorder une autorité administrative selon la distribution.
docker accorde couramment un contrôle équivalent root via le socket du démon.
kvm accorde l’accès aux périphériques de virtualisation lorsqu’ils sont présents.
adm peut exposer des journaux sensibles.

Traitez ceux-ci comme des groupes privilégiés et n’accordez que ce dont le compte a besoin. Les noms de groupes propres à une distribution ne sont pas portables.

Comptes de service

Pour un compte de service non interactif, sélectionnez un shell no-login disponible sur la cible et omettez les groupes administratifs. Confirmez que le générateur et l’unité de service préservent l’identité voulue ; un défaut de recette peut ajouter sudo si groups est omis, donc fournissez une liste de groupes vide explicite le cas échéant.

Vérification

Testez les propriétés exactes qui comptent :

le compte existe avec la plage UID attendue ;
groupes principal et supplémentaires corrects ;
shell de connexion et état de verrouillage par mot de passe corrects ;
home et propriété de fichiers, s’ils sont générés ailleurs, corrects ;
sudo et accès service non autorisés refusés ; et
le chemin de connexion ou d’enrollment approuvé réussit.

N’inférez pas le moindre privilège depuis la seule création de compte.