JWT authentication for Kudu

JSON Web Token (JWT) authentication is a standard way of securely transmitting signed information between two parties. Learn how Kudu clients can use JWT to authenticate to a Kudu cluster.

JWT is a compact, URL-safe mechanism of representing claims to be transferred between two parties (for example, Kudu server and Kudu client). The claims in a JWT token are encoded either as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext format of a JSON Web Encryption (JWE) structure. This encoding enables the claims to be digitally signed, integrity protected with a Message Authentication Code (MAC), and/or encrypted. The structure of JWT enables you to verify whether the content is tampered.

Kudu servers accept JWTs for authentication when run with the --enable_jwt_token_auth flag (by default, it is set to false). Correspondingly, all servers in a Kudu cluster should be able to access the JWT issuer's JSON Web Key Set (JWKS) to verify the JWTs presented to them by connecting clients. Kudu servers fetch JWKS from the location specified by the --jwks_url flag.

When to use JWT authentication

JWT authentication is an alternative to Kerberos authentication, and you can use it in situations where Kerberos authentication is not a viable option but authentication is required, as in the following examples,

A Kudu client runs on a node outside the Kerberos realm used in the cluster's internal network, and cross-realm authentication cannot be configured.
A Kudu client cannot access Kerberos servers in the Kudu cluster's internal network, but it can talk to those Kudu servers through a TCP proxy.
A Kudu client runs on a node without any Kerberos environment configured.

How JWT authentication works

In Kudu, a client sends a signed and non-encrypted JWT to the Kudu server when negotiating a new RPC connection between them. The JWTs are sent over communication channels protected by TLS. The Kudu servers check the validity of the JWTs by verifying their signatures. In its turn, a Kudu client confirms the authenticity of a Kudu server by verifying the signature of the server's TLS certificate. So, for JWT-based authentication scenarios in Kudu, TLS certificates used by servers should be trusted by clients. If Kudu is deployed with its own certificate authority (that is a part of the Kudu's Internal Private Key Infrastructure, or IPKI), the Kudu's IPKI CA certificate should be added as trusted by using certain Kudu client API calls. For example, use KuduClientBuilder::trusted_certificate(const std::string&) in C++ Kudu applications to add a certificate in PEM format in the client's chain of trusted certificates. The Kudu's IPKI CA certificate can be retrieved from the /ipki-ca-cert HTTP/HTTPS endpoint of the embedded master's web server.