Обзор безопасности сети приложений Azure Kubernetes (предварительная версия)

Сеть приложений Azure Kubernetes защищает обмен данными между службами в подключенных кластерах Службы Azure Kubernetes (AKS) с помощью автоматической взаимной авторизации TLS (mTLS) и авторизации на основе удостоверений. Он выдает идентификаторы рабочей нагрузки и управляет выдачей, ротацией и проверкой сертификатов, чтобы обеспечить шифрованное, аутентифицированное и явно авторизованное взаимодействие между службами без ручной настройки, с шифрованием при передаче, соответствующим требованиям FIPS.

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

Ограничения

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

mTLS

Сеть приложений использует mTLS для обеспечения зашифрованной связи на основе удостоверения личности между рабочими нагрузками. Каждая служба в кластере, подключенном к сети приложений, автоматически получает сертификат, который позволяет подтвердить свое удостоверение и установить доверенные, зашифрованные подключения с другими службами в той же сети приложений. Шифрование при передаче использует криптографию, совместимую с FIPS.

Стратегия миграции mTLS

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

Преимущества mTLS в сети приложений Azure Kubernetes

MTLS в Сети приложений Azure Kubernetes помогает:

• Защита данных при передаче: весь трафик между службами можно шифровать автоматически (fiPS-совместимый).
• Проверка удостоверения службы. Каждая рабочая нагрузка имеет уникальный корневой и промежуточный сертификат, управляемый сетью приложений.
• Упрощение операций. Сеть приложений обрабатывает выдачу сертификатов, смену и отзыв для пользователей.

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

Сеть приложений Azure Kubernetes предоставляет управление сертификатами, поддерживаемые Azure Key Vault, которая выдает и поддерживает сертификаты, используемые для MTLS. Эта служба устанавливает границу общего доверия для всех кластеров AKS, подключенных к одному ресурсу сети приложений.

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

На следующей схеме показана иерархия сертификатов в сети приложений, в которой показано, как корневой ЦС, промежуточные ЦС и сертификаты рабочей нагрузки структурированы для установления доверия между подключенными кластерами:

Иерархия сертификатов и жизненный цикл

При создании ресурса "Сеть приложений" корневой ЦС подготавливается в качестве привязки доверия для сети приложений. Когда кластер AKS присоединяется к сети приложений в качестве члена, сеть приложений выдает промежуточный сертификат для этого члена, подписанного корневым ЦС сети приложений. Каждый подключенный кластер AKS использует промежуточный сертификат, управляемый сетью приложений, для выдачи краткосрочных сертификатов рабочей нагрузки рабочим нагрузкам в этом кластере.

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

Из любого кластера-члена вы можете получить сертификат корневого Центра сертификации из конфигурационного mapa istio-root-cert в пространстве имен applink-system.

Типы сертификатов и периоды смены

Идентификация рабочих процессов и авторизация

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

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

Каждая рабочая нагрузка Сети приложений автоматически получает уникальное удостоверение в формате SPIFFE, которое включает её пространство имен и учетную запись службы. Идентификационные данные отформатированы следующим образом:

spiffe://cluster.local/ns/<namespace>/sa/<service-account>

Удостоверение встраивается в сертификат рабочей нагрузки и используется для подтверждения идентичности службы при установлении связи с другими рабочими нагрузками. Сеть приложений Azure Kubernetes использует эту модель идентификации на основе SPIFFE с политиками авторизации Istio, чтобы можно было определить четкие согласованные правила, для которых могут взаимодействовать службы.

Определение политик доступа

Вы можете использовать Istio AuthorizationPolicies для управления тем, какие рабочие нагрузки разрешены для обмена данными в вашей среде. Эти политики позволяют определять доступ на основе проверенных удостоверений рабочих процессов, а не сетевых местоположений или IP-адресов. Этот подход позволяет применять согласованные элементы управления доступом, даже если службы масштабируются и перемещаются по узлам. Например, можно разрешить вызывать службу только определенным шлюзам или рабочим нагрузкам из доверенных пространств имен, ссылаясь на их удостоверения SPIFFE в списке субъектов политики, как показано в следующем примере:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-gateway-to-app
  namespace: default
spec:
  selector:
    matchLabels:
      app: myApp
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/default/sa/myApp-gateway // see SPIFFE format above

Руководство по проектированию политик

При разработке политик авторизации следует учитывать следующие рекомендации.

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

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

Связанный контент

Дополнительные сведения о сети приложений Azure Kubernetes см. в следующих статьях:

• Архитектура сети приложений Azure Kubernetes
• Обзор наблюдаемости сети приложений Azure Kubernetes