Интеграция Istio с AWS IAM

В настоящее время я изучаю возможность запуска кластера Istio / Kubernetes на AWS с использованием EKS. Я хотел бы иметь возможность назначать разные роли IAM для каждой службы, работающей в кластере, чтобы ограничить привилегии AWS для каждой службы.

В кластерах, не относящихся к Istio Kubernetes, эта возможность предоставляется такими проектами, как kube2iam, но это не кажется идеальным в мире Istio, поскольку kube2iam полагается на iptables правила, а Istio уже использует iptables правила для перенаправления всего исходящего трафика на сопроводительный элемент Envoy.

В документации по безопасности Istio говорится, что модель идентификации обслуживает различные базовые реализации, а в AWS эта реализация Я:

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

Идентификаторы сервисов Istio на разных платформах:

Kubernetes: сервисный аккаунт Kubernetes
GKE / GCE: может использовать сервисный аккаунт GCP
GCP: сервисный аккаунт GCP
AWS: пользовательский / ролевой аккаунт AWS IAM

Но я не встречал какой-либо дополнительной документации о том, как назначать роли IAM для Istio ServiceRoles .

Кто-нибудь нашел решение этого?

ОБНОВЛЕНИЕ: см. IRSA


kubernetes istio amazon-web-services amazon-iam
person AEldridge    schedule 10.10.2018    source источник
comment
Обновление: с тех пор AWS решила эту проблему с помощью Роли IAM для учетных записей служб.   -  person AEldridge    schedule 18.02.2021

Ответы (2)


arrow_upward
1
arrow_downward

Я тоже борюсь с этим и не нашел никакой помощи. Я добился успеха с предложением этого человека https://groups.google.com/forum/m/#!topic/istio-users/3-fp2JPb2dQ

Мне не удавалось заставить kube2iam работать, пока я не добавил эту службу (см. Ниже или перейдите по ссылке)

В основном вы добавляете это

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: apipa
spec:
  hosts:
  - 169.254.169.254
  ports:
  - number: 80
    name: http
    protocol: HTTP
  resolution: DNS
  location: MESH_EXTERNAL

Посмотрев на сопроводительный файл istio-proxy перед применением serviceentry, вы могли бы увидеть в журнале множество ошибок 404 с путями, похожими на вызовы aws api. После служебного ввода те превратились в 200.

ОБНОВЛЕНИЕ .... Позже я узнал, что это ожидаемое требование при использовании istio для любой связи с внешней сеткой. См. https://istio.io/docs/concepts/traffic-management/#service-entries

person A. Stappenbeck    schedule 19.12.2018

arrow_upward
1
arrow_downward

Конфигурация Istio позволяет исключить некоторые диапазоны IP-адресов из прокси https://istio.io/docs/tasks/traffic-management/egress/egress-control/#direct-access-to-external-services

Таким образом, если вы добавите global.proxy.excludeIPRanges: "169.254.169.254/32" в конфигурацию istio, все запросы к IP-адресу метаданных AWS не будут обрабатываться istio, а будут отправляться напрямую на этот IP-адрес.

Это позволит применить правило kube2iam iptables.

ср. https://github.com/istio/istio/issues/9297#issuecomment-516353921

person gdupin    schedule 08.10.2019