Image-lokala användare
Användarposter finns i os.users. De skapar konton i imagen; de har inget samband med OpenFactory-webbkonton eller organisationsroller.
Kanonisk form
{
"os": {
"users": [
{
"username": "deploy",
"full_name": "Deployment Operator",
"groups": ["sudo"],
"shell": "/bin/bash"
}
]
}
}Fält som stöds är username, valfritt password, full_name, groups, shell, och ett målspecifikt level som används av Elster/Vyatta-images. Äldre exempel med home eller comment matchar inte den kanoniska modellen och kan ignoreras.
Användar- och gruppnamn begränsas till säkra Linux-kontotecken och längd. Shell måste vara en absolut sökväg utan blanksteg eller shell-metatecken.
Lösenordsbeteende
Om password lämnas oinställt skapas ett lösenordslåst konto. Det är önskat recepttillstånd för SSH enbart med nyckel, first-boot enrollment eller identitetsintegration vid deployment.
Om ett klartextlösenord ingår blir det känslig build-input och kan exponeras via sparade recept, loggar eller export. Använd inte riktiga produktionsuppgifter i ett recept. Phone-recept ska samla in credentials på enheten i stället för att baka in dem i imagen.
Innan SSH-lösenordsautentisering stängs av, bekräfta att en godkänd public key eller annan åtkomstmetod finns och är testad. Annars kan en korrekt härdad image bli otillgänglig.
Grupper och behörighet
sudoochwheelkan ge administrativ behörighet beroende på distribution.dockerger ofta root-ekvivalent kontroll via daemon-socketen.kvmger åtkomst till virtualiseringsenheter där sådana finns.admkan exponera känsliga loggar.
Behandla dessa som privilegierade grupper och ge bara det kontot behöver. Distributionsspecifika gruppnamn är inte portabla.
Tjänstekonton
För ett icke-interaktivt tjänstekonto, välj ett no-login shell som finns på målet och utelämna administrativa grupper. Bekräfta att generator och service unit behåller avsedd identitet; ett receptstandardvärde kan lägga till sudo om groups utelämnas, så ange en explicit tom grupplista där det passar.
Verifiering
Testa exakt de egenskaper som spelar roll:
- kontot finns med förväntat UID-intervall;
- primära och kompletterande grupper stämmer;
- inloggningsshell och lösenordslåsstatus stämmer;
- hem och filägande, om de genereras någon annanstans, stämmer;
- obehörig sudo och tjänsteåtkomst nekas; och
- den godkända inloggnings- eller enrollment-vägen lyckas.
Dra inte slutsatsen least privilege enbart från att kontot skapades.