Понимание Istio AuthN и authz для Кубернетс Стручки - PullRequest
Новая
       37

Понимание Istio AuthN и authz для Кубернетс Стручки

0 голосов
/ 06 февраля 2020

Я немного озадачен использованием Istio с EKS. У нас есть 2 пружинных загрузочных микросервиса, один из которых является поставщиком услуг REST, а другой - потребителем. Мы хотим реализовать Authn и authz, используя Istio.

Для этого: 1. На стороне службы провайдера: у меня есть VirtualService, правило назначения (заявляющее, что режим TLS должен быть ISTIO_MUTUAL для входящего трафика c ), AuthorizationPolicy, которая в основном вносит в белый список учетные записи клиентов. У меня также есть AuthenticationPolicy, как показано ниже: 

apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
  name: $APP_NAME-$FEATURE_NAME-authenticationpolicy
  namespace: $NAME_SPACE
spec:
  targets:
  - name: "$APP_NAME-$FEATURE_NAME"
  peers:
  - mtls:
      mode: STRICT

Насколько я понимаю, эта политика не разрешает входящий трафик c, не являющийся mtls.

Теперь у меня есть сомнения, что как настроить мой клиентский модуль для отправки всех исходящих трафика mtls c. Я понимаю, что должен создать ServiceAccount, который занесен в белый список на стороне провайдера, с использованием политики Authz. Меня больше беспокоит мой клиентский модуль, поскольку я не уверен, как включить MTL на уровне стручка. К вашему сведению, я не хочу включать mtls на уровне пространства имен. Я хочу сделать это на уровне модуля с помощью файла yaml.

Правильно ли мое понимание использования правила назначения, политик Authn и Authz? Правильно ли, что правило назначения, политики Authn и Authz должны быть на уровне поставщика услуг? А клиент просто должен включить MTLS для успешной работы связи? Я был go через документацию Istio, но здесь у меня есть сомнения

Ответы [ 2 ]

1 голос
/ 07 февраля 2020

Насколько я понимаю, эта политика не разрешает входящий трафик c, не являющийся mtls.

Это правда, если вы устанавливаете режим tls в строгий, то клиентский сертификат должен быть представленным, соединение в TLS.

Меня больше беспокоит мой клиентский модуль здесь, так как я не уверен, как включить mtls на уровне модуля.

Есть хорошая статья о том, как заставить это работать, особенно часть

Настройка mTLS для одного соединения между двумя службами

Поскольку Bookinfo - это Hello World of Istio, я собираюсь использовать это для объяснения того, как настроить mTLS от страницы продукта до сервиса подробностей, как показано в приведенном выше фрагменте графика.

В этом есть две части :

Установите Политику, чтобы сообщить Подробности, что он хочет получить трафик TLS c (только): 

apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: details-receive-tls
spec:
  targets:
  - name: details
  peers:
  - mtls: {}
Установите DestinationRule, чтобы сообщить клиентам (на странице продукта), чтобы они говорили на TLS с деталями: 
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: details-istio-mtls
spec:
  host: details.bookinfo.svc.cluster.local
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL

Ниже приведено графическое представление задействованных служб и где предыдущий применяются два документа конфигурации.

enter image description here

Теперь, когда вы внимательно посмотрите на приведенную выше Политику, вы увидите и введите для аутентификации однорангового узла 

peers:
- mtls: {}

Это означает, что проверка TLS является строгой, и Istio (или, скорее, прокси-серверу в модуле) требуется TLS traffi c и действительный сертификат. Мы можем передать флаг, чтобы получить разрешающий режим: 

peers:
- mtls: 
    mode: PERMISSIVE

Правильно ли, что правило назначения, политики Authn и Authz должны быть на уровне поставщика услуг?

Насколько я знаю, да.

А клиент просто должен включить MTLS для успешной работы связи?

Я не уверен насчет этого, поскольку MTLS работает внутри меня sh, это зависит от требований вашего приложения.

Я хочу сделать это на уровне модуля с помощью файла yaml.

Имеется ссылка на документацию istio об аутентификации, которая включает

И еще один из github

Или вы можете расширить определение вашего шлюза для поддержки взаимного TLS. Измените учетные данные входного шлюза, удалив его секрет и создав новый. Сервер использует сертификат CA для проверки своих клиентов, и мы должны использовать имя cacert для хранения сертификата CA. Вы можете использовать cert-manager для генерации сертификата клиента.

Я нашел несколько учебных пособий, которые могут оказаться полезными, ознакомьтесь с ними.

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

0 голосов
/ 17 февраля 2020

Спасибо JT97. Это то, что я реализовал

1) Для проверки подлинности я применил политику проверки подлинности Istio STRICT для входящих запросов, для которых должен быть включен MTLS. Citadel должен позаботиться о том, чтобы определить клиента и поставщика услуг, являются ли они теми, кого, по их утверждению, основывают на своих сертификатах.

2) Для авторизации я создал учетную запись службы в клиенте и добавил политику авторизации на серверная часть для внесения в белый список только тех учетных записей служб, для которых я хочу использовать свои ресурсы REST (PUT POST et c)

3) Одна вещь, которую я настроил по-другому, - это правило назначения. В идеале это должно быть на стороне клиента, где клиент говорит, что я заявляю, что мое правило назначения для пункта назначения провайдера таково. То, что я сделал, объявило правило назначения на стороне провайдера, чтобы оно сообщалось Istio me sh, что это готово с ISTIO_MUTUAL. Объявление правила назначения на стороне провайдера, по моему мнению, не имеет никакого значения.

4.) Я объявил правило назначения на уровне пространства имен. Теперь нужно проверить, есть ли клиенты, приходящие извне пространства имен но внутри меня sh.

...