Назначить контекст безопасности в Google Kubernetes

Question

Мне было интересно, каков наилучший способ определения роли пользователя для назначения в контексте безопасности в Pod и контейнере?

Не рекомендуется предоставлять пользователя с правами root, и, как я знаю, если пользователь играет слишком мощную роль, то когда он записывает файл на том узла и в следующий раз, когда мы развертываем новый контейнер, вероятно, у нас недостаточно разрешение на удаление файла, записанного в контейнере, мощным пользователем.

В частности, в Google Kubernetes я хочу избежать сценария, описанного ниже, например, при развертывании приложения в среде докера: Когда A развертывает приложение, запустив docker: docker run ... если процесс внутри контейнера выполняется пользователем B, более мощным, чем A, то, вероятно, A не сможет удалить файл, написанный B. Не уверен, что этот случай может произойти в Google K8S

Через некоторое время я думаю, что упомянутый сценарий не происходит в K8S. K8S будет управлять ресурсами контейнера при повторном развертывании, обновляя pod с помощью своего внутреннего механизма

Answer 1

В этом случае, если контекст безопасности для модулей не установлен на «привилегированный», контейнеры не получат привилегии root. Если вы являетесь администратором кластера, вы можете использовать Pod Security Policy, чтобы ограничить использование привилегированных контейнеров.

В этом документе вы найдете 7 рабочих контейнеров Best Practices, которые также применимы для докеров. По сути, вы должны избегать привилегированных контейнеров, чтобы избежать описанного сценария.

Answer 2

Вы можете смешать Возможности Linux с контекстом безопасности в Pod и контейнере, чтобы обеспечить более детальную разбивку привилегий, традиционно связанных с суперпользователем (root или uid = 0). Некоторые из этих возможностей могут использоваться для повышения привилегий или для прорыва контейнера, и могут быть ограничены PodSecurityPolicy. Для получения более подробной информации о возможностях Linux см. abilities .

Сказал, что PodSecurityPolicy позволит вам контролировать чувствительные к безопасности аспекты спецификации модуля, такие как: выделение FSGroup, которая владеет томами модуля, идентификаторы пользователя и группы контейнера и, кроме того, возможности Linux для предоставления более точных привилегий.

Для пользователей и групп , поскольку RunAsUser (MustRunAs) и RunAsGroup (MustRunAs) требует указывать хотя бы один диапазон, тогда у вас должно быть достаточное разрешение для удаления файла, записанного в контейнере, для любого определенного диапазона в RunAsUser или RunAsGroup. Я бы рекомендовал вам использовать MustRunAsNonRoot для пользователей и групп, чтобы избежать описанного сценария.

В соответствии с рекомендациями, если в кластере Kubernetes запущено несколько приложений, каждое приложение должно запускаться в собственном пространстве имен, чтобы избежать конфликтов имен, и для каждого приложения должны использоваться разные uid и метка MCS. Кроме того, предлагается, чтобы все контейнеры запускались как один пользователь без полномочий root. Описанные случаи использования здесь предоставляют некоторые из этих соображений при использовании контекстов безопасности для узлов и контейнеров.

В этой ссылке вы можете найти более подробную информацию о Pod Security Policy