У меня есть приложение Python, развернутое на EKS (Elastic Kubernetes Service). Это приложение сохраняет большие файлы в корзине S3 с помощью AWS SDK для Python (boto3). И кластер EKS, и корзина S3 находятся в одном регионе.
Мой вопрос: как по умолчанию осуществляется связь между двумя службами (EKS и S3)? Общаются ли обе службы напрямую и внутри через сеть Amazon, или они взаимодействуют извне через Интернет?
Если они общаются через Интернет, есть ли пошаговое руководство по установлению прямого внутреннего соединения между обеими службами?
AWS не будет поддерживать базовый пакет.
Если вы не видите ссылки в комментариях ниже, соответствующие ссылки: docs.aws.amazon.com/eks/latest/userguide/… и aws.github.io/aws-eks-best-practices/security/docs/iam.
Вы можете добавить доступ S3 к своей роли IAM узла EKS, эта ссылка показывает, как добавить доступ к реестру ECR к роли IAM узла EKS, но это то же самое для S3.
Другой способ — сделать переменные среды доступными в вашем контейнере, см. эта ссылка, хотя я бы рекомендовал первый способ.
Вы даете разрешение узлам, а не модулям, я не уверен, что это сработает. Я рекомендую использовать IRSA: https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html
и ему потребуется конечная точка s3 vpc для внутренней связи.
это то, что я сказал, цитируя: «Вы можете добавить доступ S3 к своей роли IAM узла EKS»
Вы проверили это? Создайте модуль busybox или awscli и получите объект из S3.
Я этого не делаю. Вы предоставляете такое разрешение, и если оно работает, все модули могут получить доступ к этому S3. Где безопасность?
Это ваше решение, и я предоставил лучшее.
Предоставление вашим модулям доступа к роли IAM вашего узла является серьезной проблемой безопасности. Если вы выберете этот подход, все модули и службы в вашем кластере будут иметь одинаковые разрешения IAM. aws.github.io/aws-eks-best-practices/security/docs/iam
Мой первый ответ был на точный вопрос. Мой второй - альтернативный.
Вы не совсем ясно выразились в своем ответе. Даже при повторном чтении кажется, что вы рекомендуете изменить роль узла, чтобы разрешить поду доступ к S3 (что даже не сработает, если вы будете следовать руководству по передовым методам). Рекомендации для статических ключей доступа не намного лучше.
пришлите мне "руководство по лучшим практикам", которому вы следуете, пожалуйста.
Ах, теперь я знаю, вы были от парней; вы запускаете все свои развертывания в одном пуле узлов?
how is communication between the two services (EKS and S3) handled by default?
По умолчанию топология сети вашего EKS предлагает маршрут к общедоступному AWS S3 конечные точки.
Do both services communicate directly and internally through the Amazon network, or do they communicate externally via the Internet?
Ваш кластер должен иметь сетевой доступ к указанным общедоступным конечным точкам AWS S3. Например, рабочие узлы, работающие в общедоступной подсети, или использование шлюза NAT в частной подсети.
...is there a step by step guide on how to establish a direct internal connection between both services?
Вы создаете конечные точки VPC для S3 в VPC, в котором работает ваш EKS, чтобы гарантировать, что сетевое взаимодействие с S3 останется в сети AWS. Конечные точки VPC для S3 поддерживают оба типа интерфейс и шлюз. Попробуйте этот статья, чтобы узнать об основных конечных точках S3, вы можете использовать тот же метод для создания конечных точек в VPC, где работает ваш EKS. Затем запрос к S3 от ваших модулей будет использовать конечную точку для обращения к S3 в сети AWS.
Это похоже на вопрос, на который техническая поддержка aws должна ответить вам как клиенту.