Kudu security considerations

Kudu includes security features that allow Kudu clusters to be hardened against access from unauthorized users.

Kudu uses strong authentication with Kerberos, and authorization with Ranger. Communication between Kudu clients and servers, and between servers to other servers, can be encrypted with TLS. Kudu also supports HTTPS on the web UI.

These security features should work seamlessly in Impala as well, as long as Impala’s user is given permission to access Kudu.

With support of JWT for authenticating Kudu clients and RPC forwarding through a TCP proxy, more options are available for deploying secure Kudu clusters. For example, you can deploy a secure (for example, Kerberised) Kudu cluster in an internal or firewalled network and allow Kudu clients running outside of the network to connect to the cluster by authenticating themselves through JWT to Kudu servers, where all the RPC traffic is forwarded through a TCP proxy. In such a deployment, all the communications between Kudu clients running outside of the internal network and the Kudu cluster running in the internal network are protected by TLS, where the clients are provided with the cluster's IPKI CA certificate to authenticate the server side they are communicating with.