Основные имена Kerberos для распределенных служб

Основные имена Kerberos для распределенных служб

Две типичные формы имен основных участников Kerberos (v5) выглядят следующим образом:

username[/instance]@REALM
service/fully-qualified-domain-name@REALM

Я также видел что-то подобное для служб, которые могли существовать на нескольких портах:

service/fully-qualified-domain-name:port@REALM

У меня есть внутреннее приложение, которое сейчас проходит Kerberos, и я хотел бы понять, как следует называть принципала(ов) службы. Служба распределена, и на каждой из нескольких машин в каждом из нескольких поддоменов запущено несколько экземпляров.

Например, предположим, что мое доменное имя —zombo.com, а мой Kerberized сервис, "tenaciousd", работает на машинах "www1" - "www5". Кроме того, каждая машина имеет десять экземпляров на известных портах, скажем, с 25001 по 25010.

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

Теперь, как мне назвать принципал(ы) службы в Kerberos? Должен ли быть один для каждого хоста, работающего со службой, как это было бы в наиболее распространенной форме?

tenaciousd/[email protected]
tenaciousd/[email protected]
tenaciousd/[email protected]
tenaciousd/[email protected]
tenaciousd/[email protected]

Или лучше (и почему) иметь один принципал службы на экземпляр службы?

tenaciousd/www1.zombo.com:[email protected]
tenaciousd/www1.zombo.com:[email protected]
tenaciousd/www1.zombo.com:[email protected]
...
tenaciousd/www5.zombo.com:[email protected]

Наконец, как насчет наличия только одного принципала обслуживания, что кажется более простым, но встречается реже?

[email protected]

Если это имеет значение, то Kerberized-сервис (и клиенты) используют Cyrus SASL, GNU GSSAPI и MIT Kerberos 5. API SASL принимает параметр «полного доменного имени» в дополнение к имени сервиса, но я подозреваю, что это связано с тем, что он поддерживает не только Kerberos, и мы, вероятно, могли бы передавать и другие данные, помимо фактических FQDN.

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

решение1

Для вещей, которые не являются уникальными (то есть реплицированных служб, выполняющих точно такие же обязанности), я обычно разделяю один общий серверный принципал. Это хорошо работает, если внешние сущности видят, например, одно и то же доменное имя, поскольку это поддерживает эту иллюзию.

Это также означает, что если пользователь переключается с instance-1 на instance-49, ему не придется выполнять еще одно рукопожатие Kerberos, поскольку у него уже есть действительный рабочий билет. Он будет использовать этот билет для аутентификации в любом из экземпляров без необходимости получать новый билет для каждого экземпляра.

Таким образом, я бы использовал:

tenaciousd/[email protected]

в качестве основного имени для этой службы, предполагая, что www.example.com — это то, как клиенты обращаются к этой службе.

Связанный контент