[Перевод] Назад к микросервисам вместе с Istio. Часть 329.03.2019 11:19

bjj4oyjxqshrbjf5eks9sgsvbeg.png

Прим. перев.: Первая часть этого цикла была посвящена знакомству с возможностями Istio и их демонстрации в действии, вторая — тонко настраиваемой маршрутизации и управлению сетевым трафиком. Теперь же речь пойдёт про безопасность: для демонстрации связанных с ней базовых функций автор использует identity-сервис Auth0, однако по аналогии с ним могут настраиваться и другие провайдеры.

Мы настроили Kubernetes-кластер, в котором развернули Istio и пример микросервисного приложения Sentiment Analysis, — так были продемонстрированы возможности Istio.

С помощью Istio нам удалось сохранить небольшой размер сервисов, поскольку они не нуждаются в реализации таких «слоёв», как повторные попытки подключения (Retries), таймауты (Timeouts), автоматический выключатели (Circuit Breakers), трассировка (Tracing), мониторинг (Monitoring). Кроме того, мы задействовали техники продвинутого тестирования и деплоя: A/B-тестирование, зеркалирование и канареечные выкаты.

bsx7sci6cfghlpg8_crfjyutiuk.png

В новом материале мы разберёмся с финальными слоями на пути к business value: аутентификацией и авторизацией — и в Istio это сплошное удовольствие!

Аутентификация и авторизация в Istio


Никогда бы не поверил, что вдохновлюсь аутентификацией и авторизацией. Что же такого с технологической точки зрения может предложить Istio для того, чтобы сделать эти темы увлекательными и даже более того — чтобы они вдохновили и вас?

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

Звучит неплохо? Заглянем же внутрь!

Аутентификация с Auth0


В качестве сервера для управления идентификацией и доступом будем использовать Auth0, у которого есть пробная версия, который интуитивно понятен в использовании и попросту нравится мне. Впрочем, те же самые принципы можно применить и по отношению к любой другой реализации OpenID Connect: KeyCloak, IdentityServer и многим другим.

Для начала зайдите на Auth0 Portal со своим аккаунтом, создайте tenant (tenant — «арендатор», ­логическая единица изоляции, подробнее см. в документации — прим. перев.) и зайдите в Applications > Default App, выбрав Domain, как показано на скриншоте ниже:

1zx1irb-9tqksk6gd8eb0feubdm.png

Укажите этот домен в файле resource-manifests/istio/security/auth-policy.yaml (исходник): 

apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: auth-policy
spec:
  targets:
  - name: sa-web-app
  - name: sa-feedback
  origins:
  - jwt:
      issuer: "https://{YOUR_DOMAIN}/"
      jwksUri: "https://{YOUR_DOMAIN}/.well-known/jwks.json"
  principalBinding: USE_ORIGIN


Располагая таким ресурсом, Pilot (один из трёх базовых компонентов Control Plane в Istio — прим. перев.) настраивает Envoy’и на аутентификацию запросов перед тем, как перенаправлять их на сервисы: sa-web-app и sa-feedback. В то же самое время конфигурация не применяется к Envoy’ям сервиса sa-frontend, позволяя нам оставить фронтенд неаутентифицированным. Чтобы применить политику (Policy), выполните команду: 

$ kubectl apply -f resource-manifests/istio/security/auth-policy.yaml
policy.authentication.istio.io "auth-policy” created


Вернитесь на страницу и сделайте запрос — увидите, что он закончится статусом 401 Unauthorized. Теперь перенаправим пользователей фронтенда на аутентификацию с Auth0.

Аутентификация запросов с Auth0


Чтобы аутентифицировать запросы конечного пользователя, необходимо создать API в Auth0, который будет представлять аутентифицированные сервисы (reviews, details и ratings). Для создания API перейдите в Auth0 Portal > APIs > Create API и заполните форму:

96_gb5wcteuxtvt-yakzlsu4a4g.png

Важной информацией здесь является Identifier, который позже мы будем использовать в скрипте. Выпишем его себе так:

  • Audience: {YOUR_AUDIENCE}


Оставшиеся нужные нам детали расположены на Auth0 Portal в разделе Applications — выберите Test Application (создаётся автоматически вместе с API).

Здесь мы запишем:

  • Domain: {YOUR_DOMAIN}
  • Client Id: {YOUR_CLIENT_ID}


Прокрутите в Test Application до текстового поля Allowed Callback URLs (разрешённые URL’ы для callback’а), в котором мы укажем URL, куда должен отправляться вызов после того, как аутентификация завершена. В нашем случае это: 

http://{EXTERNAL_IP}/callback


А для Allowed Logout URLs (разрешённые URL’ы для разлогинивания) добавим: 

http://{EXTERNAL_IP}/logout


Перейдём к фронтенду.

Обновление фронтенда


Переключитесь на ветку auth0 репозитория [istio-mastery]. В этой ветке код фронтенда изменён так, чтобы перенаправлять пользователей в Auth0 для аутентификации и использовать JWT-токен в запросах к остальным сервисам. Последнее реализовано следующим образом (App.js): 

analyzeSentence() {
    fetch('/sentiment', {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json',
            'Authorization': `Bearer ${auth.getAccessToken()}` // Access Token
        },
        body: JSON.stringify({ sentence: this.textField.getValue() })
    })
        .then(response => response.json())
        .then(data => this.setState(data));
}


Чтобы перевести фронтенд на использование данных tenant’а в Auth0, откройте sa-frontend/src/services/Auth.js и замените в нём значения, которые мы записали выше (Auth.js): 

const Config = {
    clientID: '{YOUR_CLIENT_ID}',
    domain:'{YOUR_DOMAIN}',
    audience: '{YOUR_AUDIENCE}',
    ingressIP: '{EXTERNAL_IP}' // Используется для редиректа после аутентификации
}


Приложение готово. Укажите свой Docker ID в командах ниже при сборке и деплое произведённых изменений: 

$ docker build -f sa-frontend/Dockerfile \
 -t $DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0 \
 sa-frontend

$ docker push $DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0

$ kubectl set image deployment/sa-frontend \
 sa-frontend=$DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0


Попробуйте приложение! Вас перенаправят на Auth0, где необходимо залогиниться (или зарегистрироваться), после чего вас отправят обратно на страницу, с которой будут производиться уже аутентифицированные запросы. Если же вы попробуете упомянутые в первых частях статьи команды с curl — получите код 401 Status Code, сигнализирующий о том, что запрос не авторизован.

Сделаем следующий шаг — авторизуем запросы.

Авторизация с Auth0


Аутентификация позволяет нам понять, кем является пользователь, но для того, чтобы узнать, к чему у него есть доступ, требуется авторизация. Istio предлагает инструменты и для этого.

В качестве примера создадим две группы пользователей (см. на схеме ниже):

  • Пользователи (users) — с доступом только к сервисам SA-WebApp и SA-Frontend;
  • Модераторы (moderators) — с доступом ко всем трём сервисам.


01i-dccinr9i1aq81atcf_qze90.png
Концепция авторизации

Для создания этих групп воспользуемся расширением Auth0 Authorization и с помощью Istio предоставим им разные уровни доступа.

Установка и конфигурация Auth0 Authorization


На портале Auth0 перейдите к расширениям (Extensions) и установите Auth0 Authorization. После установки перейдите к Authorization Extension, а там — к конфигурации tenant’а по клику справа наверху и выбору соответствующей опции меню (Configuration). Активируйте группы (Groups) и нажмите на кнопку публикации правила (Publish rule).

qotz5nt8hpt0jcoyjav3rhkrn9g.png

Создание групп


В Authorization Extension перейдите в Groups и создайте группу Moderators. Поскольку мы будем рассматривать всех аутентифицированных пользователей как обычных, потребности в создании для них дополнительной группы нет.

Выберите группу Moderators, нажмите на Add Members, добавьте свой основной аккаунт. Оставьте некоторых пользователей без какой-либо группы, чтобы убедиться, что доступ для них запрещён. (Новых пользователей можно создать вручную через Auth0 Portal > Users > Create User.)

Добавьте Group Claim в Access Token


Пользователи добавлены в группы, однако эта информация должна быть отражена и в токенах для доступа. Чтобы соответствовать OpenID Connect и в то же время возвращать группы, которые нам нужны, токену потребуется добавлять свой custom claim. Реализуется через правила Auth0.

Для создания правила перейдите на Auth0 Portal к Rules, нажмите на Create Rule и выберите пустое правило из шаблонов.

k0v6diyfaeiftxaknnbfbnvfxq0.png

Скопируйте код ниже и сохраните его как новое правило Add Group Claim (namespacedGroup.js): 

function (user, context, callback) {
    context.accessToken['https://sa.io/group'] = user.groups[0];
    return callback(null, user, context);
}


Примечание: этот код берёт первую группу пользователя, определённую в Authorization Extension, и добавляет её в access-токен как custom claim (под своим пространством имён, как того требует Auth0).

Вернитесь к странице Rules и проверьте, что у вас есть два правила, записанные в следующем порядке:

  • auth0-authorization-extension
  • Add Group Claim


Порядок важен, потому что поле группы асинхронно получает правило auth0-authorization-extension и после этого добавляется как claim вторым правилом. В результате получается такой access-токен: 

{
 "https://sa.io/group": "Moderators",
 "iss": "https://sentiment-analysis.eu.auth0.com/",
 "sub": "google-oauth2|196405271625531691872"
 // [сокращено для наглядности]
}


Теперь необходимо настроить Envoy-прокси на проверку пользовательского доступа, для чего группа будет вытаскиваться из claim (https://sa.io/group) в возвращаемом access-токене. Это тема для следующего раздела статьи.

Конфигурация авторизации в Istio


Чтобы авторизация заработала, необходимо включить RBAC для Istio. Для этого воспользуемся следующей конфигурацией: 

apiVersion: "rbac.istio.io/v1alpha1"
kind: RbacConfig
metadata:
  name: default
spec:
  mode: 'ON_WITH_INCLUSION'                     # 1
  inclusion:
    services:                                   # 2
    - "sa-frontend.default.svc.cluster.local"
    - "sa-web-app.default.svc.cluster.local"
    - "sa-feedback.default.svc.cluster.local"


Пояснения:

  • 1 — включаем RBAC только для сервисов и пространств имён, перечисленных в поле Inclusion;
  • 2 — перечисляем список наших сервисов.

Применим конфигурацию такой командой: 

$ kubectl apply -f resource-manifests/istio/security/enable-rbac.yaml
rbacconfig.rbac.istio.io/default created


Теперь все сервисы требуют управления доступом на основе ролей (Role-Based Access Control). Другими словами, доступ ко всем сервисам запрещён и приведёт к ответу RBAC: access denied. Теперь разрешим доступ авторизованным пользователям.

Конфигурация доступа для обычных пользователей


Все пользователи должны иметь доступ к сервисам SA-Frontend и SA-WebApp. Реализуется с помощью следующих ресурсов Istio:

  • ServiceRole — определяет права, которые есть у пользователя;
  • ServiceRoleBinding — определяет, к кому эта ServiceRole относится.


Для обычных пользователей разрешим доступ к определённым сервисам (servicerole.yaml): 

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: regular-user
  namespace: default
spec:
  rules:
  - services: 
    - "sa-frontend.default.svc.cluster.local" 
    - "sa-web-app.default.svc.cluster.local"
    paths: ["*"]
    methods: ["*"]


А через regular-user-binding применим ServiceRole ко всем посетителям страницы (regular-user-service-role-binding.yaml): 

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: regular-user-binding
  namespace: default
spec:
  subjects:
  - user: "*"
  roleRef:
    kind: ServiceRole
    name: "regular-user"


Означает ли «все пользователи», что и неаутентифицированные пользователи получат доступ к SA WebApp? Нет, политика проверит валидность JWT-токена.

Применим конфигурации: 

$ kubectl apply -f resource-manifests/istio/security/user-role.yaml
servicerole.rbac.istio.io/regular-user created
servicerolebinding.rbac.istio.io/regular-user-binding created


Конфигурация доступа для модераторов


Для модераторов мы хотим включить доступ ко всем сервисам (mod-service-role.yaml): 

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: mod-user
  namespace: default
spec:
  rules:
  - services: ["*"]
    paths: ["*"]
    methods: ["*"]


Но мы хотим таких прав только для тех пользователей, в access-токене которых есть claim https://sa.io/group со значением Moderators (mod-service-role-binding.yaml): 

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: mod-user-binding
  namespace: default
spec:
  subjects:
  - properties:
      request.auth.claims[https://sa.io/group]: "Moderators"
  roleRef:
    kind: ServiceRole
name: "mod-user"


Применим конфигурации: 

$ kubectl apply -f resource-manifests/istio/security/mod-role.yaml
servicerole.rbac.istio.io/mod-user created
servicerolebinding.rbac.istio.io/mod-user-binding created


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

Заключение по этой части


Ну вот серьёзно: вы где-нибудь видели более простой, не требующий усилий, масштабируемый и безопасный подход к аутентификации и авторизации?

Всего лишь три ресурса Istio (RbacConfig, ServiceRole, and ServiceRoleBinding) потребовались для того, чтобы добиться тонкого контроля над аутентификацией и авторизацией доступа конечных пользователей к сервисам.

Вдобавок, мы вынесли заботу об этих проблемах из наших сервисов в envoy’и, добившись:

  • уменьшения количества типового кода, в котором могут оказаться проблемы безопасности и баги;
  • снижения количества глупых ситуаций, в которых один endpoint оказался доступным снаружи и забыл сообщить об этом;
  • устранения необходимости в обновлении всех сервисов при каждом добавлении новой роли или права;
  • того, что новые сервисы остаются простыми, безопасными и быстрыми.


Вывод


Istio позволяет командам сфокусировать свои ресурсы на важных для бизнеса задачах, не добавляя накладные расходы сервисам, возвращая их к статусу «микро».

Статья (в трёх частях) предоставила базовые знания и готовую практическую инструкцию для начала работы с Istio в реальных проектах.

P.S. от переводчика


Читайте также в нашем блоге:

© Habrahabr.ru