anchor.diff:  establish initial trust with the Kudu master, and then use alternate credentials
   for subsequent connections. In particular, the master will issue internal
   X.509 certificates to servers, and temporary authentication tokens to clients.
  +
  +== Coarse-Grained Authorization
  +
  +Kudu supports coarse-grained authorization of client requests based on the
  +authenticated client Kerberos principal (i.e. user or service). The two levels
  +of access which can be configured are:
  +
  +* *Superuser* - principals authorized as a superuser are able to perform
  +certain administrative functionality such as using the `kudu` command line tool
  +to diagnose or repair cluster issues.
  +
  +* *User* - principals authorized as a user are able to access and modify all
  +data in the Kudu cluster. This includes the ability to create, drop, and alter
  +tables as well as read, insert, update, and delete data.
  +
  +NOTE: Internally, Kudu has a third access level for the daemons themselves.
  +This ensures that users cannot connect to the cluster and pose as tablet
  +servers.
  +
  +Access levels are granted using whitelist-style Access Control Lists (ACLs), one
  +for each of the two levels. Each access control list either specifies a
  +comma-separated list of users, or may be set to `*` to indicate that all
  +authenticated users are able to gain access at the specified level. See
  +<<configuration>> below for examples.
  +
  +NOTE: The default value for the User ACL is `*`, which allows all users access
  +to the cluster. However, if authentication is enabled, this still restricts access
  +to only those users who are able to successfully authenticate via Kerberos.
  +Unauthenticated users on the same network as the Kudu servers will be unable
  +to access the cluster.
   
   == Encryption
   
  
positive.code: since traffic from these connections is never exposed externally. This allows
  locality-aware compute frameworks like Spark and Impala to avoid encryption
  overhead, while still ensuring data confidentiality.
  
  == Coarse-Grained Authorization
  
  Kudu supports coarse-grained authorization of client requests based on the
  authenticated client Kerberos principal (i.e. user or service). The two levels
  of access which can be configured are:
  
  * *Superuser* - principals authorized as a superuser are able to perform
  certain administrative functionality such as using the `kudu` command line tool
  to diagnose or repair cluster issues.
  
  * *User* - principals authorized as a user are able to access and modify all
  data in the Kudu cluster. This includes the ability to create, drop, and alter
  tables as well as read, insert, update, and delete data.
  
  NOTE: Internally, Kudu has a third access level for the daemons themselves.
  This ensures that users cannot connect to the cluster and pose as tablet
  servers.
  
  Access levels are granted using whitelist-style Access Control Lists (ACLs), one
  for each of the two levels. Each access control list either specifies a
  comma-separated list of users, or may be set to `*` to indicate that all
  authenticated users are able to gain access at the specified level. See
  <<configuration>> below for examples.
  
  NOTE: The default value for the User ACL is `*`, which allows all users access
  to the cluster. However, if authentication is enabled, this still restricts access
  to only those users who are able to successfully authenticate via Kerberos.
  Unauthenticated users on the same network as the Kudu servers will be unable
  to access the cluster.
  
  [[web-ui]]
  == Web UI Encryption
  
negative.code: Once authenticated, you use the same client code to read from and write to Kudu
  servers with and without Kerberos configuration.
  
  === Scalability
  
  Kudu authentication is designed to scale to thousands of nodes, which requires
  avoiding unnecessary coordination with a central authentication authority (such
  