Как включить Mutual TLS и gRPC TLS в Istio, чтобы Istio мог собирать метрики, но gRPC считал соединение безопасным

Это «принципиальный» вопрос, поскольку я пытаюсь понять, как mTLS реализован в Istio и как он работает с сервисами, которые в остальном хорошо поддерживают mTLS (например, gRPC).

Считайте, что у меня кластер с включенным "mtls везде". Это эффективно туннелирует все TCP-соединения по каналу mTLS между прокси-серверами envoy, а соединение между envoy и службой осуществляется в виде обычного текста.

Однако есть службы, требующие как минимум TLS-подключений к прокси-серверу envoy; в идеале соединения mTLS. Одним из них является gRPC, который требует TLS для использования своей базовой аутентификации JWT:

https://grpc.io/docs/guides/auth.html#authenticate-with-google

Итак, возникает вопрос:

  • Возможно ли, чтобы прокси-сервер посланника «отслеживал» соединения, которые в противном случае зашифрованы mTLS в самой исходной службе? В идеале с использованием сертификатов и ключей, предоставленных Citadel
  • Может ли решение создать новый метод аутентификации, который игнорирует тот факт, что он находится в открытом тексте, поскольку Istio будет использовать его по протоколу mTLS?

‹3 Ура


istio ssl grpc
person Andrew Howden    schedule 10.01.2019    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Одна из многих проблем, которые пытается решить Istio, - это переложить управление сертификатами с уровня приложения на дополнительный контейнер. Я лично не знаю, как использовать Citadel для управления сертификатами в контейнере приложения, поскольку для «отслеживания» вы можете попробовать что-то приготовить с помощью envoy filter, но даже если вы можете это сделать, это будет индивидуальное решение, которое легко сломается. Почему-то я не думаю, что это сработает или вообще возможно. Кажется, ваш первый вопрос / подход неверный.

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

Стоит отметить, что это пример использованной политики аутентификации.

apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
  name: {{ template "service.name" . }}
  labels:
    app: {{ template "service.name" . }}
    chart: {{ template "service.chart" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
spec:
  targets:
  - name: {{ template "service.name" . }}
  origins:
  - jwt:
      issuer: https://auth.company.com/
      jwksUri: https://auth-service.auth.svc.cluster.local:8008/keys/public
      audiences:
      - dGQVkdEluc3RhrmNps:CompanyApp:CompanyOrg
  principalBinding: USE_ORIGIN
person Filip Nikolov    schedule 20.02.2020