[
https://issues.apache.org/jira/browse/HDFS-10643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15383432#comment-15383432
]
Xiao Chen commented on HDFS-10643:
----------------------------------
Thanks [~xyao] for opening the issue and the patch.
I think the idea makes sense, since from HDFS perspective the only user needs
to generate EDEK is {{hdfs}}. Ping [~andrew.wang] for awareness.
Regarding {{checkTGTAndReloginFromKeytab}}, you're absolutely right that we
don't need it in the client code here. I think adding it to
{{KerberosAuthencitator}} makes sense logically, and in that case we don't need
these in DTA any more.
{code}
public void authenticate(URL url, AuthenticatedURL.Token token)
throws IOException, AuthenticationException {
if (!hasDelegationToken(url, token)) {
// check and renew TGT to handle potential expiration
UserGroupInformation.getCurrentUser().checkTGTAndReloginFromKeytab();
authenticator.authenticate(url, token);
}
}
{code}
I didn't put it there in HADOOP-13255 because KA is in hadoop-auth component,
while DTA and UGI are both in hadoop-common. Feels like we'll need a dependency
between the two in order to add this... Let's follow up on this in the separate
jira.
> HDFS namenode should always use service user (hdfs) to generateEncryptedKey
> ---------------------------------------------------------------------------
>
> Key: HDFS-10643
> URL: https://issues.apache.org/jira/browse/HDFS-10643
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: encryption, namenode
> Affects Versions: 2.6.0
> Reporter: Xiaoyu Yao
> Assignee: Xiaoyu Yao
> Attachments: HDFS-10643.00.patch, HDFS-10643.01.patch
>
>
> KMSClientProvider is designed to be shared by different KMS clients. When
> HDFS Namenode as KMS client talks to KMS to generateEncryptedKey for new file
> creation from proxy user (hive, oozie), the proxyuser handling for
> KMSClientProvider in this case is unnecessary, which cause 1) an extra proxy
> user configuration allowing hdfs user to proxy its clients and 2) KMS acls to
> allow non-hdfs user for GENERATE_EEK operation.
> This ticket is opened to always use HDFS namenode login user (hdfs) when
> talking to KMS to generateEncryptedKey for new file creation. This way, we
> have a more secure KMS based HDFS encryption (we can set kms-acls to allow
> only hdfs user for GENERATE_EEK) with less configuration hassle for KMS to
> allow hdfs to proxy other users.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
