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,
<property> <name>key.acl.testKey.DECRYPT_EEK</name> <value>testUser</value> </property>
, 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.
Attachments
Attachments
Issue Links
- is depended upon by
-
HADOOP-11342 KMS key ACL should ignore ALL operation for default key ACL and whitelist key ACL
- Closed