Лучшая мультикластерная конфигурация для mTLS между приложениями - PullRequest
Новая
       80

Лучшая мультикластерная конфигурация для mTLS между приложениями

0 голосов
/ 28 января 2020

Я хочу настроить 2 кластера Kubernetes с мультикластером Istio, и я думаю об этих 2 вариантах:

  1. Реплицированные плоскости управления (https://istio.io/docs/setup/install/multicluster/gateways/)
  2. Общая плоскость управления (для одной сети) (https://istio.io/docs/setup/install/multicluster/shared-vpn/)

Я бы предпочел использовать дублированные плоскости управления по причинам доступности, но следующий вопрос возникает у меня помните: как в этом случае работает mTLS между приложениями?

Если 2 приложения одного кластера общаются друг с другом, а mTLS включен, я могу создать AuthorizationPolicy, например: 

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "allow-app-a"
  namespace: app-b
spec:
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/app-a/sa/default"]
    to:
    - operation:
        methods: ["GET"]

app-a идентифицируется по принципалу, предоставленному mTLS.

Если мы развернем мультикластер с реплицированными плоскостями управления (версия 1), у нас будет что-то вроде этого:

мультикластер с реплицированными плоскостями управления

Как идентифицируются приложения в другом кластере (cluster.global)? Весь трафик c проходит через шлюз, я предполагаю, что он никогда не будет читать принципал от исходного вызывающего абонента, он будет читать принципал из шлюза. Это правильно?

Есть ли способ решить эту проблему? Могу ли я получить реплицированные плоскости управления, но без развертывания шлюзов?

1 Ответ

0 голосов
/ 29 января 2020

Вы должны выбрать мультикластерную модель на основе ваших требований, а не наоборот. Согласно документации istio :

Модель общей плоскости управления (для одной сети) является самой простой и используется в основном как единое целое sh, охватывающее несколько кластеров.

Что касается реплицированной модели плоскостей управления, то она в основном используется для восстановления доступности и резервирования, когда у вас есть своего рода реплики вашего кластера и меня sh в нескольких регионах. Таким образом, вы можете добиться одинаковой конфигурации и политики в обоих кластерах. Его также можно использовать расширенным способом, как в здесь .

Istio документация суммирует реплицированную плоскость управления со следующим:

Используя шлюзы Istio, общий root CA и служебные записи, вы можете настроить один сервис Istio me sh для нескольких кластеров Kubernetes. После такой настройки traffi c может быть прозрачно перенаправлен на удаленные кластеры без какого-либо участия приложения. Хотя для этого подхода требуется определенный объем ручной настройки для удаленного доступа к службе, процесс создания записи службы может быть автоматизирован.

Что касается межкластерной связи и mTLS согласно документации :

Для межкластерной связи требуется взаимное соединение TLS между службами. Чтобы включить взаимную связь TLS между кластерами, Citadel каждого кластера будет настроен с промежуточными учетными данными CA, сгенерированными общим root CA. В качестве иллюстрации вы используете образец сертификата root CA, доступный в установке Istio в каталоге samples / certs.

Как работают приложения в другом кластере (cluster.global ) опознан?

По имени host, что приложения вводятся для обслуживания меня sh реестра. Вы можете использовать ServiceEntry объекты для настройки глобальной видимости сервисов. Вы можете найти пример здесь .

Одна из multi-me sh функция развертывания :

Ни одна из служб в me sh выставляются по умолчанию, владельцы me sh должны явно указать, какие службы предоставляются.

Весь трафик c проходит через шлюз Я предполагаю, что он никогда не будет читать принципал от исходного абонента, он будет читать принципал из шлюза. Это правильно?

Это зависит от вашей Gateway конфигурации. У вас может быть Входной шлюз без завершения TLS , который дает шлюзу команду пройти входящий трафик c КАК ЕСТЬ, без завершения TLS. Таким образом, адрес источника будет сохранен.

Можно ли получить реплицированные плоскости управления, но без развертывания шлюзов?

Нет, для многокластерной модели с реплицированными плоскостями управления в каждом кластере все еще имеет Gateways, которые используются для маршрутизации.

Надеюсь, это поможет.

...