Securing Hadoop Clusters: Removing Passwords from XML Configs with Credential Provider API and JCEKS
One day in a Hadoop cluster, opening hive-site.xml revealed the metastore password stored in clear text. The file was readable by the entire hadoop group, multiple services, and dozens of engineers with cluster access. While formally a violation of basic security norms, this practice remains widespread.
Removing the password proved straightforward thanks to Hadoop’s built-in mechanism, yet it raised a deeper question: once the password disappeared from the config, where did it go, and did security actually improve?
Egor Ivshin, security analyst at Arenadata, is responsible for the security of the ADH product. His role involves identifying vulnerabilities through SCA, SAST, and manual testing, then working with development teams on remediation.
Origin of Secrets in Hadoop Configs
Components such as Hive, Spark, and HBase commonly store sensitive values including database passwords, encryption keys, and S3 tokens directly in XML files. Typical examples include javax.jdo.option.ConnectionPassword in hive-site.xml and AWS credentials in core-site.xml.
Historical tutorials, the need for rapid deployment, and simple inertia explain why clear-text storage persists. The result is uncontrolled proliferation of secrets across backups, developer laptops, and public repositories.
How Credential Provider API Works
The Credential Provider API lets applications request passwords from a provider rather than reading them from XML. When hadoop.security.credential.provider.path points to a JCEKS location, conf.getPassword() checks the keystore first. If the alias is absent and hadoop.security.credential.clear-text-fallback is false, the application fails instead of falling back to the XML value.
Not every component calls getPassword(); those using plain get() require either code changes or continued XML storage.
JCEKS Structure and Limitations
JCEKS is a Java keystore format that stores encrypted aliases. Hadoop supports jceks://file, localjceks://file, and jceks://hdfs URIs. HDFS storage simplifies synchronization and rotation for most services.
The format is locked to the PBEWithMD5AndTripleDES algorithm. Although NIST deprecated 3DES in 2018 and Sweet32 demonstrated practical collision attacks after 32 GB of data, the small size of keystore files keeps real-world risk low. Stronger algorithms require alternative formats or external secret managers such as OpenBao.
Protecting the Master Password
Security ultimately depends on the master password used to unlock the JCEKS file. Common approaches include environment variables, a dedicated password file with strict permissions (chmod 400), or relying on HDFS Transparent Data Encryption so no additional password is needed.
Environment variables are visible via /proc and core dumps. Password files can be placed on tmpfs but still require distribution and rotation across nodes.
Rotation and Automation in ADCM
Manual rotation involves creating a new JCEKS, updating permissions, and restarting services. Arenadata automates this via the “Manage credential encryption” action in ADCM. After execution, JCEKS files receive 640 permissions for local storage and 755 for HDFS paths, balancing security with operational requirements.
Alias names must exactly match the property names referenced in XML. The hadoop credential list command confirms stored aliases without revealing values.
Related articles
Security Week 2644: Active Exploitation of PHP2Shell Vulnerabilities Confirmed
PHP developers released patches for two critical vulnerabilities collectively known as PHP2Shell on October 20, affecting PHP 8.2 through 8.5 as well as older branches. The flaws allow unauthenticated remote code execution on affected servers, which power approximately 70 percent of websites. Despite expectations of immediate exploitation, confirmed attacks with working exploits only began on October 25. CrowdStrike noted technical difficulties in weaponizing the issues in real-world environments. Only one-fifth of top Russian websites had applied the fixes by October 25. Additional incidents included compromised eMudhra certificates, a critical GitLab flaw, and a 16-year-old Broadcom router vulnerability.
Positive Technologies Offers Up to 500,000 Rubles for Bypassing PT Application Firewall
Positive Technologies has expanded its Standoff Bug Bounty program to include rewards for bypassing its web application firewalls. Researchers can earn between 150,000 and 500,000 rubles for demonstrating practical bypasses against PT Application Firewall PRO and PT Application Firewall Cloud. The program targets the core protective mechanisms, including traffic filtering, attack detection rules, and the management layer used by administrators. Submissions must include reproducible attack scenarios that show how malicious requests can pass through undetected, rather than relying on scanner reports or theoretical findings. Reward amounts vary by severity and confirmed business impact, with critical issues in the PRO version paying up to 500,000 rubles. The company plans to use validated findings to strengthen detection rules and improve overall product resilience.
Tailscale SSH Vulnerability Allows Root Access via Unix Socket Redirection
A researcher identified flaws in Tailscale that let an attacker with existing SSH access on one node escalate to root privileges and move laterally across the network. Erica Windisch of Cyberdione Labs demonstrated the issues in lab conditions against Tailscale 1.104.2 and Headscale 0.29.5. The core problem stems from privileged operations performed by the tailscaled process when handling Unix socket redirection, granting an ordinary SSH session access to root-only resources. The researcher used the technique to interact with Docker and run elevated commands, and showed that broad access policies allow automated lateral movement in under a second. Additional issues include denial-of-service conditions and bypasses of certain restrictions. Recommendations include reviewing SSH policies and disabling unnecessary socket redirection, noting that Headscale 0.29.5 lacks an independent way to turn the feature off.
Critical CVE-2026-111497 Out-of-Bounds Write Flaw in Google Brotli Decoder Impacts Broad Range of Environments
A severe vulnerability has been identified in the Google-developed Brotli decoder used for decompressing data in web communications and other applications. The flaw, tracked as CVE-2026-111497, allows out-of-bounds writes when processing specially crafted compressed data, potentially enabling arbitrary code execution, information disclosure, or denial of service. It carries a CVSS v4.0 base score of 9.2 and is rated Critical. Google has released patched versions 1.2.1, 1.1.1, and 1.0.10 of the library. Node.js incorporated the fix in its updates, while Microsoft issued an out-of-band patch for .NET on October 25, 2026, to address the issue. The vulnerability affects any environment relying on the Brotli C implementation for data decompression.