Image-lokale User

User-Datensätze liegen in os.users. Sie legen Konten im Image an; sie haben nichts mit OpenFactory-Website-Konten oder Organisationsrollen zu tun.

Kanonische Form


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

Unterstützte Felder sind username, optionales password, full_name, groups, shell und ein zielspezifisches level für Elster/Vyatta-Images. Ältere Beispiele mit home oder comment passen nicht zum kanonischen Modell und können ignoriert werden.

User- und Gruppennamen sind auf sichere Linux-Account-Zeichen und Länge beschränkt. Die Shell muss ein absoluter Pfad ohne Whitespace oder Shell-Metazeichen sein.

Passwort-Verhalten

Ohne gesetztes password entsteht ein passwort-gesperrtes Konto. Das ist der bevorzugte Rezeptzustand für Key-only-SSH, First-Boot-Enrollment oder Deployment-Zeit-Identitätsintegration.

Enthält das Rezept ein Klartext-Passwort, wird es sensibler Build-Input und kann über gespeicherte Rezepte, Logs oder Exports sichtbar werden. Kein echtes Produktions-Credential im Rezept. Phone-Rezepte müssen Credentials auf dem Gerät erfassen statt ins Image zu backen.

Vor Deaktivierung der SSH-Passwort-Authentifizierung genehmigten Public Key oder andere Zugriffsmethode bestätigen und testen. Sonst kann ein korrekt gehärtetes Image unzugänglich sein.

Gruppen und Privilegien

sudo und wheel können je nach Distribution administrative Rechte gewähren.
docker gewährt häufig root-äquivalente Kontrolle über den Daemon-Socket.
kvm gewährt Zugriff auf Virtualisierungsgeräte, wo vorhanden.
adm kann sensible Logs offenlegen.

Behandeln Sie diese als privilegierte Gruppen und gewähren Sie nur, was das Konto braucht. Distributions-spezifische Gruppennamen sind nicht portabel.

Service Accounts

Für ein nicht interaktives Service-Konto eine No-Login-Shell wählen, die auf dem Ziel verfügbar ist, und administrative Gruppen weglassen. Bestätigen, dass Generator und Service-Unit die beabsichtigte Identität bewahren; ein Rezept-Default kann sudo hinzufügen, wenn groups fehlt, also bei Bedarf explizit leere Gruppenliste angeben.

Verifikation

Exakt die relevanten Eigenschaften testen:

Konto existiert im erwarteten UID-Bereich;
Primary- und Supplementary-Groups stimmen;
Login-Shell und Passwort-Lock-Zustand stimmen;
Home und Datei-Ownership, falls woanders erzeugt, stimmen;
unautorisiertes sudo und Service-Zugriff werden verweigert; und
genehmigter Login- oder Enrollment-Pfad gelingt.

Least Privilege nicht allein aus Kontoanlage ableiten.