Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье показано, как использовать контрольные механизмы развертывания для обеспечения лучших практик в кластере службы Azure Kubernetes (AKS).
Обзор
Примечание.
Защита развертывания включена по умолчанию в AKS Automatic.
На протяжении всего жизненного цикла разработки часто возникают ошибки, проблемы и другие проблемы, если первоначальное развертывание ресурсов Kubernetes включает неправильные настройки. Чтобы упростить нагрузку на разработку Kubernetes, служба Azure Kubernetes (AKS) предлагает средства защиты развертывания. Средства защиты развертывания применяют рекомендации Kubernetes в кластере AKS с помощью элементов управления политикой Azure.
Средства защиты развертывания предлагают два уровня конфигурации:
-
Warn: отображает предупреждающие сообщения в терминале кода, чтобы предупредить вас о любых несоответствующих конфигурациях кластера, но по-прежнему позволяет выполнять запрос. -
Enforce: применяет соответствующие конфигурации, запрещая и изменяя развертывания, если они не соответствуют рекомендациям.
После настройки средств защиты развертывания на "Предупреждение" или "Принудительное применение", средства защиты развертывания программно оценивают ресурсы Kubernetes на их соответствие требованиям в момент создания или обновления. Средства защиты развертывания также отображают агрегированные сведения о соответствии для рабочих нагрузок на уровне ресурсов с помощью панели мониторинга соответствия политик Azure на портале Azure или в интерфейсе командной строки или терминале. Выполнение несоответствующей рабочей нагрузки указывает, что кластер не соответствует рекомендациям и что рабочие нагрузки в кластере подвержены риску возникновения проблем, вызванных конфигурацией кластера.
Необходимые компоненты
Примечание.
Администраторы кластера не нуждаются в разрешениях политики Azure для включения или отключения защиты развертывания. Однако необходимо установить надстройку политики Azure.
- Необходимо включить надстройку Политика Azure для AKS. Дополнительные сведения см. в разделе "Включить Политика Azure" в кластере AKS. Это включает регистрацию поставщика ресурсов
Microsoft.PolicyInsightsв вашей подписке.
Политики защиты развертывания
В следующей таблице перечислены политики, которые становятся активными и нацелены на ресурсы Kubernetes при включении защиты развертывания. Вы можете просмотреть доступные средства защиты развертывания на портале Azure в виде определения политики Azure или встроенных определений политики Azure для службы Azure Kubernetes. Цель этой коллекции — создать общий и универсальный список рекомендаций, применимых к большинству пользователей и вариантов использования.
| Политика защиты развертывания | Результат мутации при наличии |
|---|---|
| Не удается изменить отдельные узлы | Н/П |
| Запросы на ресурсы ЦП и память контейнеров в кластере Kubernetes должны быть определены. | Задает запросы ЦП и памяти по умолчанию и применяет минимальные значения. Дополнительные сведения см. в разделе "Мутатор запросов ресурсов". |
| Должен иметь правила защиты от сходства или топологииSpreadConstraintsSet | Добавляет правила защиты от сопоставления pod и ограничения распространения топологии для улучшения распределения рабочей нагрузки. Дополнительные сведения см. в разделе "Анти-сходство" и "Топология распространения мутатора". |
| Нет конкретных меток AKS | Н/П |
| Контейнеры в кластере Kubernetes должны использовать только разрешенные образы | Н/П |
| Зарезервированные метки системного пула | Удаляет CriticalAddonsOnly фрагмент из пула узлов пользователя, если он не задан. AKS использует запятую CriticalAddonsOnly , чтобы сохранить модули pod клиента от системного пула. Эта конфигурация обеспечивает четкое разделение между компонентами AKS и клиентскими модулями pod и предотвращает вытеснение модулей pod клиентов, которые не допускают CriticalAddonsOnly их. |
| Убедитесь, что в контейнерах кластера настроены пробы проверки готовности или активности | Н/П |
| Кластеры Kubernetes должны использовать драйвер StorageClass для интерфейса хранилища контейнеров (CSI) | Н/П |
| Службы кластеров Kubernetes должны использовать уникальные селекторы | Н/П |
| Образы контейнеров кластера Kubernetes не должны содержать последний тег образа | Н/П |
Если вы хотите отправить идею или запрос на защиту развертывания, откройте проблему в репозитории AKS GitHub и добавьте [Deployment Safeguards request] в начало заголовка.
Мутатор запросов ресурсов
Если для защиты развертывания установлен уровень Enforce, мутатор запросов ресурсов автоматически задает параметры запросов и ограничения для ЦП и памяти в контейнерах, в которых они не определены или имеют значения ниже минимально допустимых.
Значения по умолчанию
Если ресурсы не указаны, мутатор задает следующие значения по умолчанию:
| Resource | Просьба | Лимит |
|---|---|---|
| ЦП | 500 м | 500 м |
| Memory | 2048Mi (2Gi) | 2048Mi (2Gi) |
Минимальный контроль
Если ресурсы указаны, но они ниже пороговых значений, мутатор применяет следующие минимальные значения:
| Resource | Минимальное значение |
|---|---|
| ЦП | 100 м |
| Memory | 100Mi |
Общие сведения об единицах ресурсов
Единицы ЦП:
-
m= милликоры (1m= 1/1000 ядра ЦП) -
1000m= 1 полное ядро ЦП -
500m= 0,5 ядра ЦП (половина ядра) -
100m= 0,1 ядра ЦП (10% ядра)
Единицы памяти:
-
Mi= Mebibytes (binary: 1 Mi = 1 024 × 1 024 байта) -
Gi= Gibibytes (binary: 1 Gi = 1,024 Mi) 2048Mi=2Gi-
100Mi≈ 105 МБ
Правила изменения ЦП
Мутатор применяет следующую логику для ресурсов ЦП:
| Scenario | Действие |
|---|---|
| Запросы и ограничения для ЦП (центрального процессора) отсутствуют. | Задайте для обоих значение 500m (по умолчанию) |
Запрос центрального процессора существует, но меньше 100m |
Задайте для запроса значение 100m (минимальное значение) |
Ограничение ЦП существует, но меньше 100m |
Установите ограничение 100m (минимальное) |
| Существует только запрос ЦП | Установка запроса, равного ограничению |
| Существует только ограничение ЦП | Установка запроса, равного ограничению |
Правила изменения памяти
Мутатор применяет следующую логику для ресурсов памяти:
| Scenario | Действие |
|---|---|
| Запрос памяти и ограничение отсутствуют | Задайте для обоих значение 2048Mi (по умолчанию) |
Запрос на память существует, но меньше 100Mi |
Задайте для запроса значение 100Mi (минимальное значение) |
Ограничение памяти существует, но меньше 100Mi |
Установите ограничение 100Mi (минимальное) |
| Существует только запрос памяти | Оставьте как есть (не добавлено ограничение) |
| Существует только ограничение памяти | Оставьте как есть (запрос не добавлен) |
Исправление класса качества обслуживания (QoS) в Kubernetes
После применения изменений ЦП и памяти, если значение запроса превышает ограничение для того же типа ресурса, мутатор заключит запрос, чтобы соответствовать ограничению. Это исправление поддерживает допустимые конфигурации классов Kubernetes Quality of Service (QoS).
Случаи, которые мутируют
Мутатор запросов ресурсов применяет изменения в следующих сценариях:
-
Пустые ресурсы: контейнеры без запросов ЦП или памяти или ограничений получают значения по умолчанию (
500mЦП,2048Miпамять). -
Ниже минимальных пороговых значений: запросы ЦП или ограничения ниже
100mувеличиваются до100m. Запросы или ограничения памяти ниже100Miувеличены до100Mi. - Недопустимые сценарии качества обслуживания: когда запросы превышают ограничения, запросы снижаются до соответствия ограничениям.
- Спецификации частичных ресурсов: контейнеры с только запросами или только ограничениями (но не оба) имеют минимальные ограничения, которые применяются, где указано.
- Несколько контейнеров: все контейнеры в модуле pod обрабатываются и мутируются соответствующим образом.
- Включенные пространства имен: только рабочие нагрузки в пространствах имен, в которых включен защитный механизм, подвергаются изменениям.
Случаи, которые не подвергаются мутации
Мутатор запросов ресурсов не применяет изменения в следующих сценариях:
- Исключенные пространства имен: рабочие нагрузки в пространствах имен, в которых защита исключается, остаются неизменными.
- Уже соответствующие ресурсы: контейнеры, для которых уже установлены запросы и ограничения, превышающие минимальные пороговые значения, остаются неизменными.
- Допустимые конфигурации QoS: если запросы меньше или равны ограничениям, и оба значения превышают минимальные значения, изменения не происходят.
Анти-аффинность и распространение по топологии Mutator
Если для Deployment Safeguards задан уровень Enforce, мутатор анти-аффинности и распределения топологии автоматически добавляет правила анти-аффинности pod и ограничения распространения топологии для улучшения распределения рабочей нагрузки между узлами.
При запуске мутатора
Мутатор запускается только при соблюдении всех следующих условий:
- Ограничения на антиаффинность подов и распределение топологии еще не установлены в рабочей нагрузке.
- Пространство имен не исключается из средств защиты развертывания.
- Механизмы безопасности развертывания находятся в
Enforceрежиме. - Рабочая нагрузка не имеет
kubernetes.azure.com/managedby=aksметки.
Что добавляет мутатор
Идентификация меток: Мутатор идентифицирует поды по следующему приоритету меток:
-
applabel (первый приоритет) -
app.kubernetes.io/namelabel (второй приоритет) - Создает метку (резервная версия
default-antiaffinity-applabel=<workload-name>)
Pod anti-affinity: добавляет предпочтительное правило антиаффинности с весом 100, предполагающее планирование pod с соответствующими метками на разных узлах. Использует ключ kubernetes.io/hostname топологии.
Ограничения распространения топологии: добавляет ограничение со следующими параметрами:
| Setting | Ценность |
|---|---|
| MaxSkew | 1 (допускает максимальную разницу в 1 pod на узел) |
| WhenUnsatisfiable | ScheduleAnyway (лучше всего, не блокирует планирование) |
| Ключ топологии | kubernetes.io/hostname |
Измененные случаи
Мутатор распространения топологии и защиты от сходства применяет изменения в следующих сценариях:
-
Рабочие нагрузки с
appметкой: используютappзначение метки для селекторов распространения топологии и анти-афинности. -
Рабочие нагрузки с
app.kubernetes.io/nameметкой: когда меткаappотсутствует, используется эта метка для селекторов. - Рабочие нагрузки без меток приложений: создает метку по умолчанию, используя имя рабочей нагрузки, и добавляет правила анти-аффинности и распределения топологии.
- Чистые рабочие нагрузки: рабочие нагрузки без существующих ограничений по сходству или распространению топологии принимают обе конфигурации.
- Частичное сходство: рабочие нагрузки с существующим сходством узлов (но без антипатии pod) получают правила распространения топологии.
- Включенные пространства имен: изменения происходят только в пространствах имен, где включена защита.
Случаи, которые не подвергаются мутации
Мутатор анти-симпатии и распределения топологии не применяет изменения в следующих сценариях:
- Существующие ограничения распространения топологии: рабочие нагрузки, у которых уже есть ограничения распространения топологии, пропускаются полностью.
- Существующие правила защиты от сопоставления pod: рабочие нагрузки с существующими обязательными или предпочитаемыми правилами защиты от сопоставления pod полностью пропускаются.
- Исключенные пространства имен: рабочие нагрузки в пространствах имен, в которых защита исключается, остаются неизменными.
- Рабочие нагрузки без определяемых имен или меток: крайние случаи, когда имя приложения не может быть определено, пропускаются без ошибок.
Сообщения об ошибках мер безопасности при развертывании
В этом разделе описываются сообщения об ошибках, которые могут возникнуть при обнаружении несоответствующих конфигураций, а также рекомендуемых исправлений.
Общие сообщения об ошибках защиты
В следующей таблице перечислены сообщения об ошибках для общих политик защиты развертывания:
| Policy | Сообщение об ошибке | Исправить |
|---|---|---|
| Принудительное применение проб | Container <container_name> in your Pod <pod_name> has no livenessProbe. Required probes: readinessProbe, livenessProbe |
Добавьте пробы активности и готовности к каждому контейнеру. |
| Нет изображения «Последний» | Please specify an explicit, versioned image tag such as '1.0' for container %v. Using explicit version tags is a best practice to ensure reproducibility, prevent unintended updates, and facilitate easier debugging and rollbacks. Avoid using the 'latest' tag because it can change over time without notice. |
Используйте явный тег изображения, отличный от latest или пустого. Например, nginx не допускается, но nginx:v1.0.0 допускается. |
| Принудительное применение драйвера CSI |
Storage class <class_name> use intree provisioner kubernetes.io/azure-file is not allowed или Storage class <class_name> use intree provisioner kubernetes.io/azure-disk is not allowed |
Вместо этого используются типы disk.csi.azure.com или file.csi.azure.com. Дополнительные сведения см. в статье о драйверах CSI в AKS. |
| Запросы ресурсов | container <container_name> has no resource requests |
Добавьте запросы ЦП и памяти в контейнер. |
| Правила антиаффинности | Deployment with 2 replicas should have either podAntiAffinity or topologySpreadConstraints set to avoid disruptions due to nodes crashing |
Задайте podAntiAffinity или topologySpreadConstraints для рабочей нагрузки. |
| Ограниченные метки | Label kubernetes.azure.com is reserved for AKS use only |
Удалите метку из рабочей нагрузки. |
| Ограниченные изменения узла | Tainting or labeling individual nodes is not recommended. Please use Azure CLI to taint/label node pools instead |
Используйте Azure CLI, чтобы запятнать пулы узлов, а не отдельные узлы. |
| Ограниченные тэйнты | Taint with key CriticalAddonsOnly is reserved for the system pool only |
Не запятнайте пул узлов пользователя.CriticalAddonsOnly |
Сообщения об ошибках стандартов безопасности Pod
Примечание.
Базовые стандарты безопасности Pod теперь включены по умолчанию в АКС Automatic. Базовые стандарты безопасности Pod в AKS Automatic не могут быть отключены.
Средства защиты развертывания также поддерживают возможность включения базовых, ограниченных и привилегированных стандартов безопасности Pod. Чтобы обеспечить успешное развертывание рабочих нагрузок, убедитесь, что каждый манифест соответствует требованиям базовой или ограниченной безопасности Pod. По умолчанию служба Azure Kubernetes использует привилегированные стандарты безопасности Pod.
| Policy | Сообщение об ошибке | Исправить |
|---|---|---|
| AppArmor |
AppArmor annotation values must be undefined/nil, runtime/default, or localhost/* или AppArmor profile type must be one of: undefined/nil, RuntimeDefault, or Localhost |
Удалите любую спецификацию AppArmor. Kubernetes по умолчанию применяет параметры AppArmor. На поддерживаемых узлах профиль RuntimeDefault AppArmor применяется по умолчанию. |
| Пространства имен узла |
Host network namespaces are disallowed: spec.hostNetwork is set to true или Host PID namespaces are disallowed: spec.hostPID is set to true или Host IPC namespaces are disallowed: spec.hostIPC is set to true |
Установите для этих значений false или удалите указание полей. |
| Привилегированные контейнеры | Privileged [ephemeral\|init\|N/A] containers are disallowed: spec.containers[*].securityContext.privileged is set to true |
Задайте соответствующее securityContext.privileged поле на false, или удалите поле. |
| Capabilities | Сообщение начинается с Disallowed capabilities detected |
Удалите функцию, указанную в манифесте контейнера. |
| Тома HostPath | HostPath volumes are forbidden under restricted security policy unless containers mounting them are from allowed images |
Удалите том HostPath и точку монтирования тома. |
| Хостовые порты | HostPorts are forbidden under baseline security policy |
Удалите спецификацию порта узла из проблемного контейнера. |
| SELinux | SELinux type must be one of: undefined/empty, container_t, container_init_t, container_kvm_t, or container_engine_t |
Задайте для поля контейнера securityContext.seLinuxOptions.type одно из допустимых значений. |
| Тип подключения /proc | ProcMount must be undefined/nil or 'Default' in spec.containers[*].securityContext.procMount |
Установите spec.containers[*].securityContext.procMount на Default или оставьте его не заданным. |
| Seccomp | Seccomp profile must not be explicitly set to Unconfined. Allowed values are: undefined/nil, RuntimeDefault, or Localhost |
Задайте securityContext.seccompProfile.type для pod или контейнеров одно из допустимых значений. |
| Sysctls | Disallowed sysctl detected. Only baseline Kubernetes pod security standard sysctls are permitted |
Удалите недопустимые sysctl-параметры. Подробный список см. в спецификации стандартов безопасности pod Kubernetes. |
| Типы томов (только для PSS) | Only the following volume types are allowed under restricted policy: configMap, csi, downwardAPI, emptyDir, ephemeral, persistentVolumeClaim, projected, secret |
Удалите любые тома, которые не являются одним из разрешенных типов. |
| Эскалация привилегий (ограничено только для PSS) | Privilege escalation must be set to false under restricted policy |
spec.containers[*].securityContext.allowPrivilegeEscalation Установите false для каждого контейнера, initContainer и эфемерного контейнера. |
| Запуск некорневым пользователем (только для ограниченных PSS) | Containers must not run as root user in spec.containers[*].securityContext.runAsNonRoot |
Установите spec.containers[*].securityContext.runAsNonRoot на true для каждого контейнера, initContainer и эфемерного контейнера. |
| Запуск от имени пользователя без прав суперпользователя (только для режима PSS с ограничениями) | Containers must not run as root user: spec.securityContext.runAsUser is set to 0 |
Задайте securityContext.runAsUser ненулевое значение или оставьте его неопределенным для уровня пода и каждого контейнера, initContainer и ephemeralContainer. |
| Seccomp (только для ограниченного использования PSS) | Seccomp profile must be "RuntimeDefault" or "Localhost" under restricted policy |
Задайте securityContext.seccompProfile.type для pod или контейнеров одно из допустимых значений. Это отличается от базовой конфигурации, так как ограниченная политика не допускает неопределенное значение. |
| Возможности (только для ограниченного использования PSS) |
All containers must drop ALL capabilities under restricted policy или Only NET_BIND_SERVICE may be added to capabilities under restricted policy |
Все контейнеры должны отказаться от ALL возможностей и могут добавлять только NET_BIND_SERVICE. |
Включить защиту развертывания
Примечание.
Использование уровня "Защита развертывания" Enforce означает, что вы выбираете включение блокировки и модификации развертываний. Прежде чем включить Enforce, подумайте, как эти политики могут работать с вашим кластером AKS.
Включение защиты развертывания в существующем кластере
Включите защиту развертывания в существующем кластере, в котором включено дополнение Azure Policy, используя команду az aks safeguard create с флагом --level. Если вы хотите получать предупреждения о несоответствии, задайте для --level нее значение Warn. Если вы хотите запретить или изменить все несоответствующие развертывания, задайте для него значение Enforce.
az aks safeguards create --resource-group <resource-group-name> --name <cluster-name> --level Enforce
Вы также можете включить средства защиты развертывания с помощью флага --cluster и указать идентификатор ресурса кластера.
az aks safeguards create --cluster <ID> --level Enforce
Если вы хотите обновить уровень защиты развертывания существующего кластера, выполните следующую команду с новым значением.--level
az aks safeguards update --resource-group <resource-group-name> --name <cluster-name> --level Warn
Исключение пространств имен
Вы также можете исключить определенные пространства имен из средств защиты развертывания. При исключении пространства имен действие в этом пространстве имен не влияет на предупреждения или принудительное применение средств защиты развертывания.
Например, чтобы исключить пространства имен ns1 и ns2, используйте разделенный пробелами список пространств имен с флагом --excluded-ns, как показано в следующем примере.
az aks safeguards update --resource-group <resource-group-name> --name <cluster-name> --level Warn --excluded-ns ns1 ns2
Включите стандарты безопасности Pod
Примечание.
Служба Azure Kubernetes (AKS) использует Privileged стандарты безопасности pod по умолчанию. Если вы хотите вернуться к конфигурации по умолчанию, задайте для флага --pss-level значение Privileged.
Чтобы включить стандарты безопасности Pod в мерах защиты развертывания, используйте --pss-level параметр для выбора одного из следующих уровней: Baseline, Restricted или Privileged.
az aks safeguards update --resource-group <resource-group-name> --name <cluster-name> --level Warn --pss-level <Baseline|Restricted|Privileged>
Обновление версии защиты развертывания
Средства защиты развертывания соответствуют схеме управления версиями надстроек AKS. Каждая новая версия механизма обеспечения безопасности развертывания будет выпущена в качестве новой минорной версии в AKS. Эти обновления будут переданы через заметки о выпуске AKS GitHub и будут отражаться в таблице "Политики защиты развертывания" в нашей документации.
Дополнительные сведения об использовании версий и надстройках AKS см. в следующей документации: aks-component-versions и aks-versioning-for-addons.
Проверка соответствия между кластерами
После развертывания манифеста Kubernetes вы увидите предупреждения или потенциальное сообщение об отказе в интерфейсе командной строки или терминале, если кластер не соответствует требованиям средств защиты развертывания, как показано в следующих примерах:
Предупредить
$ kubectl apply -f deployment.yaml
Warning: [azurepolicy-k8sazurev1antiaffinityrules-ceffa082711831ebffd1] Deployment with 2 replicas should have either podAntiAffinity or topologySpreadConstraints set to avoid disruptions due to nodes crashing
deployment.apps/simple-web created
принудительное применение
При изменении уровня Deployment Safeguard, ваши ресурсы Kubernetes изменяются, когда это применимо. Однако ресурсы Kubernetes по-прежнему должны передавать все меры безопасности для успешного развертывания. Если какие-либо политики защиты завершаются ошибкой, ресурс запрещен и не будет развернут.
$ kubectl apply -f deployment.yaml
Error from server (Forbidden): error when creating "deployment.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [azurepolicy-k8sazurev1antiaffinityrules-ceffa082711831ebffd1] Deployment with 2 replicas should have either podAntiAffinity or topologySpreadConstraints set to avoid disruptions due to nodes crashing
Если ресурсы Kubernetes соответствуют применимым гарантиям мутаций и соответствуют всем другим требованиям защиты, они будут успешно развернуты, как показано в следующем примере:
$ kubectl apply -f deployment.yaml
deployment.apps/simple-web created
Проверка соответствия между кластерами с помощью панели мониторинга Политика Azure
Чтобы проверить применение средств защиты развертывания и проверить соответствие кластера, перейдите на страницу портала Azure для кластера и выберите политики, а затем перейдите к политике Azure.
В списке политик и инициатив выберите инициативу, связанную с защитой развертывания. Отображается панель мониторинга, показывающая состояние соответствия в кластере AKS.
Примечание.
Чтобы правильно оценить соответствие в кластере AKS, Политика Azure инициатива должна быть ограничена группой ресурсов кластера.
Отключение защиты развертывания
Чтобы отключить защиту развертывания в кластере delete , используйте команду.
az aks safeguards delete --resource-group <resource-group-name> --name <cluster-name>
Вопросы и ответы
Можно ли создать собственные мутации?
№ Если у вас есть идея о защите, откройте проблему в репозитории AKS GitHub и добавьте [Deployment Safeguards request] в начало заголовка.
Можно ли выбрать и выбрать изменения, которые я хочу в принудительном применении?
№ Защита развертывания — это все или ничего. После включения предупреждения или принудительного применения все меры защиты активны.
Почему мой ресурс развертывания признался, несмотря на то, что он не следует рекомендациям?
Механизмы защиты развертывания применяют наилучшие практики с помощью элементов управления политикой Azure и имеют политики для проверки ресурсов Kubernetes. Чтобы оценить и применить компоненты кластера, Политика Azure расширяет Gatekeeper. Принудительное применение gatekeeper также в настоящее время работает в fail-open модели. Так как нет никакой гарантии, что Gatekeeper отвечает на наш сетевой вызов, мы убедимся, что в этом случае проверка пропускается, чтобы запрет не блокировал развертывания.
Дополнительные сведения см. в статье "Проверка рабочей нагрузки" в Gatekeeper.
Следующие шаги
- Узнайте больше о рекомендациях по работе с кластером AKS.