Поделиться через


Базовые показатели управления, безопасности и соответствия требованиям для Kubernetes с поддержкой Azure Arc

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

Политика Azure и Microsoft Defender для облака — это облачные средства, которые позволяют реализовать средства защиты, элементы управления, отчеты, оповещения и задачи исправления в автоматическом масштабе. Объединяя их с Kubernetes с поддержкой Azure Arc, вы можете расширить политики управления и проверки безопасности в любом кластере Kubernetes в локальной среде и (или) многооблачной среде.

Архитектура

На следующей схеме показана концептуальная эталонная архитектура, изображающая области проектирования безопасности, соответствия и управления для Kubernetes с поддержкой Azure Arc:

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

Рекомендации по проектированию

Так как гибридные и многооблачные ресурсы становятся частью Azure Resource Manager, вы можете управлять ими из Azure. В этом разделе содержатся рекомендации по проектированию, которые следует учитывать при планировании безопасности и управления ресурсами кластера Kubernetes с поддержкой Azure Arc.

Просмотрите области проектирования безопасности и управления целевых зон Azure, чтобы оценить влияние Kubernetes с поддержкой Azure Arc на общие модели управления и безопасности.

Подготовка агента

Определите стратегию подготовки агента Kubernetes с поддержкой Azure Arc и используйте минимальные привилегии при создании субъекта-службы подключения. Рекомендуется использовать автоматизацию для массовой регистрации.

Управление агентами

Агенты Kubernetes с поддержкой Azure Arc играют важную роль в гибридных операциях кластеров Kubernetes с поддержкой Azure Arc, так как они позволяют управлять кластерами из Azure. Реализуйте решения, которые отслеживают состояние подключения агента. Убедитесь, что вы определите процесс обновления агентов Kubernetes с поддержкой Azure Arc.

Управление доступом на основе ролей (RBAC)

Определите административные, операции и роли разработчика в организации, которые отвечают за повседневные операции в гибридных кластерах. Сопоставление каждой команды с действиями и обязанностями определяет роли управления доступом на основе ролей Azure (RBAC) и Кластер Kubernetes ClusterRoleBinding и RoleBinding.

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

Дополнительные сведения см. в статье "Управление удостоверениями и доступом" для Kubernetes с поддержкой Azure Arc.

Управление секретами и сертификатами

Защита секретов и сертификатов с помощью Azure Key Vault и развертывания его расширения в кластерах Kubernetes с поддержкой Azure Arc с помощью интерфейса хранилища контейнеров (CSI).

Место расположения данных

Рассмотрим, какой регион Azure планируется подготовить кластер Kubernetes с поддержкой Azure Arc. Узнайте , какие данные собираются из ресурсов и планируются соответствующим образом на основе требований к месту размещения данных для вашей организации.

Включение и защита конфигураций GitOps

Конфигурации GitOps обеспечивают требуемое состояние системы и являются важным средством для отслеживания соответствия кластера Kubernetes с поддержкой Arc. При работе с конфигурациями GitOps рекомендуется защитить доступ к системе управления версиями с помощью соответствующих сетевых и элементов управления доступом.

Управление политиками и отчеты

Определите план управления для гибридных кластеров Kubernetes, который преобразуется в политики Azure, которые проверяют и применяют стандарты организации в масштабе. Например, вы можете применить политику sourceControlConfiguration к кластерам Kubernetes, чтобы гарантировать, что кластеры получают источник истины для рабочих нагрузок и конфигураций из определенного репозитория Git и отслеживают соответствие требованиям с помощью Политика Azure.

Стратегия управления журналами

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

Защита от угроз и управление безопасностью в облаке

Принудительное применение защиты от угроз и внедрение элементов управления для обнаружения неправильной настройки безопасности и отслеживания соответствия требованиям. Используйте аналитику Azure для защиты гибридных рабочих нагрузок от угроз. Включите мониторинг базовых показателей безопасности, управление безопасностью и защиту от угроз для всех подписок, содержащих Kubernetes с поддержкой Azure Arc, за счет включения Microsoft Defender для контейнеров.

Безопасный доступ к кластеру

Запланируйте безопасный доступ к API Kubernetes. Функция подключения кластера Kubernetes с поддержкой Azure Arc обеспечивает подключение к серверу API без включения входящего порта.

Улучшение наблюдаемости микрослужб и безопасности

Реализация сетки служб может помочь в проверке подлинности, авторизации, безопасности и видимости приложений на основе микрослужб. Kubernetes с поддержкой Azure Arc упрощает развертывание Сетки Open Service (OSM) в качестве расширения.

Рекомендации по проектированию

В этом разделе содержатся рекомендации по проектированию, которые следует следовать при планировании безопасности и управления ресурсами кластера Kubernetes с поддержкой Azure Arc.

Подготовка агента

  • Определите стратегию подключения кластеров к Azure Arc, включая метод автоматизации для массовой регистрации. Создайте формальный план, который учитывает область развертывания и включает цели, критерии выбора, критерии успешности, планы обучения, откат и риски.

  • Вы можете использовать субъект-службу для интеграции подготовки агентов в рамках конвейеров непрерывной интеграции и непрерывного развертывания (CI/CD). Необходимо ограничить привилегии этого субъекта-службы и назначить только роли, необходимые для подключения Kubernetes к Azure (роль "Кластер Kubernetes — подключение Azure Arc"), так как ее можно использовать только для подключения Kubernetes, а не отмены процесса или удаления ресурса.

Управление агентами

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

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

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

Если служба не получила пульс агента в течение 15 минут, кластер Kubernetes с поддержкой Azure Arc отображается как автономный. Чтобы обеспечить безопасное подключение агента к конечным точкам Azure Arc, ознакомьтесь с критической областью проектирования подключения Kubernetes с поддержкой Azure Arc.

Управление доступом на основе ролей (RBAC)

После подключения кластера Kubernetes вы можете назначить Azure RBAC ресурсу кластера Kubernetes с поддержкой Azure Arc.

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

Вы должны применить тот же принцип RBAC к конфиденциальным данным, которые отправляются в рабочую область Azure Monitor Log Analytics. Kubernetes с поддержкой Azure Arc предоставляет доступ RBAC к данным журнала, собранным агентом Log Analytics, хранящимся в рабочей области Log Analytics, в которую зарегистрирован кластер. Чтобы узнать, как реализовать детальный доступ к рабочей области Log Analytics, просмотрите сведения о развертывании журналов Azure Monitor.

Интеграция кластера Kubernetes с поддержкой Azure Arc с идентификатором Microsoft Entra позволяет использовать назначения ролей Azure для более детального контроля доступа к ресурсам кластера с поддержкой Azure Arc и разрешений.

Примечание.

Эта интеграция работает в собственном коде с типами объектов ClusterRoleBinding и RoleBinding и эффективно объединяет авторизацию в кластере Kubernetes с идентификатором Microsoft Entra в качестве центральной службы управления удостоверениями и доступом. Используя идентификатор Microsoft Entra, вы получаете полный аудит и трассировку изменений, внесенных в кластер, а также любые события авторизации.

Интеграция с идентификатором Microsoft Entra также позволяет получить доступ к расширенным возможностям безопасности, которые следует использовать для настройки:

  • Условный доступ с идентификатором Microsoft Entra. Дополнительные сведения об условном доступе можно найти в обзоре условного доступа.
  • Правила доступа JIT для задач, которым требуются повышенные разрешения. Наличие постоянного доступа для некоторых пользователей к конфиденциальной информации или критически важным параметрам конфигурации сети в Kubernetes создает потенциальный путь для скомпрометированных учетных записей или внутренних действий угроз. Управление привилегированным доступом может помочь защитить организацию от нарушений и помочь вам удовлетворить рекомендации по соответствию требованиям, ограничив постоянный доступ к конфиденциальным данным или доступ к критически важным параметрам конфигурации.

Управление секретами и сертификатами

Не сохраняйте секреты или сертификаты в коде приложения или файловых системах. Секреты должны размещаться в хранилищах ключей и предоставляться контейнерам во время выполнения по мере необходимости.

Рекомендуется использовать расширение Azure Key Vault для управления секретами и сертификатами в кластерах Kubernetes с поддержкой Azure Arc. Расширение Key Vault позволяет управлять жизненным циклом сертификата в развертываниях Kubernetes, как показано на следующей схеме.

Схема, на которой показана интеграция Kubernetes с поддержкой Azure Arc и Key Vault.

Включение и защита конфигураций GitOps

GitOps является важным компонентом любой ИТ-стратегии, которая принимает полностью автоматизированный подход к операциям. GitOps предоставляет возможности масштабирования, согласованности, отслеживания и аудита для любого развертывания.

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

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

Управление политиками и отчеты

Управление на основе политик — это базовый принцип облачных операций и Microsoft Cloud Adoption Framework для Azure. Политика Azure предоставляет механизм применения корпоративных стандартов и оценки соответствия в масштабе. С помощью Политика Azure можно реализовать управление для согласованности развертываний, соответствия требованиям, управления затратами, состоянием безопасности. На панели мониторинга соответствия можно просмотреть агрегированное представление общего состояния среды в масштабе и найти возможности исправления на уровне кластера.

Kubernetes с поддержкой Azure Arc поддерживает Политика Azure на уровне управления ресурсами Azure, а также принудительное применение политик в кластере путем расширения Gatekeeper для агента Open Policy. Вы можете реализовать любую из встроенных политик , чтобы быстро добиться соответствия требованиям и принудительного применения в масштабе. На следующей схеме показано, как Политика Azure применять масштабируемые принудительное применение и защиту к кластерам Kubernetes с поддержкой Azure Arc.

Схема, на которой показана политика Kubernetes с поддержкой Azure Arc.

Изучите область политики Azure и где ее можно применить (группу управления, подписку, группу ресурсов или отдельный уровень ресурсов). Используйте встроенную библиотеку Политика Azure для Kubernetes с поддержкой Azure Arc. Создайте структуру группы управления в соответствии с рекомендациями, описанными в руководстве по масштабированию облачных решений Cloud Adoption Framework для предприятий.

  • Определите, какие политики Azure необходимы для удовлетворения бизнес-требований, нормативных и нормативных требований вашей организации для Kubernetes с поддержкой Azure Arc.
  • Применение тегов и реализация задач исправления.
  • Используйте Политика Azure для применения GitOps и применения конфигураций в масштабе.
  • Изучите и оцените встроенные определения Политика Azure для Kubernetes с поддержкой Azure Arc.
  • политики DeployIfNotExists Политика Azure программно развертывают расширения и агенты службы управления в кластерах с поддержкой Arc в масштабе, включая Azure Monitor.
  • Включите Аналитику контейнеров Azure Monitor для обеспечения соответствия требованиям и оперативного мониторинга кластеров Kubernetes с поддержкой Azure Arc.

Стратегия управления журналами

Проектирование и планирование развертывания рабочей области Log Analytics, которая является хранилищем, в котором собираются, агрегируются и более поздние анализы. Так как рабочая область Log Analytics представляет географическое расположение данных, чтобы поддерживать уровень изоляции и области для конфигураций, таких как хранение данных, необходимо определить количество необходимых рабочих областей и их сопоставление со структурой организации.

Используйте одну рабочую область Azure Monitor Log Analytics для управления централизованным RBAC, видимостью и отчетами, как описано в рекомендациях по управлению и мониторингу Cloud Adoption Framework.

Дополнительные сведения см. в рекомендациях по проектированию развертывания журналов Azure Monitor.

Защита от угроз и управление безопасностью в облаке

  • Microsoft Defender для облака предоставляет унифицированную платформу управления безопасностью, сегментированную как управление безопасностью облака (CSPM) и платформу защиты облачных рабочих нагрузок (CWPP). Чтобы повысить безопасность гибридной целевой зоны, необходимо защитить данные и ресурсы, размещенные в Azure и других местах.
  • Microsoft Defender для контейнеров расширяет возможности Microsoft Defender для облака в Kubernetes с поддержкой Azure Arc. Чтобы обеспечить безопасность в гибридной целевой зоне, рассмотрите:
    • Использование расширения Kubernetes с поддержкой Azure Arc для подключения ресурсов Kubernetes с поддержкой Arc в Microsoft Defender для облака.
    • Включение плана Microsoft Defender для контейнеров для всех подписок. По умолчанию план настраивается для автоматического развертывания расширения Defender в любом кластере Kubernetes с поддержкой Arc, подключенном к той же подписке. При необходимости эту конфигурацию можно изменить.
    • Убедитесь, что расширение Defender развернуто в кластерах.
    • Интеграция сведений о безопасности и управления событиями (SIEM) с Microsoft Defender для облака и Microsoft Sentinel.

На следующей схеме показана концептуальная эталонная архитектура для Microsoft Defender для облака в ресурсе кластера Kubernetes с поддержкой Azure Arc.

Схема, изображающая Microsoft Defender для Azure Arc Kubernetes.

Если вы используете Реестр контейнеров Майкрософт в качестве центрального частного реестра Docker для хранения образов контейнеров и управления ими, следует использовать Microsoft Defender для контейнеров для сканирования образов уязвимостей.

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

Безопасный доступ к кластеру

API Kubernetes получает запросы на выполнение действий в кластере. Так как это центральный способ взаимодействия с кластером и управления ими, API Kubernetes является ключевым элементом, который необходимо защитить. С помощью подключения кластера Kubernetes с поддержкой Azure Arc вы можете безопасно подключаться к кластерам Kubernetes с поддержкой Azure Arc, не требуя включения любого входящего порта в брандмауэре. Доступ к серверу API с поддержкой Azure Arc Kubernetes обеспечивает следующие преимущества:

  • Включает интерактивную отладку и устранение неполадок.
  • Позволяет использовать размещенные агенты и средства выполнения Azure Pipelines, GitHub Actions или любую другую размещенную службу CI/CD, не требуя локальных агентов.
  • Предоставляет кластерный доступ к службам Azure для пользовательских расположений и других ресурсов, созданных на основе них.

Наблюдаемость микрослужб и безопасность

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

Реализации сетки служб могут защититься от:

  • Несанкционированный доступ
  • Sniffing атаки
  • Кража данных
  • Олицетворения

Дополнительные сведения см. в критической области проектирования реализации сетки Open Service.

Следующие шаги

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