Всички процеси в контейнера ще се изпълняват като root потребител, освен ако не го посочите по специален начин. Това изглежда много удобно, защото този потребител няма ограничения. Ето защо работата като root е грешна от гледна точка на сигурността. Ако никой с здрав ум не работи на локалния компютър с root права, тогава много стартират процеси под root в контейнери.
Винаги има бъгове, които ще позволят на зловреден софтуер да избяга от контейнера и да влезе в хост компютъра. Ако приемем най-лошото, трябва да гарантираме, че процесите вътре в контейнера се изпълняват от потребител, който няма никакви права на хост машината.
Създаване на потребител
Създаването на потребител в контейнер не се различава от създаването му в Linux дистрибуции. Въпреки това, командите може да варират за различните базови изображения.
За дистрибуции, базирани на debian, трябва да добавите следното към Dockerfile:
RUN groupadd --gid 2000 node
&& useradd --uid 2000 --gid node --shell /bin/bash --create-home node
За алпийски:
RUN addgroup -g 2000 node
&& adduser -u 2000 -G node -s /bin/sh -D node
Изпълнение на процеси от потребителя
За да стартирате всички следващи процеси като потребител с UID 2000, изпълнете:
USER 2000
За да стартирате всички последващи процеси като потребител на възел, изпълнете:
USER node
Повече в
Монтажни обеми
Когато монтирате томове в контейнер, дайте на потребителя възможност да чете и/или записва файлове. За да направите това, UID (GID) на потребителя в контейнера и потребителя извън контейнера, който има съответните разрешения за достъп до файла, трябва да съвпадат. В този случай потребителските имена нямат значение.
Често на компютър с Linux UID и GID на потребителя са равни на 1000. Тези идентификатори се присвояват на първия потребител на компютъра.
Намирането на вашите идентификатори е лесно:
id
Ще получите изчерпателна информация за вашия потребител.
Заменете 2000 от примерите с вашия идентификатор и всичко ще бъде наред.
Присвояване на UID и GID на потребител
Ако потребителят е създаден преди това, но трябва да промените идентификаторите, можете да го направите по следния начин:
RUN usermod -u 1000 node
&& groupmod -g 1000 node
Ако използвате алпийското базово изображение, трябва да инсталирате пакета shadow:
RUN apk add —no-cache shadow
Предаване на потребителския идентификатор вътре в контейнера при изграждане на изображението
Ако вашият идентификатор и идентификаторите на всички хора, които работят по проекта, съвпадат, просто посочете този идентификатор в Dockerfile. Често обаче потребителските идентификатори не съвпадат.
Как да постигнете това, което искате, не е веднага ясно. За мен това беше най-трудното нещо в процеса на овладяване на Docker. Много потребители на докери не осъзнават, че има различни етапи в живота на едно изображение. Първо, изображението се сглобява с помощта на Dockerfile. Когато стартирате контейнер от изображение, Dockerfile вече не се използва.
Създаването на потребител трябва да се извърши, когато изображението е изградено. Същото важи и за определяне на потребителя, под който се стартират процеси. Това означава, че трябва по някакъв начин да предадем UID (GID) вътре в контейнера.
Директивите се използват за използване на външни променливи в Dockerfile
Докер файл
ARG UID=1000
ARG GID=1000
ENV UID=${UID}
ENV GID=${GID}
RUN usermod -u $UID node
&& groupmod -g $GID node
Можете да предавате аргументи чрез docker-compose по този начин:
докер-ново съобщение
build:
context: ./src/backend
args:
UID: 1000
GID: 1000
PS За да овладеете всички тънкости на Docker, не е достатъчно да прочетете документацията или статиите. Трябва да практикувате много, трябва да усетите Docker.
Източник: www.habr.com