0

For my understanding in a Kerberos Architecture, a client needs to get a particular Ticket-Granting-Ticket (TGT) from the Authentication Server to be able to interact with a service. Those TGT contains:

  • client ID
  • client network address
  • ticket validity period
  • client/TGS session key.

I got this from here

Let's imagine I have a Master Workflow which contains: pig, hive and spark files I will need three different TGT, one per service, to use them all sucessfully.

One of the elements in the TGT is the ticket validity period. Let's imagine this is set to 8 hours.

For my understanding, if the master workflow needs, let's say, 10 hours to complete, it may fail after the 8th hour, since the validity of the ticket will be over.

So, as I understand, it will be necessary to refresh every 8 hours this TGT to communicate with the service without issues.

Now I was thinking as a possible approach to have a background process refreshing this TGT every 8 hours, so the client will have for any necessary service always a valid TGS session key.

A possible problem with this approach is that may be a gap between this refreshing, even a 30 seconds gap or 1 minute gap for any delay, which may cause the client being with an invalid TGS session key.

My question: Is it possible to refresh this TGS session key every 6 hours, which mean get a new TGT with the previous one is still valid? And what happens if you make this TGT request when an valid one still exists? is the old one replaced/descarted, are both stored in the client or is this new request just ignored?

I am completely new at this, so if there other ways to handle this issue please let me know.

Ignacio Alorre
  • 7,307
  • 8
  • 57
  • 94
  • 1
    Some confusion here. TGT = proof of identity. You need **one** to obtain **multiple service tickets**. – Samson Scharfrichter May 18 '18 at 19:22
  • 1
    For the record, the Java implementation of Kerberos uses the ticket cache for TGT but not for service tickets; these are always private to the JVM. Whereas the C implem uses the cache for both (e.g. Python can reuse a service ticket created by curl). Also, the Java implem does not create renewable tickets, nor can it renew existing tickets in cache. – Samson Scharfrichter May 18 '18 at 19:30
  • 1
    Finally, Hadoop has its own implem on top of the Java one -- cf. the GitBook _"Hadoop and Kerberos, the Madness beyond the Gate"_ by S. Loughran (HortonWorks). – Samson Scharfrichter May 18 '18 at 19:33
  • Thanks a lot @samson. Add this comments in an answer so I can upvote. After all it is valuable complementary information for the question – Ignacio Alorre May 19 '18 at 06:59
  • BTW you might also be interested by my answer to https://stackoverflow.com/questions/33211134/hbase-kerberos-connection-renewal-strategy/33243360#33243360 and Chris Nauroth's (ex-HortonWorks) answer to https://stackoverflow.com/questions/34616676/should-i-call-ugi-checktgtandreloginfromkeytab-before-every-action-on-hadoop – Samson Scharfrichter May 19 '18 at 12:23

1 Answers1

2

Yes, you can update your program to use this keytab rather than relying on a TGT to already exist in the cache. This is done by using the UserGroupInformation class from the Hadoop Security package.

val configuration = new Configuration
configuration.addResource("/etc/hadoop/conf/hdfs-site.xml")
UserGroupInformation.setConfiguration(configuration)

UserGroupInformation.getCurrentUser.setAuthenticationMethod(AuthenticationMethod.KERBEROS)
UserGroupInformation.loginUserFromKeytabAndReturnUGI(
  "hadoop.kerberos.principal", " path of hadoop.kerberos.keytab file")
  .doAs(new PrivilegedExceptionAction[Unit]() {
    @Override
    def run(): Unit = {

      // logic

    }
  })

Above we specify the name of our service principal and the path to the keytab file we generated. As long as that keytab is valid our program will use the desired service principal for all actions, regardless of whether or not the user running the program has already authenticated and received a TGT.

Kishore
  • 5,761
  • 5
  • 28
  • 53