При настройке процесса контейнера для запуска в Kubernetes от имени пользователя без полномочий root должен ли пользователь существовать на хосте? Если да, то какой идентификатор пользователя следует использовать, когда узел хоста управляется Google Kubernetes Engine?
В рекомендациях Google Cloud по работе с контейнерами говорится следующее:
(...) рекомендуется не запускать процессы как root внутри контейнеров. Вы можете принудительно применить это поведение в Kubernetes с помощью PodSecurityPolicy. При создании модуля в Kubernetes используйте параметр runAsUser, чтобы указать пользователя Linux, который запускает процесс.
Я хотел бы следовать этой практике.
Как указано в Лучшей практике документ, вы можете запустить образ контейнера локально (или на узлах кластера GKE) со случайным пользователем:
docker run --user $ ((RANDOM + 1)) [ВАШ_КОНТЕЙНЕР]
Это означает, что пользователь может быть случайным; поэтому он не существует на хосте. Вам просто нужно убедиться, что это не рут.
Более того, вы можете проверить это документ и запустите команду, чтобы получить оболочку для работающего контейнера. После запуска «ps aux» вы увидите, что некоторые процессы выполняются под доступными пользователями. Им может быть любой случайный пользователь.
В настоящее время принятый ответ подразумевает, что вы можете просто установить любой случайный UID без полномочий root и быть в порядке. Я хочу кое-что прояснить для будущих читателей.
Во-первых, чтобы убедиться, что все находятся на одной странице, Kubernetes в настоящее время не поддерживает размещение имен пользователей в соответствии с Эта проблема. Это несмотря на то, что теперь это функция ядра Linux, а также Докер. Итак, в Kubernetes, когда вы указываете под или контейнер securityContext с runAsUser UID, этот UID будет использоваться как на хост-узле, так и внутри контейнера. Это подводит нас к вашему вопросу (а также моему перед исследованием): какой UID вам следует использовать?
Итак, во-первых, да, везде и все согласны, что он не должен быть root (UID 0). Но это не может быть полностью случайный UID. Если UID сталкивается с существующим пользователем, например, с разрешениями sudo без пароля, это фактически root. Однако это не единственный плохой случай, вы также, например, не хотите, чтобы UID конфликтовал, скажем, с вашим пользователем базы данных MySQL. Таким образом, вы хотите назначить UID, который либо а) не имеет уже назначенного пользователя, либо б) пользователю, специально созданному на хосте для этой цели.
В Google Kubernetes Engine, если вы работаете с образами ОС, оптимизированными для контейнеров, похоже, существует соглашение для значений UID:
Выберите идентификатор из диапазона [2000, 4999], чтобы избежать конфликтов с другими учетными записями пользователей.
[1] https://cloud.google.com/container-optimized-os/docs/how-to/create-configure-instance
При проверке одного из наших узлов GKE это кажется правильным, поскольку я вижу, что пользователям SSH назначаются UID, начиная с 5000. Итак, в нашем кластере GKE мы только что назначили UID / GID 2000 для наших контейнеров.