[HADOOP-15997] KMS client uses wrong UGI after HADOOP-14445

• Type: Bug
• Status: Resolved
• Priority: Blocker
• Resolution: Fixed
• Affects Version/s: 3.2.0, 3.0.4, 3.1.2
• Fix Version/s: 3.2.0, 3.3.0, 3.1.2
• Component/s: kms

Environment

Hadoop 3.0.x (CDH6.x), Kerberized, HDFS at-rest encryption, multiple KMS

• Hadoop Flags: Reviewed
• Assignee: Wei-Chiu Chuang
• Reporter: Wei-Chiu Chuang
• Created: 11/Dec/18 14:03
• Updated: 02/Oct/19 17:14
• Resolved: 04/Jan/19 16:22

Description

After HADOOP-14445, KMS client always authenticates itself using the credentials from login user, rather than current user.

2018-12-07 15:58:30,663 DEBUG [main] org.apache.hadoop.crypto.key.kms.KMSClientProvider: Using loginUser when Kerberos is enabled but the actual user does not have either KMS Delegation Token or Kerberos Credentials

The log message "Using loginUser when Kerberos is enabled but the actual user does not have either KMS Delegation Token or Kerberos Credentials" is printed because KMSClientProvider#containsKmsDt() is null when it definitely has the kms delegation token.

In fact, KMSClientProvider#containsKmsDt() should select delegation token using clientTokenProvider.selectDelegationToken(creds) rather than checking if its dtService is in the user credentials.

This is done correctly in KMSClientProvider#createAuthenticatedURL though.

We found this bug when it broke Cloudera's Backup and Disaster Recovery tool.

 

Daryn Sharp Xiao Chen mind taking a look? HADOOP-14445 is a huge patch but it is almost perfect except for this bug.

Issue Links

• is broken by: HADOOP-14445 Use DelegationTokenIssuer to create KMS delegation tokens that can authenticate to all KMS instances