[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"question-bezopasnost-konteynerov-kak-zapustit-konteyner-ne-ot-polzovatelya-root":3},{"id":4,"slug":5,"topicId":6,"topicSlug":7,"topicName":8,"topicEmoji":9,"question":10,"answer":11,"codeLang":12,"codeSrc":12,"important":12,"commonMistakes":12,"modernUsage":12,"difficulty":13,"tags":14,"related":20,"progress":21,"seo":22},309,"kak-zapustit-konteyner-ne-ot-polzovatelya-root",9,"bezopasnost-konteynerov","Безопасность контейнеров","🛡️","Как запустить контейнер не от пользователя root?","Запуск контейнера не от пользователя root -- это практика создания и использования непривилегированного пользователя (с UID отличным от 0) для выполнения процесса внутри контейнера, что предотвращает получение атакующим root-прав на хосте при побеге из контейнера.\n\n### Инструкция USER в Dockerfile\n\nОсновной способ -- создать непривилегированного пользователя и переключиться на него:\n\n\u003Cdetails>\n\u003Csummary>Пример Dockerfile с непривилегированным пользователем\u003C\u002Fsummary>\n\n```dockerfile\nFROM eclipse-temurin:21-jre-alpine\n\n# Создаём группу и пользователя\nRUN addgroup -S javaapp && adduser -S javaapp -G javaapp\n\n# Создаём директории и назначаем владельца\nRUN mkdir -p \u002Fapp\u002Flogs \u002Fapp\u002Fconfig && \\\n    chown -R javaapp:javaapp \u002Fapp\n\nWORKDIR \u002Fapp\n\n# Копируем артефакт\nCOPY --chown=javaapp:javaapp target\u002Fbanking-service.jar \u002Fapp\u002Fapp.jar\n\n# Переключаемся на непривилегированного пользователя\nUSER javaapp\n\nEXPOSE 8080\n\nENTRYPOINT [\"java\", \"-jar\", \"\u002Fapp\u002Fapp.jar\"]\n```\n\n\u003C\u002Fdetails>\n\n### Директива runAsNonRoot в Kubernetes\n\nKubernetes может принудительно запретить запуск контейнеров от root:\n\n\u003Cdetails>\n\u003Csummary>Пример Deployment с runAsNonRoot\u003C\u002Fsummary>\n\n```yaml\napiVersion: apps\u002Fv1\nkind: Deployment\nmetadata:\n  name: banking-service\nspec:\n  replicas: 3\n  selector:\n    matchLabels:\n      app: banking-service\n  template:\n    metadata:\n      labels:\n        app: banking-service\n    spec:\n      securityContext:\n        runAsNonRoot: true\n        fsGroup: 1000\n      containers:\n      - name: app\n        image: registry.bank.local\u002Fbanking-service:1.0.0\n        securityContext:\n          runAsUser: 1000\n          runAsGroup: 1000\n          allowPrivilegeEscalation: false\n```\n\n\u003C\u002Fdetails>\n\nЕсли в образе `USER` указан root, а в Kubernetes выставлен `runAsNonRoot: true`, кластер **откажется запустить** под и выдаст ошибку `CreateContainerConfigError`.\n\n### User namespace remapping в Docker daemon\n\nЭтот механизм сопоставляет UID 0 внутри контейнера с непривилегированным UID на хосте:\n\n```json\n\u002F\u002F \u002Fetc\u002Fdocker\u002Fdaemon.json\n{\n  \"userns-remap\": \"default\"\n}\n```\n\nДаже если процесс внутри контейнера работает как root (UID 0), на хосте он будет обычным пользователем (например, UID 100000). Это обеспечивает дополнительный уровень защиты при побеге из контейнера.\n\n### Типичные проблемы при запуске не от root\n\n| Проблема | Решение |\n|----------|---------|\n| Нет прав на запись в `\u002Fapp\u002Flogs` | `RUN mkdir \u002Fapp\u002Flogs && chown appuser:appgroup \u002Fapp\u002Flogs` |\n| Порт ниже 1024 (например, 80) | Использовать порт 8080+ или добавить `NET_BIND_SERVICE` capability |\n| Java не может создать временные файлы | Примонтировать `tmpfs` или `emptyDir` в `\u002Ftmp` |\n| Не удаётся подключиться к БД через unix-socket | Настроить права на сокет или использовать TCP |\n\n### Проверка текущего пользователя\n\n```bash\ndocker exec my-container whoami\ndocker exec my-container id\n# uid=1000(javaapp) gid=1000(javaapp) groups=1000(javaapp)\n```\n\n### Вывод\n\nЗапуск от непривилегированного пользователя -- первая и простейшая мера защиты контейнера. Комбинация инструкции `USER` в Dockerfile и `runAsNonRoot: true` в Kubernetes гарантирует, что процесс никогда не запустится от root, даже если кто-то случайно соберёт образ без `USER`.\n\n> **На собеседовании:** достаточно показать знание трёх уровней защиты: `USER` в Dockerfile, `runAsNonRoot` в Kubernetes, и user namespace remapping как дополнительный барьер. Также упомяните типичные проблемы -- это демонстрирует практический опыт.","","junior",[15,16,17,18,19],"root","USER","container-security","runAsNonRoot","docker",[],null,{"title":23,"description":24,"ogTitle":25,"ogDescription":26,"keywords":27,"schemaAnswer":33,"featuredSnippetReady":34},"Запуск контейнера не от root — USER, runAsNonRoot, userns-remap — Gymterview","Как запустить Docker-контейнер от непривилегированного пользователя: USER в Dockerfile, runAsNonRoot в Kubernetes, user namespace remapping. Типичные проблемы.","Запуск контейнера не от root — 3 уровня защиты","USER в Dockerfile, runAsNonRoot в Kubernetes и user namespace remapping. Решение типичных проблем: порты, права на запись, временные файлы.",[28,29,30,31,32],"контейнер не от root","USER Dockerfile","runAsNonRoot Kubernetes","userns-remap Docker","безопасность контейнера root","Три уровня защиты: 1) USER в Dockerfile — создать пользователя через adduser и переключиться на него. 2) runAsNonRoot: true в Kubernetes securityContext — Kubernetes откажется запускать под от root. 3) User namespace remapping в Docker daemon — UID 0 внутри контейнера сопоставляется с непривилегированным UID на хосте.",true]