Comment ajouter un utilisateur lorsque j'utilise Alpine comme image de base ?

Question

J'utilise alpine (ou une image basée sur Alpine) comme image de base dans mon Dockerfile. Quelles instructions dois-je ajouter pour créer un utilisateur ?

En fin de compte, j'utiliserai cet utilisateur pour exécuter l'application que je placerai dans le conteneur, de sorte que l'utilisateur racine ne le fasse pas.

Answer 1

Alpine utilise la commande adduser y addgroup pour la création d'utilisateurs et de groupes (plutôt que useradd y usergroup ).

FROM alpine:latest

# Create a group and user
RUN addgroup -S appgroup && adduser -S appuser -G appgroup

# Tell docker that all future commands should run as the appuser user
USER appuser

Les drapeaux pour adduser sont :

Usage: adduser \[OPTIONS\] USER \[GROUP\]

Create new user, or add USER to GROUP

        -h DIR          Home directory
        -g GECOS        GECOS field
        -s SHELL        Login shell
        -G GRP          Group
        -S              Create a system user
        -D              Don't assign a password
        -H              Don't create home directory
        -u UID          User id
        -k SKEL         Skeleton directory (/etc/skel)

Ajouter de nouveaux documents officiels pour les utilisateurs

Answer 2

Les commandes sont adduser y addgroup .

Voici un modèle pour Docker que vous pouvez utiliser dans les environnements busybox (alpine) ainsi que dans les environnements basés sur Debian (Ubuntu, etc.) :

ENV USER=docker
ENV UID=12345
ENV GID=23456

RUN adduser \
    --disabled-password \
    --gecos "" \
    --home "$(pwd)" \
    --ingroup "$USER" \
    --no-create-home \
    --uid "$UID" \
    "$USER"

Notez ce qui suit :

• --disabled-password empêche la demande d'un mot de passe
• --gecos "" contourne l'invite pour "Nom complet" etc. sur les systèmes basés sur Debian
• --home "$(pwd)" définit le domicile de l'utilisateur comme étant le répertoire WORKDIR. Vous ne voulez peut-être pas de ça.
• --no-create-home empêche la copie dans le répertoire des déchets provenant de /etc/skel

La description de l'utilisation de ces applications est la suivante manque les longs drapeaux présent dans le code pour adduser y addgroup .

Les drapeaux longs suivants devraient fonctionner aussi bien dans alpine que dans debian-derivatives :

adduser

BusyBox v1.28.4 (2018-05-30 10:45:57 UTC) multi-call binary.

Usage: adduser [OPTIONS] USER [GROUP]

Create new user, or add USER to GROUP

        --home DIR           Home directory
        --gecos GECOS        GECOS field
        --shell SHELL        Login shell
        --ingroup GRP        Group (by name)
        --system             Create a system user
        --disabled-password  Don't assign a password
        --no-create-home     Don't create home directory
        --uid UID            User id

Une chose à noter est que si --ingroup n'est pas défini, le GID est attribué pour correspondre à l'UID. Si le GID correspondant à l'UID fourni existe déjà, adduser échouera.

addgroup

BusyBox v1.28.4 (2018-05-30 10:45:57 UTC) multi-call binary.

Usage: addgroup [-g GID] [-S] [USER] GROUP

Add a group or add a user to a group

        --gid GID  Group id
        --system   Create a system group

J'ai découvert tout ceci en essayant d'écrire ma propre alternative au fixuid pour exécuter les conteneurs en tant qu'UID/GID des hôtes.

Mon aide de point d'entrée script peut être trouvé sur GitHub.

L'intention est de faire précéder ce script comme premier argument à ENTRYPOINT ce qui devrait permettre à Docker de déduire l'UID et le GID d'un montage de liaison pertinent.

Une variable d'environnement "TEMPLATE" peut être nécessaire pour déterminer d'où les permissions doivent être déduites.

(Au moment où j'écris ces lignes, je n'ai pas de documentation pour mon script. C'est toujours sur la todo list !!)