Search code examples
hadoopcurlkerberoswebhdfskeytab

When using --negotiate with curl, is a keytab file required?

The documentation describing how to connect to a kerberos secured endpoint shows the following:

curl -i --negotiate -u : "http://<HOST>:<PORT>/webhdfs/v1/<PATH>?op=..."

The -u flag has to be provided but is ignored by curl.

Does the --negotiate option cause curl to look for a keytab that was created beforehand with the kinit command, or will curl prompt for credentials?

If it looks for a keytab file, what filename will the command be looking for?

Solution

  • Being a once-in-a-while-contributor to curl in that area. Here is what you need to know:

    curl(1) itself knows nothing about Kerberos and will not interact neither with your credential cache nor your keytab file. It will delegate all calls to a GSS-API implementation which will do the magic for you. What magic depends on the library, Heimdal and MIT Kerberos.

    Based on your question, I assume that you have little knowledge about Kerberos and want simply automate API calls to a REST endpoints secured by SPNEGO.

    Here is what you need to do:

    1. Have a Unix-like OS
    2. Install at least MIT Kerberos 1.11
    3. Install at least curl 7.38.0 against MIT Kerberos
    4. Verify this with curl --version mentioning GSS-API and SPNEGO and with ldd linked against your MIT Kerberos version.
    5. Create a client keytab for the service principal with ktutil or mskutil
    6. Try to obtain a TGT with that client keytab by kinit -k -t <path-to-keytab> <principal-from-keytab>
    7. Verify with klist that you have a ticket cache

    Environment is now ready to go:

    1. Export KRB5CCNAME=<some-non-default-path>
    2. Export KRB5_CLIENT_KTNAME=<path-to-keytab>
    3. Invoke curl --negotiate -u : <URL>

    MIT Kerberos will detect that both environment variables are set, inspect them, automatically obtain a TGT with your keytab, request a service ticket and pass to curl. You are done.

    Note: this will not work with Heimdal.