[
https://issues.apache.org/jira/browse/HADOOP-11341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arun Suresh updated HADOOP-11341:
---------------------------------
Description:
As reported by [~dian.fu] :
Key based ACL in KMS is currently implemented as whitelist. So if I configure
as follows in kms-acl.xml,
{code}
<property>
<name>key.acl.testKey.DECRYPT_EEK</name>
<value>testUser</value>
</property>
{code}, then only {{testUser}} user can do {{DECRYPT_EEK}} call on key
{{testKey}}. If I want {{yarn}} user can also do {{DECRYPT_EEK}} call on
{{testKey}} key, I need add {{yarn}} user to the above configuration value
manually. This means that if I want to configure key based ACL({{DECRYPT_EEK}})
for {{some key}}, I need also add {{yarn}} user to configuration
{{DECRYPT_EEK}} for that key. As I don't know if {{yarn}} user will later need
to do {{DECRYPT_EEK}} for this key.. This is inconvenient and tricky.
This can be alleviated by slightly modifying the key ACL logic in KMS first
checks if the user, in this case {{yarn}}, is present in
{{key.acl.<key-name>.<OP-name>}} list. And if not, then also check if the user
is present in {{default.key.acl.<OP-name>}}. If yes, then grant access.. else
deny.
Currently, {{default.key.acl.<OP-name>}} is consulted only if NO
{{key.acl.<key-name>.<OP-name>}} is specified.
was:
As reported by [~dian.fu] :
Key based ACL in KMS is currently implemented as whitelist. So if I configure
as follows in kms-acl.xml,
{code}
<property>
<name>key.acl.testKey.DECRYPT_EEK</name>
<value>testUser</value>
</property>
{code}, then only {{testUser}} user can do {{DECRYPT_EEK}} call on key
{{testKey}}. If I want {{yarn}} user can also do {{DECRYPT_EEK}} call on
{{testKey}} key, I need add {{yarn}} user to the above configuration value
manually. This means that if I want to configure key based ACL({{DECRYPT_EEK}})
for {{some key}}, I need also add {{yarn}} user to configuration
{{DECRYPT_EEK}} for that key. As I don't know if {{yarn}} user will later need
to do {{DECRYPT_EEK}} for this key, such as the described example in the
description of this JIRA. This is inconvenient and tricky.
This can be alleviated by slightly modifying the key ACL logic in KMS first
checks if the user, in this case {{yarn}}, is present in
{{key.acl.<key-name>.<OP-name>}} list. And if not, then also check if the user
is present in {{default.key.acl.<OP-name>}} before. If yes, then grant access..
else deny.
Currently, {{default.key.acl.<OP-name>}} is consulted only if NO
{{key.acl.<key-name>.<OP-name>}} is specified.
> Check if user is present in default key ACL if user does not have explicit
> key ACLS
> -----------------------------------------------------------------------------------
>
> Key: HADOOP-11341
> URL: https://issues.apache.org/jira/browse/HADOOP-11341
> Project: Hadoop Common
> Issue Type: Bug
> Components: kms, security
> Reporter: Arun Suresh
> Assignee: Arun Suresh
>
> As reported by [~dian.fu] :
> Key based ACL in KMS is currently implemented as whitelist. So if I configure
> as follows in kms-acl.xml,
> {code}
> <property>
> <name>key.acl.testKey.DECRYPT_EEK</name>
> <value>testUser</value>
> </property>
> {code}, then only {{testUser}} user can do {{DECRYPT_EEK}} call on key
> {{testKey}}. If I want {{yarn}} user can also do {{DECRYPT_EEK}} call on
> {{testKey}} key, I need add {{yarn}} user to the above configuration value
> manually. This means that if I want to configure key based
> ACL({{DECRYPT_EEK}}) for {{some key}}, I need also add {{yarn}} user to
> configuration {{DECRYPT_EEK}} for that key. As I don't know if {{yarn}} user
> will later need to do {{DECRYPT_EEK}} for this key.. This is inconvenient and
> tricky.
> This can be alleviated by slightly modifying the key ACL logic in KMS first
> checks if the user, in this case {{yarn}}, is present in
> {{key.acl.<key-name>.<OP-name>}} list. And if not, then also check if the
> user is present in {{default.key.acl.<OP-name>}}. If yes, then grant access..
> else deny.
> Currently, {{default.key.acl.<OP-name>}} is consulted only if NO
> {{key.acl.<key-name>.<OP-name>}} is specified.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
