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
When to use JWT authentication
- 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
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
HTTP/HTTPS endpoint of the embedded master's web server.