Can you check what keytab your tablet servers are running with?
You can do that by logging in to one of the tablet server machines and checking the command line that kudu-tserver process is running with. Then check what's inside that keytab.
It's something like
[root@anonymous ~]# ps axw | grep kudu-tserver
548 pts/0 S+ 0:00 grep --color=auto kudu-tserver
32747 ? Sl 1:12 /opt/cloudera/parcels/CDH/lib/kudu/sbin/kudu-tserver
--rpc_authentication=required --rpc_encryption=required --keytab_file=/var/run/cloudera-scm-agent/process/580-kudu-KUDU_TSERVER/kudu.keytab --tserver_master_addrs=master.myhost.org --flagfile=/var/run/cloudera-scm-agent/process/580-kudu-KUDU_TSERVER/gflagfile
[root@anonymous ~]# klist -k /var/run/cloudera-scm-agent/process/580-kudu-KUDU_TSERVER/kudu.keytab
Keytab name: FILE:/var/run/cloudera-scm-agent/process/580-kudu-KUDU_TSERVER/kudu.keytab
If tablet servers are not runing or running without keytabs, or there is nothing in those keytabs, that might be the problem.
Anyway, I think there should be log files of Kudu tablet servers at those machines, by default they are in /var/log/kudu. Checking those logs might give you some ideas what to start the troubleshooting with.
There is documentation for how to enable Kudu security on CDH 5.13.0 here: https://www.cloudera.com/documentation/enterprise/5-13-x/topics/kudu_security.html#concept_syg_k35_l...
Please follow those steps and let us know if it still doesn't work for you.
It's this document that I followed to enable TLS/SSL and Kerberos.
I have this settings in Cloudera Manager
Is there something wrong ?
The 'ps' sample output from one your servers looks fine.
Just another question: I assume the 'superuser_acl' property in you CM configuration (that's blurred out) contains 'kudu' (or whatever you have for the Kudu service principal), right? If not, add that into the list.
Anyway, it's hard to say what's wrong looking at the configuration snippets and playing the 'guess what?' game. I would highly recommend following Will's advise on looking into the logs of master(s) and tablet servers for the error details. I think that will give you a firm starting point in troubleshooting the issue and save some time for everybody.
It seems in your case kudu service principals (like 'kudu/XXX1119.krj.gie@REALM') are not mapped into 'kudu' as expected, but into name of local users (like 'm-zhdp-s-hwefzjneur'). If I'm not mistaken, that's exactly https://issues.apache.org/jira/browse/KUDU-2198.
As a workaround, I can suggest to add --use_system_auth_to_local=false to the Kudu flags (both masters and tservers). If using CM, add that flag into the 'Kudu Service Advanced Configuration Snippet (Safety Valve) for gflagfile'.
Hope this helps.
Oh, sorry -- it seems you are at 5.13.0 and that flag is not available in that version yet (but it's present starting 5.14.0). I'm afraid you need either to introduce custom mappings for those kudu service principals (so they would be mapped into 'kudu') or upgrade to 5.14 or higher to get access to that flag. Setting superuser ACL to '*' would not allow tablet servers to register with masters anyway because of the following: