Como um serviço pode autenticar outro que está registrado no Kerberos? No meu caso, ambos são de propriedade de contas de serviço diferentes, então eles não podem executar o kinit como um usuário comum pode, por exemplo, atualizando-o quando ele expira a cada 10 horas. Então, quando um serviço quer algo do outro, como ele obtém um tíquete Kerberos sem um TGT (tíquete de concessão de tíquete)?
Para ser mais específico, eu executo um servidor web Apache para fornecer acesso aos repositórios do Subversion. Sua conta de serviço e SPN (Service Principal Name) são registrados no Kerberos. Eu também executo um servidor Jenkins que às vezes precisa fazer checkout desses repositórios. Usuários comuns podem autenticar em ambos os servidores: no Apache somente após executar kinit e no Jenkins via LDAP. Como a conta de serviço Jenkins autentica no Apache para acessar um repositório do Subversion, já que ele não pode executar kinit a cada 10 horas, 24/7?
Isso parece similar, mas sem uma boa resposta. E o plugin Jenkins para Kerberos é para autenticar o usuário para Jenkins, não Jenkins para Apache. Há também essa solução obscura e obsoleta, mas não sei se ela se aplica mais. E a questão parece que deveria ser independente de qualquer servidor específico, apenas um servidor tentando autenticar para outro que está em Kerberos.
Elas podem – contas de serviço sempre podem atuar como contas de usuário (o que de fato são em primeiro lugar: o MIT Kerberos nem mesmo tem essa distinção, enquanto contas de serviço do Active Directory são apenas contas de usuário com um nome principal de serviço adicional atribuído a elas).
As credenciais padrão do Kerberos são simétricas, tanto no sentido de criptografia (elas agem como chaves de "criptografia simétrica" para AES/DES/RC4) quanto no sentido prático (um principal usa a mesma chave para adquirir e validar tickets).
(Na verdade, até o oposto é possível – tecnicamente, é possível obter tickets para uma conta de usuário mesmo sem que essa conta tenha um SPN – embora a implementação do Active Directory não permita isso, pois há certos riscos de segurança em permitir isso.)
Então, se você tem um principal de serviço com uma senha (em um servidor Windows) ou com um keytab (em um servidor Linux ou Java), essa senha/keytab pode ser usada para ambos os propósitos. Acredito que o Windows obterá automaticamente um TGT em nome do seu primeiro serviço assim que o Jenkins chamar o SSPI, e para servidores Linux você pode dar o keytab de serviço para
kinit
(ouk5start
ouKRB5_CLIENT_KTNAME
ou mesmogss-proxy
).A questão é baseada em suposições incorretas. Ele pode executar o kinit a cada 10 horas, 24/7.
Como já mencionado, no Linux você normalmente usaria um keytab para armazenar as credenciais no disco
kinit -k -t
(ou os outros 3 métodos) – embora se você preferir fornecer uma senha, isso também não o impedirá de fazê-lo – enquanto no Windows você faria o LSASS fazer isso automaticamente usando a "senha da conta de serviço" armazenada.