@harlem X
What's a Keytab
Is a container to store Kerberos principal's keys. A key in terms of Kerberos can be some random bytes. You can use container to store a password for a user principal or a password (key) for a service principal.
Keytabs are cryptographic files containing an representation of the service and its long-term key.Keytabs are used to either de-crypt the Kerberos service ticket of a Service or user to an hadoop service or authenticate the service itself to another service on the network.
The permissions of the keytabs is usually 400 or 440 for services like (hdfs, hbase, ambari-qa, accumulo, and spnego). These keytabs are used by other services rather than just the owner for testing connectivity to the cluster, and other functions on startup. All of the other keytabs are only readable by the service account that owns the file and the group that owns the keytabs (hadoop) group, and should be reserved for service accounts.
What's a Kerberos service
Represents an application either acting as a client or as a server, it does not really matter which way. Such application may have own arrangement on how it runs (which UID/GID it uses on the operating system level) but it
is not important from Kerberos point of view because Kerberos is not responsible for the identity of your application (or user), it only deals with Kerberos principals and their keys.
Headless keytab
What you call 'headless keytab' is user principal keys. This already makes an assumption that you have a user principal that corresponds to certain POSIX user it will start services without prompting for password e.g(smokeuser,hdfs,hbase). Headless principals are not bound to a specific host or node, they have the syntax: - @ EXAMPLE.COM
For Example: Headless: hdfs-mycluster@EXAMPLE.COM
Service keytab
Service principal is something that does not need to be a POSIX user,they are mostly applications that have own arrangement on how they run on the OS level and need to interact with the Kerberized cluster.
Kerberos services have traditional meaning e.g there could be host/fqdn REALM service principal that 'represents' this host in Kerberos realm. The same service principal may be shared by several applications: for example, both SSSD and SSH daemon use host/fqdn REALM for own needs. SSSD uses it as a client when authenticating against IPA LDAP server using SASL GSSAPI, and SSH daemon uses host/fqdn REALM key to represent itself as a server to incoming SSH
clients using GSSAPI or Kerberos authentication methods. Service principals are bound to a specific service and host or node, they have the syntax: / @ EXAMPLE.COM
e.g: Service: nn/c6601.ambari.apache.org@EXAMPLE.COM
For example in FreeIPA it is recommended to create service principals to represent applications as they are not required to have global POSIX identity associated with them and they are usually running on a specific host. In addition, if they are accepting SASL GSSAPI authentication method to access themselves, a client application will usually build up a target principal based on the hostname they run on, e.g. HTTP/fqdn REALM for a web server running on the host fqdn. Thus, there is clear arrangement between client and server applications on what they expect from each other on Kerberos (or SASL GSSAPI) level.
User principals
For user principals you can store user's password in a 'headless keytab' to allow some impersonation of the user for certain needs but it is irrelevant from Kerberos level what identity is there, both service and user principals can equally be used at a client side to initiate authentication towards a server.
Script for generating headless keytabs
Generating a headless keytab uses the same utility using kadmin.local you just specify headless assuming you have already a POSIX see above.
kadmin: ktadd -k /etc/security/keytabs/solr-headless-keytab host/prodsolr.exmple.com
The above will generate solr-headless-keytab for host prodsolr
HTH
