hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arun Suresh (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HADOOP-11341) Check if user is present in default key ACL if user does not have explicit key ACLS
Date Wed, 26 Nov 2014 20:15:12 GMT

     [ 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)

Mime
View raw message