Kerberos auth for CTA Frontend

Could you please clarify a couple of things with regards the Kerberos authorization needed by the CTA Frontend node (in our case it has also the cta-cli package installed)?

What exactly should be the exact service principle in /etc/cta/cta-frontend.krb5.keytab? In the K8s test instance, this keytab looks like

slot KVNO Principal


1 1 cta/cta-frontend@TEST.CTA
2 1 cta/cta-frontend@TEST.CTA
3 1 cta/cta-frontend@TEST.CTA

I thought the naming scheme for a service principal is service/hostname@realm but I can’t relate this to the above.

With regards the ctaadmin keytab, I understand that this is for authorising CTA admin commands sent to the Frontend but I cant understand how is it related with the ctafrontend service principal. Because “kinit -kt ctaadmin1.keytab ctaadmin1@TEST.CTA” results in the following credentials cache.

Default principal: ctaadmin1@TEST.CTA

Valid starting Expires Service principal
02/11/2021 20:59:43 02/12/2021 20:59:43 krbtgt/TEST.CTA@TEST.CTA
02/11/2021 20:59:53 02/12/2021 20:59:43 cta/cta-frontend@TEST.CTA

Many thanks,

George

Hi George,
Your setup is consistent, in that the credential cache you quote indicates that user ctaadmin1@TEST.CTA holds credentials for cta/cta-frontend@TEST.CTA, allowing you to access the frontend, which has kerberos identity cta/cta-frontend@TEST.CTA using credentials in /etc/cta/cta-frontend.krb5.keytab. Check cta-frontend-xrootd.conf for further details.
Cheers,
Oliver.

Hi Oliver,

Thanks a lot for your reply; it is really helpful!

Is the actual name of the service principal (krb5 identity) of the CTA frontend arbitrary or
follows a certain naming scheme like service/host@realm where “service” is the actual
name of the (systemd?) name of the service (cta-frontend)?

George

Hi,
The name of the service principal must follow the usual kerberos format but is otherwise arbitrary.
Cheers,
Oliver.