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,
, 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.