Как стать автором
Обновить

Комментарии 7

Спасибо большое за статью и за примеры использования.

Я бы хотел задать пару вопросов:

  • А почему выбрали метод DNS_PING, а не KUBE_PING

  • Снимаете ли вы метрики с WildFly и метрики самого Keycloak?

  • Есть опыт снятия метрик с Infinispan? Честно у меня так и не завелось.

  • Бывали ли у вас проблемы с таймаутами у infinispan? У меня были странные развалы кластера infinispan и пока проблема решилась только переключением на TCP с UDP.

  • livenessProbe/readinessProbe специально отсутствуют у Infinispan?

  • Бывали ли у вас проблемы с replicated cache у Infinispan? С режимом работы sync/async? Я пока перешел на sync из-за развала replicated cache.

  • А что это за IP-адреса в JAVA_OPTS ? -Djboss.default.multicast.address=230.0.0.5 -Djboss.modcluster.multicast.address=224.0.1.106

  • Тестировали ли вы реальную отказоустойчивость? Т.е. убивали ли поды Keycloak/Infinispan/Вырубали одну из нод в кластере. И как это все переживало эти тесты?

  • Проводили ли вы нагрузочное тестирование? Возможно есть какие-то утилиты для проведения таких тестов?

  • А точно ли это лучший способ? Может стоит заменить на корректный shutdown: jboss-cli.sh --connect command=':shutdown(timeout=30)'

Год назад мне очень помог этот репозиторий и соответствующая статья.

  • Тестировали ли вы реальную отказоустойчивость? Т.е. убивали ли поды Keycloak/Infinispan/Вырубали одну из нод в кластере. И как это все переживало эти тесты?

Поды - да, включали / выключали. С нодами - специально нет.

Про метрики. мы используем вот этот плагин: https://github.com/aerogear/keycloak-metrics-spi
И вот мой дашборд под них, который показывает всё, что нам нужно: https://grafana.com/grafana/dashboards/14607

Хорошо, а почему именно эти IP-адреса? Они во всех кластерах везде будут одинаковые? Если я захочу 2 Keycloak в кластер, они тоже будут одинаковые?

В дополнение спрошу, а почему не использовали JDBC_PING (про KUBE_PING уже спросили) и deployments.

Зачем modcluster в данной настройке, можно просто балансить по clusterip?

Multicast так же не нужен (он в большинстве инсталляций облаков\куберов не работает), все задачи jgroups выполняются на unicast.

Большое спасибо за статью! Очень интересно, ведь в русскоязычном интернете информации по keycloak в принципе не так много.
Если позволите, несколько «оффтоп»-вопрос по keycloak, как к более опытным специалистам в данном вопросе:

Пробую использовать keycloak в своем pet-проекте (пока больше в целях самообучения):
Развернул в докере: keycloak, postgries БД для него, nginx со статическим vue приложением и arangodb+foxx в качестве основной базы приложении и REST API к ней.

Стыковка Vue и Keycloak прошли без проблем — проверяется наличие актуального токена, если что кидается на форму авторизации, получаем оттуда токен обратно — дальше данные по пользователю получаю без проблем.

А вот дальше начались проблемы.
Я надеялся, что я полученный токен передам в свой REST API и там смогу его проверить — ну то есть уже со стороны серверного приложения внутри REST API дернуть какой-нибудь endpoint (например: auth/realms/{realm}/protocol/openid-connect/token/introspect или auth/realms/{realm}/protocol/openid-connect/userinfo) и подтвердив что он валидный и проверив доступы отдать пользователю то, что он просит.
Но ни один из перечисленных endpoint не хочет признавать мой токен валидным при обращении с серверной стороны REST API.

Так же пробовал делать валидацию без обращения к endpoint, но не смог найти рабочего решения под NodeJS для декодирования RS256, а keycloak только его сейчас и поддерживает насколько я понял.

Подскажите пожалуста:
  1. Могут ли токены передаваться между разными клиентами? Ну то есть сайт получивший токен на чистом клиенте, отдает его на сервер, где уже другой keycloak клиент должен проверить его валидность и получить данные по нему из keycloak? Возможен ли такой сценарий?
  2. Возможно нужно использовать и там и там реквизиты одного keycloak-клиента, но ведь по логике статическое веб-приложение должно быть клиентом c Access type = public, в то время, как серверное приложение должно быть bearer-only. Или я ошибаюсь?
  3. Выяснил, что если даже одним клиентом обращаться к keycloak по разным адресам, то корректный результат он отдает только при обращении на тот же адрес, по которому изначально авторизовывался. Поясню: при перенаправлении на форму авторизации с сайта идет обращение на публичный адрес, а когда обращаюсь с серверного приложения он доступен уже по внутреннему адресу, который от внешнего отличается. Опять же возможный ли это сценарий? И если да, то какие особенности настройки keycloak под это могут быть?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.