Как настроить istio для объединения сетей без обнаружения служб?

Question

Я хочу соединить несколько сеток вместе. В настоящее время я управляю 3 разными кластерами AKS

• Операции (aks-ops-euwest-1)
• Постановка (aks-stg-euwest-1)
• Производство (акс-прод-еувест-1)

У меня есть Hashicorp Vault, работающий на Operations, я бы хотел получить доступ, например. Postgres, работающий в промежуточной и производственной среде, с использованием istio mTLS (для автоматической ротации секретов).

Каждый из кластеров запускает istio (Multi-Primary) в разных сетях. Каждый кластер имеет разные ClusterName, MeshID, TrustDomain и NetworkID. Хотя cacertsсекреты настраиваются с помощью общего корневого центра сертификации

Из , что для обеспечения взаимодействия необходимо развернуть специальный документации istio следуетфайлмежкластерного . TlsMode - это.

Это переменные среды для Eastwestgateway.

      # sni-dnat adds the clusters required for AUTO_PASSTHROUGH mode
- name: ISTIO_META_ROUTER_MODE
  value: "sni-dnat"
# traffic through this gateway should be routed inside the network
- name: ISTIO_META_REQUESTED_NETWORK_VIEW
  value: aks-ops-euwest-1

Я не хочу включать автоматическое обнаружение служб путем обмена секретами между кластерами. Почему? Потому что мне нужен точный контроль над тем, какие сервисы будут отображаться между сетками. Я хочу указать AuthorizationPolicies которые указывают на сервисные учетные записи из удаленных кластеров (из-за разных доменов доверия)

Например:

      # production cluster
kind: AuthorizationPolicy
spec:
  selector:
    matchLabels:
      app: postgres
  rules:
  - from:
      source:
        - principal: spiffe://operations-cluster/ns/vault/sa/vault

Это из документации istio

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

• Не обменивайтесь удаленными секретами между кластерами. Это обеспечивает самую сильную изоляцию между кластерами.
• Используйте VirtualService и DestinationRule, чтобы запретить маршрутизацию между двумя версиями служб.

В документации istio не указано, как включить межкластерный обмен данными в случае, когда секреты не передаются. При обмене секретами istiod создаст дополнительную конфигурацию посланника, которая позволит модулям прозрачно общаться через eastwestgateway. Но в нем не указано, как создавать эти конфигурации вручную, когда секреты не передаются.

TlsMode - это AUTO_PASSTHROUGH. Глядя на репозиторий istio

          // Similar to the passthrough mode, except servers with this TLS
    // mode do not require an associated VirtualService to map from
    // the SNI value to service in the registry. The destination
    // details such as the service/subset/port are encoded in the
    // SNI value. The proxy will forward to the upstream (Envoy)
    // cluster (a group of endpoints) specified by the SNI
    // value. This server is typically used to provide connectivity
    // between services in disparate L3 networks that otherwise do
    // not have direct connectivity between their respective
    // endpoints. Use of this mode assumes that both the source and
    // the destination are using Istio mTLS to secure traffic.
    // In order for this mode to be enabled, the gateway deployment
    // must be configured with the `ISTIO_META_ROUTER_MODE=sni-dnat`
    // environment variable.

Интересная часть The destination details such as the service/subset/port are encoded in the SNI value.

Похоже, что при совместном использовании секретов между кластерами istio добавит конфигурации посланников, которые будут эффективно кодировать эти службы / подмножества / порты в значение SNI кластера посланников. Хотя, когда секреты не разглашаются, как мы можем добиться того же результата?

Я просмотрел этот репозиторий , но он устарел и не использует eastwestgateway.

Я также задавал вопросы на форуме istio здесь и здесь , но получить помощь оттуда сложно.

Answer 1

В моей компании мы работаем над концепцией федерации Service Mesh, основанной на следующих моментах:

• Используйте частный центр сертификации для выдачи сертификатов для «клиентского» кластера k8s и «провайдерского» кластера k8s. Эти сертификаты не обязательно использовать во время установки istio. Таким образом, можно использовать любые подходящие сертификаты для установки istio, а затем генерировать новые сертификаты из общего частного центра сертификации для использования специально с ячеистой федерацией (для установки на входных и выходных шлюзах).
• Настройте вход mtls для кластера k8s «провайдера», как описано здесь: https://istio.io/latest/docs/tasks/traffic-management/ingress/secure-ingress/#configure-a-mutual-tls-ingress- шлюз, используйте сертификат общего частного центра сертификации для настройки шлюза.
• Настройте источник исходящего трафика mtls для «клиентского» кластера k8s, как описано здесь: https://istio.io/latest/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/#deploy-a-mutual-tls-server используйте сертификат общего частного центра сертификации для настройки шлюза.
• Используйте внешнюю базу данных/реестр для хранения «разрешенных» записей межсервисного соединения.
• Используйте внешний пользовательский интерфейс и API, чтобы позволить «клиентам» запрашивать новое соединение между службами и позволить «поставщикам» утверждать такой запрос. После утверждения запись о каждой услуге в базе данных помечается как «одобренная». (Предполагая, что кластеры «клиент» и «поставщик» принадлежат и управляются разными командами.)
• Используйте некоторую внешнюю автоматизацию в «клиентском» кластере K8s для получения «утвержденных» записей из базы данных и соответственно настройки объектов istio в этом кластере (запись службы, выходной шлюз, виртуальные службы, правила назначения).
• Используйте некоторую внешнюю автоматизацию в кластере K8s «поставщика», чтобы получить «одобренные» записи из базы данных и соответственно настроить объекты istio в этом кластере (входящий шлюз, виртуальный сервис).
• Используйте политику авторизации, чтобы явно разрешить только определенным клиентам/сертификатам подключаться к входу в кластер k8s «поставщика» и запретить любые другие сертификаты (в частности, другие сертификаты, выданные тем же частным центром сертификации) — описано здесь https:// my.f5.com/manage/s/article/K21084547

Конфигурацию, возможно, потребуется скорректировать, когда мы добавим в федерацию больше «поставщиков» и «клиентов».

В результате мы получаем совершенно отдельные кластеры и отдельные сетки, которыми могут управлять разные команды, и мы позволяем сервисам (развернутым в кластерах) подключаться к сервисам в других кластерах, используя сертификаты от общего частного центра сертификации, и мы назовите это «ячеистой федерацией». Каждый кластер и каждый компонент могут работать отдельно и обновляться независимо. Нам не нужно перекрестно создавать какие-либо секреты в кластерах, как предлагается в руководстве по мультикластерам istio. В каждом кластере предоставляется или потребляется только ограниченное количество сервисов, поэтому влияние на производительность практически отсутствует из-за настройки ячеистой федерации. «Клиентские» службы в кластерах могут подключаться к службам «поставщика» по протоколу http, затем запрос перехватывается istio и отправляется на соответствующий входной хост httpS (т. е. кластер «поставщика»), а сертификат mtls включается в запрос. автоматически. Нет необходимости распространять сертификаты клиентским службам, поскольку они добавляются на выходные шлюзы. Учитывая, что мы можем сохранить «разрешительную» конфигурацию аутентификации istio, «клиентские» службы могут продолжать взаимодействовать с остальными службами в кластере, как и раньше, поэтому добавление новых служб в объединение ячеек должно быть простым, поскольку мы не нужно будет менять конфигурацию межсоединений на стороне клиента или провайдера.