mTLS между двумя кластерами kubernetes - PullRequest
0 голосов
/ 29 февраля 2020

Я пытаюсь получить mTLS между двумя приложениями в двух кластерах kubernetes без способа, которым Istio делает это (с входным шлюзом), и мне было интересно, сработает ли следующее (для Istio, для Likerd, для Consul .. .).

Допустим, у нас есть кластер k8s A с приложением AA и кластер B с приложением BB, и я хочу, чтобы они связывались с mTLS.

  • Кластер A имеет С сертификатом letEncrypt для входного контроллера nginx и me sh (для любых целей) для его применения.
  • Кластер B имеет самоподписанный сертификат от нашего root CA.
  • Кластера A и Сетки службы B имеют разные сертификаты, подписанные нашим root CA.
  • Traffi c переходит от inte rnet к входному контроллеру кластера A (HTTPS), оттуда к приложению AA
  • После того, как traffi c попадает в приложение AA, это приложение хочет общаться с приложением BB
  • Приложения AA и BB имеют конечные точки, доступные через вход (используя свои контроллеры входа).
  • Сертификаты TLS заканчиваются в конечных точках d являются подстановочными знаками.

Как вы думаете, mTLS будет работать в этой ситуации?

Ответы [ 2 ]

1 голос
/ 02 марта 2020

В основном этот блог от portshift ответит на ваш вопрос.

Ответ зависит от того, как строятся ваши кластеры, потому что

Istio предлагает несколько вариантов разверните службу me sh в нескольких кластерах kubernetes, подробнее об этом здесь .

Итак, если у вас есть развертывание Single Me sh

Istio extension post

Вы можете развернуть один сервис me sh (плоскость управления) по полностью подключенной мультикластерной сети, и все рабочие нагрузки могут достигать друг друга напрямую без шлюза Istio, независимо от кластер, на котором они работают.


НО


Если у вас есть Multi Me sh Развертывание

A multi service mesh deployment over multiple clusters

При развертывании multi-me sh вы получаете большую степень изоляции и доступности, но это увеличивает сложность настройки. Сетки, которые в противном случае являются независимыми, слабо связаны друг с другом с помощью ServiceEntries, Ingress Gateway и используют общий root CA в качестве основы для безопасной связи. С сетевой точки зрения, единственное требование - чтобы входные шлюзы были доступны друг от друга. Каждый сервис в данном me sh, к которому требуется доступ, сервис в другом me sh требует конфигурации ServiceEntry в удаленном me sh.


В развертывании multi-me sh безопасность может усложняться по мере роста и диверсификации среды. Существуют проблемы безопасности при аутентификации и авторизации сервисов между кластерами. Локальный Mixer (политики служб и телеметрии) необходимо обновить с помощью атрибутов служб в соседних кластерах. В противном случае он не сможет авторизовать эти службы, когда они достигнут своего кластера. Для достижения этого каждый микшер должен знать об идентификаторах рабочей нагрузки и их атрибутах в соседних кластерах. Каждый Цитадель должен быть обновлен сертификатами соседних кластеров, чтобы разрешить соединения mTLS между кластерами.

Федерация гранулярных идентификаторов рабочих нагрузок (сертификаты mTLS) и атрибутов обслуживания через multi-me sh плоскостей управления может быть выполнена следующими способами:

  • Kubernetes Ingress: предоставление маршрутов HTTP и HTTPS извне кластера службам внутри кластера. Маршрутизация Traffi c контролируется правилами, определенными для ресурса Ingress. Вход может прекратить SSL / TLS и предложить виртуальный хостинг на основе имени. Тем не менее, ему требуется контроллер входа для выполнения правил входа
  • Service-me sh шлюз: Служба Istio me sh предлагает другую модель конфигурации Istio Gateway . Шлюз позволяет применять такие функции Istio, как мониторинг и правила маршрутизации, к трафику c, входящему в кластер. На входе g ateway описан балансировщик нагрузки, работающий на границе me sh, который получает входящие соединения HTTP / TCP. Он настраивает открытые порты, протоколы и т. Д. c. Маршрутизация Traffi c для входного трафика c настраивается вместо этого с использованием правил маршрутизации Istio, точно так же, как для внутренних запросов на обслуживание.

Как вы думаете, mTLS будет работать в этой ситуации?

На основании приведенной выше информации

  • Если у вас есть Single Me sh Развертывание

    Это должно возможно без проблем.

  • Если у вас есть Multi Me sh Deployment

    Это должно работать, но так как вы не хотите использовать istio gateway, тогда единственная опция kubernetes ingress .

Надеюсь, это ответит на ваш вопрос. Дайте мне знать, если у вас есть еще вопросы.

0 голосов
/ 01 мая 2020

Вы хотите, чтобы Консул Me sh Шлюзы . Это mTLS-сервис-связь между сервисами между объединенными кластерами Consul, развернутыми в разных центрах обработки данных, кластерах или средах выполнения.

...