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]

Adding WEB-INF/lib/* to the JVM-level classpath fixes the immediate issue but potentially reintroduces the same classloader duplication pattern for any jar that exists in both ews/lib/* and WEB-INF/lib/*. Could you check if there's any overlap between the two directories in the assembled KMS package? Ideally the two classpaths should be disjoint — otherwise we may just be shifting the LinkageError to a different class down the line

[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.