Миграция с политик безопасности Pod: подробное руководство (Часть 1: Переход на PSA)

Введение

Поскольку Kubernetes продолжает развиваться как ведущая платформа оркестрации контейнеров, безопасность остается первостепенной задачей для организаций, развертывающих контейнерные приложения. Среди фундаментальных инструментов в арсенале безопасности Kubernetes политики безопасности Pod (PSP) когда-то играли ключевую роль. PSP позволял администраторам тщательно определять и обеспечивать соблюдение ограничений безопасности для модулей, гарантируя, что в кластере могут работать только контейнеры, соответствующие определенным стандартам безопасности.

Однако ситуация в области безопасности Kubernetes быстро развивается, и важно отметить, что PSP устарел, начиная с Kubernetes 1.25 (см. ссылку на примечания к срочному выпуску Kubernetes 1.25). Это изменение вызвано различными факторами, включая сложность управления и поддержки политик PSP, что часто приводит к операционным проблемам для пользователей.

В ответ на прекращение поддержки организации теперь ищут современные альтернативы PSP, которые не только отвечают требованиям безопасности, но и оптимизируют процесс защиты рабочих нагрузок в Kubernetes .

В этом подробном руководстве мы отправляемся в путь, чтобы разобраться в этом сдвиге в методах обеспечения безопасности Kubernetes, уделяя особое внимание переходу к Pod Security Admission (PSA). PSA — одна из самых надежных доступных альтернатив, и в этой статье она подробно рассматривается. Однако стоит отметить, что две другие альтернативы, Kyverno и OPA Gatekeeper, будут рассмотрены в отдельных статьях этой серии.

В этой статье вы найдете подробные инструкции по настройке и установке PSA, пошаговые руководства по переходу с PSP на PSA и точные команды для переноса существующих правил PSP в PSA. Кроме того, вы получите знания по оценке пространств имен на предмет готовности к миграции с помощью команд пробного запуска, адаптированных к PSA.

К концу этого руководства вы получите полное представление о сильных и слабых сторонах PSA, что позволит вам принять обоснованное решение на основе конкретных требований безопасности вашей организации и среды Kubernetes.

С помощью этого руководства вы сможете уверенно модернизировать свои методы обеспечения безопасности Kubernetes, гарантируя, что ваши рабочие нагрузки останутся защищенными, пока вы прощаетесь с эпохой политик безопасности Pod.

Вход в капсулу безопасности (PSA)

• PSA обеспечивает соблюдение стандартов безопасности Kubernetes: PSA гарантирует, что контейнеры соответствуют собственным стандартам безопасности Kubernetes, которые определены стандартами безопасности Pod. Эти стандарты делят политики безопасности на три отдельных профиля, каждый из которых имеет разный уровень ограничений:

  
  

  • Privileged : политика Privileged намеренно открыта и полностью ничем не ограничена. Обычно эта политика нацелена на рабочие нагрузки на уровне системы и инфраструктуры, управляемые доверенными пользователями. Характеризуется отсутствием ограничений. Хотя механизмы разрешения по умолчанию, такие как Gatekeeper, по своей сути могут быть привилегированными, для механизмов запрещения по умолчанию, таких как Pod Security Policy (PSP), политика Privileged должна деактивировать все ограничения.

  • Базовый уровень . Базовая политика предназначена для легкого внедрения обычными контейнерными рабочими нагрузками, предотвращая при этом известное повышение привилегий. Он предназначен для операторов приложений и разработчиков некритических приложений.

  • Restricted : политика Restricted направлена на строгое соблюдение лучших практик по усилению защиты модулей, хотя и за счет потенциальной совместимости. В первую очередь он нацелен на операторов и разработчиков критически важных для безопасности приложений, а также на пользователей с низким уровнем доверия. Полный список элементов управления, которые следует применять или запрещать в каждом профиле, можно найти в официальной документации.

    
    

• Отсутствие прямой передачи правил PSP. В отличие от некоторых других решений, PSA не предлагает простой метод непосредственной миграции или изменения правил Pod Security Policy (PSP). Основное внимание PSA уделяется проверке модулей на соответствие установленным стандартам безопасности Kubernetes , включая упомянутые выше профили.

• Отсутствие мутаций : хотя PSA эффективен при проверке, он не может изменять или настраивать спецификации модулей, как это может делать PSP. Основная цель PSA — обеспечить соблюдение предопределенных стандартов безопасности Kubernetes и не включает функции для изменения или изменения спецификаций модулей. В первую очередь он фокусируется на проверке модулей на соответствие этим установленным стандартам.

Настройка и установка

Поскольку PSA является собственным компонентом Kubernetes, чтобы он работал, вам просто нужно убедиться, что контроллер Pod Security Admission (PSA) включен в вашем кластере Kubernetes. Вы можете сделать это, выполнив следующую команду:

kubectl api-versions | grep admission

Подготовительные шаги к миграции

Оценка разрешений пространства имен

На контроль доступа к модулям влияют метки пространства имен. Это означает, что лица, имеющие возможность обновлять, исправлять или создавать пространства имен, также имеют право изменять настройки безопасности Pod для этих пространств имен. Эта модификация потенциально может обойти более строгие политики безопасности. Прежде чем продолжить, важно убедиться, что разрешения пространства имен назначаются исключительно доверенным и привилегированным пользователям. Целесообразно воздержаться от предоставления этих повышенных разрешений пользователям, которым такой доступ не требуется. Если для настройки меток Pod Security на объектах пространства имен необходимы дополнительные ограничения, рассмотрите возможность использования веб-перехватчика допуска для обеспечения соблюдения этих ограничений.

Оптимизация и нормализация PodSecurityPolicies

Прежде чем переходить на Pod Security Admission (PSA), полезно нормализовать PodSecurityPolicies (PSP):

• Удалить неподдерживаемые поля . Удалите параметры, не подпадающие под стандарты безопасности модулей. Эти параметры включают в себя:

  
  

 .spec.allowedHostPaths .spec.allowedFlexVolumes .spec.allowedCSIDrivers .spec.forbiddenSysctls .spec.runtimeClass

• Устранить чисто мутирующие поля : инициируйте процесс, удалив поля, которые имеют исключительно мутирующий эффект и не влияют на политику проверки. Эти поля, как также упоминается в справочнике «Сопоставление PodSecurityPolicies со стандартами безопасности Pod», включают в себя:

 .spec.defaultAllowPrivilegeEscalation .spec.runtimeClass.defaultRuntimeClassName .metadata.annotations['seccomp.security.alpha.kubernetes.io/defaultProfileName'] .metadata.annotations['apparmor.security.beta.kubernetes.io/defaultProfileName'] .spec.defaultAddCapabilities

Определите подходящий уровень безопасности модуля

При определении соответствующего уровня безопасности Pod для вашего пространства имен необходимо учитывать несколько методов:

По требованиям безопасности для пространства имен

Если вы знакомы с ожидаемым уровнем доступа и требованиями безопасности для пространства имен, вы можете выбрать соответствующий уровень безопасности модуля на основе этих конкретных требований. Этот подход аналогичен тому, как вы подходите к настройкам безопасности в новом кластере.

По существующим PodSecurityPolicies:

Используйте ссылку «Сопоставление PodSecurityPolicies со стандартами безопасности Pod» , чтобы сопоставить каждую из существующих политик безопасности Pod (PSP) с соответствующим уровнем стандарта безопасности Pod.
Если ваши PSP изначально не основаны на стандартах безопасности Pod, возможно, вам придется принять решение. Выберите уровень безопасности Pod, который, по крайней мере, такой же разрешительный, как у ваших PSP, или выберите уровень, который, по крайней мере, такой же ограничительный. Чтобы определить, какие PSP используются для модулей в определенном пространстве имен, используйте следующую команду:

 kubectl get pods -n $NAMESPACE -o jsonpath="{.items[*].metadata.annotations.kubernetes\.io\/psp}" | tr " " "\n" | sort -u

По существующим модулям:

Проведите пробный прогон и примените команду label из следующего раздела, чтобы проверить как базовый, так и ограниченный уровни безопасности модуля. Это поможет вам оценить, являются ли эти уровни достаточно допустимыми для существующих рабочих нагрузок. Выберите допустимый уровень с наименьшими привилегиями, соответствующий вашим существующим рабочим нагрузкам.

Тестирование уровня безопасности модуля

После того как вы определили уровень безопасности модуля для своего пространства имен (за исключением уровня «Привилегированный»), важно проверить выбранную политику. Pod Security предлагает варианты тестирования для обеспечения плавного развертывания и соответствия стандартам безопасности.

Тестирование всухую:

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

 kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL

Тестирование в режиме аудита:

Режим аудита позволяет фиксировать нарушения политики, не применяя их. Модули, нарушающие правила, заносятся в записи аудита для последующего просмотра. Включите режим аудита командой:

 kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/audit=$LEVEL

Если во время тестирования возникнут непредвиденные нарушения политики, вы можете:

• Обновите несоответствующие рабочие нагрузки, чтобы они соответствовали политике.
• При необходимости настройте уровень безопасности модуля для пространства имен в соответствии с требованиями вашей рабочей нагрузки.

Обеспечение уровня безопасности модуля

Если вы уверены, что выбранный уровень безопасности Pod подходит для вашего пространства имен, вы можете приступить к его принудительному применению. Этот шаг гарантирует, что желаемые стандарты безопасности будут активно применяться к вашим рабочим нагрузкам в пространстве имен.

Чтобы обеспечить желаемый уровень безопасности Pod в пространстве имен, используйте следующую команду:

 kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL

Выполнение этой команды активирует и обеспечит соблюдение указанного уровня безопасности модуля, повышая уровень безопасности вашего пространства имен.

Обход PSP

Чтобы эффективно обойти PodSecurityPolicy на уровне пространства имен, вы можете привязать политику безопасности Pod с полными привилегиями (PSP) ко всем учетным записям служб в пространстве имен. Этот процесс гарантирует, что модули в пространстве имен больше не подвергаются изменениям или ограничениям, налагаемым PodSecurityPolicy. Вы можете сделать это на уровне кластера или на уровне отдельного пространства имен.

Настройка на уровне кластера (требуется только один раз для всего кластера):

Создайте политику безопасности Pod с полными привилегиями (PSP), применив файл конфигурации YAML, например Privileged-psp.yaml . Этот PSP должен предоставить подам все необходимые привилегии и создать роль кластера с именем привилегированный-psp, чтобы разрешить использование политик безопасности подов (PSP), и связать ее с привилегированным PSP:

 kubectl apply -f privileged-psp.yaml kubectl create clusterrole privileged-psp --verb use --resource podsecuritypolicies.policy --resource-name privileged

Отключение для каждого пространства имен:

Создайте привязку роли в целевом пространстве имен, чтобы связать роль кластера привилегированного PSP с группой system:serviceaccounts:$NAMESPACE . Эта привязка фактически предоставляет всем учетным записям служб в пространстве имен доступ к PSP с полными привилегиями, минуя PodSecurityPolicy:

 kubectl create -n $NAMESPACE rolebinding disable-psp --clusterrole privileged-psp --group system:serviceaccounts:$NAMESPACE

При такой настройке привилегированный PSP не изменяется, а контроллер допуска PodSecurityPolicy всегда отдает приоритет неизменяемым PSP. В результате PodSecurityPolicy больше не будет изменять или ограничивать модули в этом пространстве имен.

Одним из преимуществ этого подхода является его обратимость. Если возникнут какие-либо проблемы, вы можете легко отменить изменения, удалив RoleBinding, связанный с отключением PodSecurityPolicy. Убедитесь, что ранее существовавшие политики безопасности модулей остаются в силе во время этого процесса.

Отменить отключение PodSecurityPolicy:

Чтобы отменить отключение PodSecurityPolicy для пространства имен, просто удалите созданную ранее привязку RoleBinding:

 kubectl delete -n $NAMESPACE rolebinding disable-psp

Пересмотрите процессы создания пространства имен

Поскольку существующие пространства имен обновлены для обеспечения обеспечения доступа Pod Security, важно пересмотреть и обновить процессы и политики для создания новых пространств имен. Это гарантирует, что в новых пространствах имен с самого начала будет настроен соответствующий профиль Pod Security.
Рассмотрите следующие шаги для улучшения процессов создания пространства имен:

1. Настройте политику создания пространства имен . Обновите политики и процедуры вашей организации для создания новых пространств имен, включив в них выбор и применение желаемого уровня безопасности модулей. Убедитесь, что стандарты безопасности установлены прямо на этапе создания.

2. Статическая конфигурация: вы можете статически настроить контроллер доступа Pod Security, чтобы определить уровни принудительного применения, аудита и/или предупреждений по умолчанию для немаркированных пространств имен. Этот подход гарантирует, что пространства имен, в которых отсутствуют явные метки Pod Security, по-прежнему соответствуют указанным вами стандартам безопасности по умолчанию.

   
   

   Пересмотрев процессы создания пространства имен, вы сможете легко интегрировать стандарты Pod Security в нашу среду Kubernetes и поддерживать согласованный и безопасный подход во всех пространствах имен, старых и новых.

Отключить PodSecurityPolicy

Если вы уверены, что контроллер допуска PodSecurityPolicy (PSP) больше не нужен и что допуск безопасности Pod (PSA) успешно реализован и проверен, вы можете приступить к отключению контроллера доступа PSP.

Вот шаги для отключения контроллера допуска PSP:

Измените конфигурацию kube-apiserver:

• Откройте файл конфигурации вашего kube-apiserver, который обычно находится по адресу /etc/kubernetes/manifests/kube-apiserver.yaml.
• Добавьте флаг --disable-admission-plugins , чтобы отключить контроллер доступа PSP. Убедитесь, что он удален из списка активных плагинов допуска.

 kube-apiserver --disable-admission-plugins=PodSecurityPolicy

• Сохраните файл конфигурации.

Перезапустите kube-apiserver:

• Перезапустите kube-apiserver, чтобы применить изменения. Обычно этого можно добиться, перезапустив плоскость управления Kubernetes или сам модуль kube-apiserver.

 systemctl restart kubelet

Проверка:

• Убедитесь, что контроллер доступа PSP отключен, проверив журналы kube-apiserver или его статус.

После достаточного времени ожидания, чтобы быть уверенным, что вам не потребуется откат к PSP, переходите к следующему шагу.

Ресурсы по очистке PSP:

Отключив контроллер допуска PSP и установив PSA, вы можете безопасно удалить существующие PodSecurityPolicies, а также любые связанные роли, ClusterRoles, RoleBindings и ClusterRoleBindings.

 kubectl delete podsecuritypolicies --all kubectl delete roles,clusterroles,rolebindings,clusterrolebindings --selector=rbac.authorization.kubernetes.io/autoupdate=true

Этот шаг очистки гарантирует отсутствие остаточных конфигураций PSP в вашем кластере.

Деактивируя контроллер допуска PSP и устраняя ресурсы, связанные с PSP, вы упрощаете архитектуру безопасности вашего кластера, завершая переход к допуску безопасности Pod.

Краткое содержание

В этом подробном руководстве мы рассмотрели основные шаги и соображения по плавному переходу структуры безопасности вашего кластера Kubernetes с политик безопасности Pod (PSP) на допуск безопасности Pod (PSA). Эта миграция гарантирует, что ваши рабочие нагрузки будут продолжать работать безопасно и соответствовать развивающимся стандартам безопасности Kubernetes.

Плюсы и минусы использования Pod Security Admission (PSA)

Плюсы:

• Собственный компонент Kubernetes : PSA является неотъемлемой частью Kubernetes, устраняя необходимость установки сторонних инструментов. Он использует встроенные функции безопасности платформы.
• Обеспечивает соблюдение стандартов Kubernetes : PSA соответствует собственным стандартам безопасности Kubernetes, обеспечивая соответствие лучшим практикам платформы.

Минусы:

• Ограниченная настройка : PSA может не обеспечивать тот же уровень настройки, что и PSP, особенно для сложных политик безопасности, требующих изменения спецификаций модулей.
• Требуется модернизация . Существующие рабочие нагрузки необходимо обновить, включив в них настройки контекста безопасности, что может потребовать изменения файлов YAML.

Это руководство предоставит вам знания и шаги, необходимые для уверенного перехода с PSP на PSA, гарантируя безопасный и эффективный переход, сохраняя при этом ваши рабочие нагрузки Kubernetes. Следите за обновлениями в следующих статьях, в которых я рассмотрю альтернативные пути перехода на Kyverno и OPA Gatekeeper.