[
https://issues.apache.org/jira/browse/HADOOP-11479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14280359#comment-14280359
]
Ranadip commented on HADOOP-11479:
----------------------------------
Hi Charles,
Yes, you are right on the user setup and namenode process is started by "hdfs".
This is a kerberos enabled environment, so the real user is obtained from the
Kerberos ticket. The Kerberos user, though not "hdfs" is a member of the hdfs
supergroup. So, Hadoop should see the user as a superuser when executing this
command. Moreover, the encryption zone is being created inside the Kerberos
user's home directory where the user executing the command is in fact the owner
of the EZ being created.
However, providing key level access, specially READ access to an application
user does ring some alarm bells. In effect, with this limitation that hdfs user
needs those key accesses for all encryption zones, it means if the hdfs user
credentials are compromised, the "baddie" can have access to the encrypted data
as well (or am I missing something?) Should the process rather not use the real
user (authenticated by Kerberos) from the UserGroupInformation check key level
authorisations with KMS?
> hdfs crypto -createZone fails to impersonate the real user in a kerberised
> environment
> --------------------------------------------------------------------------------------
>
> Key: HADOOP-11479
> URL: https://issues.apache.org/jira/browse/HADOOP-11479
> Project: Hadoop Common
> Issue Type: Bug
> Affects Versions: 2.6.0
> Environment: CentOS
> Reporter: Ranadip
> Attachments: KMS-test-acl.txt
>
>
> The problem occurs when KMS key level acl is created for the key before the
> encryption zone is created. The command tried to create the encryption zone
> using "hdfs" user's identity and not the real user's identity.
> Steps:
> In a kerberised environment:
> 1. Create key level ACL in KMS for a new key.
> 2. Create encryption key now. (Goes through fine)
> 3. Create encryption zone. (Fails)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
