Безопасный сетевой доступ к Kubernetes

В этой статье сравниваются сетевые режимы для Служба Azure Kubernetes (AKS) и Amazon Elastic Kubernetes Service (Amazon EKS). В этой статье описывается, как улучшить безопасность подключения к управляемому серверу API кластера AKS, а также различные варианты ограничения доступа к общедоступной сети.

Сетевые режимы Amazon EKS

С помощью Amazon Virtual Private Cloud (Amazon VPC) можно запустить ресурсы Amazon Web Services (AWS) в виртуальной сети, состоящей из общедоступных и частных подсетей или диапазонов IP-адресов в VPC. Общедоступная подсеть размещает ресурсы, которые должны быть подключены к Интернету, а частная подсеть размещает ресурсы, которые не подключены к общедоступному Интернету. Amazon EKS может подготавливать управляемые группы узлов как в общедоступных, так и в частных подсетях.

Управление доступом к конечным точкам позволяет настроить доступ к конечной точке сервера API из общедоступного Интернета или через VPC. EKS предоставляет несколько способов управления доступом к конечной точке кластера. Вы можете включить общедоступную конечную точку по умолчанию, частную конечную точку или обе конечные точки одновременно. Если включить общедоступную конечную точку, можно добавить ограничения маршрутизации без классов (CIDR), чтобы ограничить IP-адреса клиента, которые могут подключаться к общедоступной конечной точке.

Как узлы Amazon EKS подключаются к управляемому плоскостю управления Kubernetes, определяется параметром конечной точки, настроенным для кластера. Параметры конечной точки можно изменить в любое время через консоль Amazon EKS или API. Дополнительные сведения см. в разделе "Управление доступом к конечной точке кластера Amazon EKS".

Только общедоступная конечная точка

Предоставление плоскости управления через общедоступную конечную точку — это режим по умолчанию для новых кластеров Amazon EKS. Если включена только общедоступная конечная точка кластера, API Kubernetes, поступающие из Amazon VPC, например рабочий узел для управления взаимодействием с плоскостью, оставьте VPC, но не покидайте сеть Amazon. Для подключения узлов к плоскости управления они должны использовать общедоступный IP-адрес и маршрут к интернет-шлюзу или маршрут к шлюзу преобразования сетевых адресов (NAT), где они могут использовать общедоступный IP-адрес шлюза NAT.

Общедоступные и частные конечные точки

Если включены общедоступные и частные конечные точки, api Kubernetes из VPC взаимодействует с плоскостью управления через управляемые Amazon EKS интерфейсы эластичных сетевых интерфейсов (ENIs) в VPC. Сервер API кластера доступен из Интернета.

Только частная конечная точка

Если включена только частная конечная точка, весь трафик на сервер API кластера, например команды kubectl или helm, должен поступать из VPC кластера или подключенной сети. Общедоступный доступ к серверу API из Интернета отключен. Этот режим доступа можно реализовать с помощью виртуальной частной сети AWS (AWS VPN) или AWS DirectConnect к VPC. Чтобы ограничить доступ к конечной точке без VPN AWS или DirectConnect, можно добавить ограничения CIDR в общедоступную конечную точку, чтобы ограничить подключения без настройки дополнительных сетей.

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

• подключенной сети: подключите сеть к VPC с шлюзом транзитного шлюза AWS или другими параметрами подключения , а затем используйте компьютер в подключенной сети. Необходимо убедиться, что группа безопасности плоскости управления Amazon EKS содержит правила для разрешения входящего трафика через порт 443 из подключенной сети.
• узле бастиона Amazon EC2: вы можете запустить экземпляр Amazon EC2 в общедоступную подсеть в VPC кластера, а затем войти через SSH в этот экземпляр, чтобы запустить команды kubectl. Дополнительные сведения см. в узлах бастиона Linux в AWS. Необходимо убедиться, что группа безопасности плоскости управления Amazon EKS содержит правила, позволяющие входящего трафика через порт 443 от узла бастиона. Дополнительные сведения см. в разделе Просмотр требований к группе безопасности Amazon EKS для кластеров. При настройке kubectl для узла бастиона обязательно используйте учетные данные AWS, которые уже сопоставлены с конфигурацией RBAC кластера, или добавьте субъект IAM, что бастион будет использоваться в конфигурацию RBAC перед удалением общедоступного доступа конечной точки. Дополнительные сведения см. в статье Предоставление доступа пользователей и ролей IAM к API Kubernetes и Несанкционированный доступ или доступ к.
• интегрированной среды разработки AWS Cloud9 IDE: AWS Cloud9 — это облачная интегрированная среда разработки (IDE), которая позволяет создавать, запускать и отлаживать код только в браузере. Вы можете создать интегрированную среду разработки AWS Cloud9 в VPC кластера и использовать интегрированную среду разработки для взаимодействия с кластером. Дополнительные сведения см. в статье Создание среды в AWS Cloud9. Необходимо убедиться, что группа безопасности плоскости управления Amazon EKS содержит правила, позволяющие входящего трафика через порт 443 из группы безопасности интегрированной среды разработки. Дополнительные сведения см. в разделе Просмотр требований к группе безопасности Amazon EKS для кластеров. При настройке kubectl для интегрированной среды разработки AWS Cloud9 обязательно используйте учетные данные AWS, которые уже сопоставлены с конфигурацией RBAC кластера, или добавьте субъект IAM, который среда разработки будет использовать в конфигурацию RBAC перед удалением общедоступного доступа к конечной точке. Дополнительные сведения см. в статье Предоставление доступа пользователей и ролей IAM к API Kubernetes и Несанкционированный доступ или доступ к.

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

Сетевой доступ AKS к серверу API

Существует два варианта защиты сетевого доступа к API Kubernetes в AKS, частном кластере AKS или авторизованных диапазонах IP-адресов.

Частный кластер AKS

частный кластер AKS гарантирует, что сетевой трафик между сервером API и узлами агента остается в виртуальной сети. В частном кластере AKS уровень управления или сервер API имеют внутренние IP-адреса, определенные в документе RFC1918 — выделение адресов для частного интернета документа. Используя частный кластер, вы можете гарантировать, что сетевой трафик между сервером API и пулами узлов остается только в частной сети.

В частном кластере AKS сервер API имеет внутренний IP-адрес, доступный только через частную конечную точку Azure , расположенную в той же виртуальной сети. Любая виртуальная машина в той же виртуальной сети может приватно взаимодействовать с плоскостем управления через эту частную конечную точку. Уровень управления или сервер API размещается в управляемой Azure подписке, а кластер AKS и пулы узлов находятся в подписке клиента.

При подготовке частного кластера AKS AKS по умолчанию создает частное полное доменное имя с частной зоной DNS и дополнительным общедоступным полным доменным именем с соответствующей записью A в общедоступной DNS Azure. Узлы агента продолжают использовать запись A в частной зоне DNS, чтобы разрешить частный IP-адрес частной конечной точки для связи с сервером API.

На следующей схеме показана частная конфигурация кластера AKS.

Скачайте файл Visio для этой архитектуры.

Чтобы подготовить частный кластер AKS, поставщик ресурсов AKS создает полное доменное имя (FQDN) для группы ресурсов узла в частной зоне DNS. При необходимости AKS также может создать общедоступное полное доменное имя с соответствующей записью адреса (A) в общедоступной зоне DNS Azure. Узлы агента используют A запись в частной зоне DNS для разрешения IP-адреса частной конечной точки для связи с сервером API.

Поставщик ресурсов AKS может создать частную зону DNS в группе ресурсов узла или создать частную зону DNS и передать его идентификатор ресурса в систему подготовки. Вы можете создать частный кластер при использовании Terraform с Azure, Bicep, шаблонами ARM, Azure CLI, модулем Azure PowerShell или REST API Azure для создания кластера.

Вы можете включить общедоступное полное доменное имя для сервера API во время подготовки или с помощью команды az aks update с --enable-public-fqdn параметром в существующих кластерах. Если вы включите общедоступное полное доменное имя, любая виртуальная машина, которая обращается к серверу, например локально размещенный агент Azure DevOps или локальный GitHub Actions, должна находиться в той же виртуальной сети, где размещен кластер, или в сети, подключенной через пиринг виртуальной сети или VPN типа "сеть — сеть".

Для частного кластера AKS отключите общедоступное полное доменное имя сервера API. Чтобы взаимодействовать с частной плоскостей управления, виртуальная машина должна находиться в одной виртуальной сети или в одноранговой виртуальной сети с подключением виртуальной сети к частной зоне DNS. Запись A в частной зоне DNS разрешает полное доменное имя сервера API на IP-адрес частной конечной точки, который взаимодействует с базовой плоскостей управления. Дополнительные сведения см. в статье Создание частного кластера службы Kubernetes Azure.

Варианты развертывания частного кластера

Поставщик ресурсов AKS предоставляет следующие параметры для настройки развертывания частного кластера AKS:

• authorizedIpRanges (string) задает допустимые диапазоны IP-адресов в формате CIDR.
• disableRunCommand (Boolean) указывает, следует ли отключить run команду для кластера.
• enablePrivateCluster (Boolean) указывает, следует ли создавать кластер как закрытый.
• enablePrivateClusterPublicFQDN (Boolean) указывает, следует ли создавать другое общедоступное полное доменное имя для частного кластера.
• privateDnsZone (string) указывает частную зону DNS в группе ресурсов узла. Если значение не указано, поставщик ресурсов создает зону. Можно указать следующие значения:
  • По умолчанию устанавливается значение System.
  • None по умолчанию используется общедоступный DNS, поэтому AKS не создает частную зону DNS.
  • <Your own private DNS zone resource ID> использует частную зону DNS, созданную в формате privatelink.<region>.azmk8s.io или <subzone>.privatelink.<region>.azmk8s.io.

В следующей таблице показаны параметры конфигурации DNS для развертывания частного кластера AKS:

Подключение к частному кластеру и управление ими

В частном кластере AKS конечная точка сервера API не имеет общедоступного IP-адреса. Существует несколько вариантов установления сетевого подключения к частному кластеру:

1. Создайте виртуальную машину в той же виртуальной сети, что и кластер AKS, используя команду az vm create с флагом --vnet-name.
2. Используйте виртуальную машину в отдельной виртуальной сети и настройте пиринг между виртуальными сетями с виртуальной сетью кластера AKS.
3. Настройте Azure ExpressRoute или VPN- для подключения к виртуальной сети кластера.
4. Создайте подключение частной конечной точки Azure в другой виртуальной сети.
5. Используйте экземпляр Cloud Shell, развернутый в подсети, подключенной к серверу API для кластера.

С помощью Azure CLI можно использовать команду az aks az aks command invoke для доступа к частным кластерам без необходимости настройки VPN или Express Route. Эта команда позволяет удаленно вызывать команды, такие как kubectl и helm, в частном кластере через API Azure, не подключаясь напрямую к кластеру. Чтобы использовать command invoke, необходимо иметь необходимые разрешения для действий Microsoft.ContainerService/managedClusters/runcommand/action и Microsoft.ContainerService/managedclusters/commandResults/read.

На портале Azure можно использовать функцию Run command для выполнения команд в частном кластере. Эта функция фактически использует функции command invoke для выполнения команд в кластере. Модуль pod, созданный функцией Run command, предоставляет средства kubectl и helm для управления кластером. Кроме того, он поддерживает Bash с такими инструментами, как jq, xargs, grepи awk доступны.

Вы можете использовать Бастион Azure в одной виртуальной сети или одноранговой виртуальной сети для подключения к виртуальной машине управления прыжками. Бастион Azure — это полностью управляемая платформа как услуга (PaaS), которая позволяет подключаться к виртуальной машине с помощью браузера и портал Azure. Бастион Azure обеспечивает безопасный и простой протокол удаленного рабочего стола (RDP) или подключение к виртуальной машине Secure Shell (SSH) через tls непосредственно из портал Azure. Если виртуальные машины подключаются через Бастион Azure, они не нуждаются в общедоступном IP-адресе, агенте или специальном клиентском программном обеспечении.

Интеграция виртуальной сети сервера API

Кластер службы Azure Kubernetes (AKS), настроенный с помощью интеграции серверной виртуальной сети API, проектирует конечную точку сервера API непосредственно в делегированную подсеть в виртуальной сети, где развертывается AKS. Интеграция виртуальной сети СЕРВЕРА API обеспечивает сетевое взаимодействие между сервером API и узлами кластера, не требуя приватного канала или туннеля. Сервер API доступен за виртуальным IP-адресом внутренней подсистемы балансировки нагрузки в делегированной подсети, которую узлы настроены для использования. С помощью интеграции виртуальной сети сервера API можно гарантировать, что сетевой трафик между сервером API и пулами узлов остается только в частной сети.

Уровень управления или сервер API находится в управляемой AKS подписке Azure. Кластер или пул узлов находится в подписке Azure. Сервер и виртуальные машины, составляющие узлы кластера, могут взаимодействовать друг с другом через IP-адрес сервера API и IP-адреса pod, которые проецируются в делегированную подсеть.

Интеграция виртуальной сети СЕРВЕРА API поддерживается для общедоступных или частных кластеров. После подготовки кластера можно добавить или удалить общедоступный доступ. В отличие от интегрированных кластеров без виртуальной сети, узлы агента всегда взаимодействуют напрямую с частным IP-адресом внутреннего IP-адреса сервера API-сервера внутренней подсистемы балансировки нагрузки (ILB) без использования DNS. Весь узел к серверу API хранится в частной сети, и для сервера API для подключения к узлам не требуется туннель. Клиенты вне кластера, нуждающиеся в обмене данными с сервером API, могут сделать это обычно, если доступ к общедоступной сети включен. Если доступ к общедоступной сети отключен, следует следовать той же методике настройки частного DNS, что и стандартные частные кластеры. Дополнительные сведения см. в статье Создание кластера службы Azure Kubernetes с помощью интеграции виртуальных сетей API Server.

Авторизованные диапазоны IP-адресов

Второй вариант повышения безопасности кластера и минимизации атак на сервер API — использовать авторизованные диапазоны IP-адресов. Авторизованные IP-адреса ограничивают доступ к плоскости управления общедоступного кластера AKS известному списку IP-адресов и CIDR. При использовании этого параметра сервер API по-прежнему предоставляется публично, но доступ ограничен. Дополнительные сведения см. в разделе "Безопасный доступ к серверу API", используя авторизованные диапазоны IP-адресов в Служба Azure Kubernetes (AKS).

Следующая az aks update команда Azure CLI разрешает диапазоны IP-адресов:

 az aks update \
     --resource-group myResourceGroup \
     --name myAKSCluster \
     --api-server-authorized-ip-ranges  73.140.245.0/24

Рекомендации по подключению AKS

При рассмотрении возможности подключения AKS следует учитывать несколько важных аспектов. Ниже приведены некоторые ключевые моменты, которые следует учитывать:

• Частный кластер AKS обеспечивает повышенную безопасность и изоляцию по сравнению с авторизованными IP-адресами. Однако невозможно преобразовать существующий общедоступный кластер AKS в частный кластер. Вместо этого авторизованные IP-адреса можно включить для любого существующего кластера AKS.
• Разрешенные диапазоны IP-адресов нельзя применить к конечной точке частного сервера API. Они применяются только к общедоступному серверу API.
• Частные кластеры не поддерживают агенты, размещенные в Azure DevOps. Вместо этого рекомендуется использовать локальные агенты.
• Чтобы реестр контейнеров Azure функционировал с частным кластером AKS, для реестра контейнеров в виртуальной сети кластера необходимо настроить приватный канал. Кроме того, пиринг можно установить между виртуальной сетью реестра контейнеров и виртуальной сетью частного кластера.
• Ограничения службы Приватного канала Azure применяются к частным кластерам.
• Если частная конечная точка в подсети клиента частного кластера удаляется или изменяется, кластер перестанет функционировать.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Основные авторы:

• Паоло Сальватори | Инженер основной службы
• Мартин Gjoшевски | Старший инженер службы
• Лора Николас | Старший архитектор облачных решений

Другие участники:

• Чад Киттель | Главный инженер программного обеспечения
• Эд Прайс | Старший диспетчер программ содержимого
• Теано Питерсен | Технический писатель

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

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

• AKS для специалистов Amazon EKS
• Управление удостоверениями и доступом Kubernetes
• Мониторинг и ведение журнала Kubernetes
• Параметры хранилища для кластера Kubernetes
• Управление затратами для Kubernetes
• Управление узлами и пулом узлов Kubernetes
• Управление кластерами

Связанные ресурсы

Следующие ссылки содержат ссылки на примеры документации и автоматизации для развертывания кластеров AKS с защищенным API:

• Создание частного кластера AKS с общедоступной зоной DNS
• Создание частного кластера Служба Azure Kubernetes с помощью Terraform и Azure DevOps
• Создание общедоступного или частного кластера Служба Azure Kubernetes с помощью шлюза NAT Azure и Шлюз приложений Azure
• Использование частных конечных точек с частным кластером AKS
• Общие сведения о Приватный канал Azure
• Общие сведения о защищенной сетевой инфраструктуре с помощью безопасности сети Azure