nomes principais do Kerberos para serviços distribuídos

2

Dois formulários típicos para os principais nomes do Kerberos (v5) parecem ser:

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

Eu também vi algo assim para serviços que podem existir em várias portas:

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

Eu tenho um aplicativo interno que agora está sendo kerberizado e gostaria de entender como o (s) diretor (es) de serviço deve (m) ser nomeado (s). O serviço é distribuído, com várias instâncias em execução em cada uma das várias máquinas em cada um dos vários subdomínios.

Por exemplo, digamos que meu nome de domínio seja zombo.com e meu serviço Kerberized, "tenaciousd", seja executado em máquinas "www1 "através de" www5 ". Além disso, cada máquina tem dez instâncias em portas conhecidas, digamos 25001 a 25010.

Portanto, tenho cinquenta instâncias do servidor, todas basicamente iguais, o que me permite equilibrar a carga, implantar novas versões gradualmente e assim por diante.

Agora, como devo nomear o (s) diretor (es) de serviço no Kerberos? Deveria haver um para cada host executando o serviço, como haveria no que parece ser a forma mais comum?

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

Ou é melhor praticar (e por que) ter uma entidade de serviço por instância de serviço?

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

Por fim, que tal ter apenas uma entidade de serviço, que parece mais simples, mas menos comumente feita?

[email protected]

Se for importante, o serviço Kerberized (e clientes) usa Cyrus SASL, GNU GSSAPI e MIT Kerberos 5. A API SASL usa um parâmetro "nome de domínio totalmente qualificado" além do nome do serviço, mas suspeito que seja porque suporta mais do que apenas o Kerberos, e provavelmente poderíamos passar outras coisas além dos FQDNs reais.

A maior parte da documentação que encontrei pressupõe que cada serviço seja executado em um único host em um domínio, ou pelo menos que os clientes se importem com a instância de serviço à qual se conectam. No meu caso, os serviços são praticamente os mesmos da perspectiva do cliente, então qual seria a melhor prática aqui?

    
por John Zwinck 24.01.2010 / 18:59

1 resposta

2

Para coisas que não são exclusivas (ou seja, serviços replicados, executando exatamente as mesmas tarefas), geralmente compartilho um princípio de servidor comum. Isso funciona bem se entidades externas visualizarem o mesmo nome de domínio, por exemplo, por manter essa ilusão.

Isso também significa que, se um usuário alternar da instância 1 para a instância 49, ele não precisará executar outro handshake do Kerberos, pois ele já tem um ticket de trabalho válido. Eles usarão esse tíquete para autenticar em qualquer uma das instâncias sem precisar buscar um novo por instância.

Assim, eu usaria:

tenaciousd/[email protected]

como seu nome principal para este serviço, assumindo que www.example.com é como esse serviço é tratado pelos clientes.

    
por 24.01.2010 / 20:24

Tags