RANGER-5530: Fix for KMS API not working in docker kerberos env

[vikaskr22]

Ranger-KMS APIs (including dev_kms TestConnection) were breaking due to authentication & authorisation error after kerberos implementation in Docker env.

This PR contains fix for following:

1. Enabled KMS to run in kerberos: KMS uses kms-site.xml in it's authentication flow, not core-site.xml. So included kms-site.xml with correct config.
2. Updated KDC entrypoint to generate HTTP.keytab for KMS , It is required for SPNEGO.
3. Corrected hadoop_auth_local rule as per kerberos principal
4. Updated dev_kms KMS URL connection
5. Fixed Class loading errors due to duplicate jars being added in ews/lib & WEB-INF/lib

After kerberos fix, it was throwing following error:

2026-06-09 07:19:48,155 ERROR [http-nio-9292-exec-9] o.a.c.c.C.[.[.[.[webservices-driver] (DirectJDKLog.java:170) - Servlet.service() for servlet [webservices-driver] in context with path [] threw exception [org.glassfish.jersey.server.ContainerException: java.lang.NoClassDefFoundError: Could not initialize class org.apache.ranger.plugin.util.JsonUtilsV2] with root cause
java.lang.ExceptionInInitializerError: Exception java.lang.LinkageError: loader constraint violation: loader 'app' wants to load class com.fasterxml.jackson.databind.ObjectMapper. A different class with the same name was previously loaded by org.apache.catalina.loader.ParallelWebappClassLoader @54336c81. (com.fasterxml.jackson.databind.ObjectMapper is in unnamed module of loader org.apache.catalina.loader.ParallelWebappClassLoader @54336c81, parent loader 'app') [in thread "http-nio-9292-exec-3"]
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017)
………………………………………
………………………………………
at org.apache.ranger.plugin.util.JsonUtilsV2.<clinit>(JsonUtilsV2.java:34)
at org.apache.hadoop.crypto.key.kms.server.KMSJSONWriter.writeTo(KMSJSONWriter.java:61)
at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.invokeWriteTo(WriterInterceptorExecutor.java:242)
at ……………..
…………………………..
at org.glassfish.jersey.internal.Errors.process(Errors.java:244)

As per my analysis, it happened due to duplicate jackson-*:jar jars available inside distro/kms.xml . Once inside "ews/webapp/WEB-INF/lib/" and once inside "ews/lib".

RCA: "ranger-common-utils" was part of "ews/lib" and Jackson jars were part of both moduleSets. JsonUtilsV2.java tries to load com.fasterxml.jackson.databind.ObjectMapper . It's part of Jackson jars and it was already loaded by another class loader. That is, once it gets loaded by the app loader, then the webapp loader tries to load it again → loader constraint violation → JsonUtilsV2 cannot initialize.

Fix: : Removed ranger-common-utils dependency & Jackson-*.jar from ews/lib and added ranger-common-utils inside "ews/webapp/WEB-INF/lib/".

How was this patch tested?

-mvn build is working

• setup docker env locally, KMS is UP & running.
• dev_kms Test connection is working now
• Zone key creation , rollover , delete etc. is working.

[vyommani]

The fix makes sense moving ranger-common-utils to WEB-INF/lib eliminates the dual classloader loading of Jackson. A couple of things worth verifying:

1--> Are there any other jars remaining in the ews/lib moduleSet that are also present in WEB-INF/lib? If so, we'd have the same loader constraint risk for those classes once WEB-INF/lib/* is added to the JVM classpath (see comment on kms/scripts/ranger-kms).

2--> Is there anything in the KMS startup lifecycle that runs before the webapp classloader is active and depends on ranger-common-utils? Since it's no longer in ews/lib, it won't be available at the JVM level until Tomcat loads the webapp

[vyommani]

@pradeepagrawal8184 could you weigh in on this? I think you'd have better insight into whether the classpath overlap is actually a concern here. Check my other comment as well.

[vikaskr22]

@vyommani , I have addressed the concern you raised. I have added the required dependency to be loaded by the same class loader where it is required. Earlier JsonUtils2 was being loaded by one loader and dependent jar was being loaded by another loader. Now this would not be the case.

Pls review one more time. Thanks.