Две типичные формы имен основных участников 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 — это то, как клиенты обращаются к этой службе.