[jira] [Commented] (HADOOP-17208) LoadBalanceKMSClientProvider#deleteKey should invalidateCache via all KMSClientProvider instances

2020-10-12 Thread Xiaoyu Yao (Jira) 


[ 
https://issues.apache.org/jira/browse/HADOOP-17208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212819#comment-17212819
 ] 

Xiaoyu Yao commented on HADOOP-17208:
-

I agree. With HADOOP-17304, this will not be no need to expose additional 
INVALIDATE_CACHE ACL for DELETE ops. The previous failed test can be used to 
validate this 

> LoadBalanceKMSClientProvider#deleteKey should invalidateCache via all 
> KMSClientProvider instances
> -
>
> Key: HADOOP-17208
> URL: https://issues.apache.org/jira/browse/HADOOP-17208
> Project: Hadoop Common
>  Issue Type: Improvement
>Affects Versions: 2.8.4
>Reporter: Xiaoyu Yao
>Assignee: Xiaoyu Yao
>Priority: Major
>  Labels: pull-request-available
> Fix For: 3.4.0
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> Without invalidateCache, the deleted key may still exists in the servers' key 
> cache (CachingKeyProvider in KMSWebApp.java)  where the delete key was not 
> hit. Client may still be able to access encrypted files by specifying to 
> connect to KMS instances with a cached version of the deleted key before the 
> cache entry (10 min by default) expired. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org

[jira] [Commented] (HADOOP-17208) LoadBalanceKMSClientProvider#deleteKey should invalidateCache via all KMSClientProvider instances

2020-10-12 Thread Xiaoqiao He (Jira) 


[ 
https://issues.apache.org/jira/browse/HADOOP-17208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212811#comment-17212811
 ] 

Xiaoqiao He commented on HADOOP-17208:
--

Thanks [~xyao] for your comments, I am concerned if this is incompatible 
improvement. After changes, we expose INVALIDATE_CACHE acl to end user which 
does not need to care about before. Please correct me if something I missed. 
Thanks.

> LoadBalanceKMSClientProvider#deleteKey should invalidateCache via all 
> KMSClientProvider instances
> -
>
> Key: HADOOP-17208
> URL: https://issues.apache.org/jira/browse/HADOOP-17208
> Project: Hadoop Common
>  Issue Type: Improvement
>Affects Versions: 2.8.4
>Reporter: Xiaoyu Yao
>Assignee: Xiaoyu Yao
>Priority: Major
>  Labels: pull-request-available
> Fix For: 3.4.0
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> Without invalidateCache, the deleted key may still exists in the servers' key 
> cache (CachingKeyProvider in KMSWebApp.java)  where the delete key was not 
> hit. Client may still be able to access encrypted files by specifying to 
> connect to KMS instances with a cached version of the deleted key before the 
> cache entry (10 min by default) expired. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org

[jira] [Commented] (HADOOP-17208) LoadBalanceKMSClientProvider#deleteKey should invalidateCache via all KMSClientProvider instances

2020-10-12 Thread Xiaoyu Yao (Jira) 


[ 
https://issues.apache.org/jira/browse/HADOOP-17208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212623#comment-17212623
 ] 

Xiaoyu Yao commented on HADOOP-17208:
-

Good catch [~ayushtkn]. And thanks [~hexiaoqiao] for looking into this. 

The original design of the INVALIDATE_CACHE op is tied to ROLLOVER ACL. The 
test itself can be fixed by allowing "DELETE" user to have ROLLOVER just like 
SET_KEY_MATERIAL does. 

conf.set(KMSACLs.Type.ROLLOVER.getAclConfigKey(),
KMSACLs.Type.ROLLOVER.toString() + ",SET_KEY_MATERIAL,DELETE");

It would be much clean if we can have a separate INVALIDATE_CACHE ACL type to 
differentiate INVALIDATE_CACHE other than ROLLOVER itself like SET_KEY_MATERIAL 
and DELETE. 

 


> LoadBalanceKMSClientProvider#deleteKey should invalidateCache via all 
> KMSClientProvider instances
> -
>
> Key: HADOOP-17208
> URL: https://issues.apache.org/jira/browse/HADOOP-17208
> Project: Hadoop Common
>  Issue Type: Improvement
>Affects Versions: 2.8.4
>Reporter: Xiaoyu Yao
>Assignee: Xiaoyu Yao
>Priority: Major
>  Labels: pull-request-available
> Fix For: 3.4.0
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> Without invalidateCache, the deleted key may still exists in the servers' key 
> cache (CachingKeyProvider in KMSWebApp.java)  where the delete key was not 
> hit. Client may still be able to access encrypted files by specifying to 
> connect to KMS instances with a cached version of the deleted key before the 
> cache entry (10 min by default) expired. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org

[jira] [Commented] (HADOOP-17208) LoadBalanceKMSClientProvider#deleteKey should invalidateCache via all KMSClientProvider instances

2020-10-12 Thread Xiaoqiao He (Jira) 


[ 
https://issues.apache.org/jira/browse/HADOOP-17208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212279#comment-17212279
 ] 

Xiaoqiao He commented on HADOOP-17208:
--

[~ayushtkn] Thanks for your comments. Failed unit test {{TestKMS.testACLs}} is 
related to change. The root cause is that not assign {{KMSACLs.Type.ROLLOVER}} 
privilege to user `DELETE` after add invalidate cache operation when delete key.
It seems that this is not an incompatible improvement? ACL entry has changed 
for delete key after this changes. cc [~xyao] would you like to have another 
checks? Thanks.

> LoadBalanceKMSClientProvider#deleteKey should invalidateCache via all 
> KMSClientProvider instances
> -
>
> Key: HADOOP-17208
> URL: https://issues.apache.org/jira/browse/HADOOP-17208
> Project: Hadoop Common
>  Issue Type: Improvement
>Affects Versions: 2.8.4
>Reporter: Xiaoyu Yao
>Assignee: Xiaoyu Yao
>Priority: Major
>  Labels: pull-request-available
> Fix For: 3.4.0
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> Without invalidateCache, the deleted key may still exists in the servers' key 
> cache (CachingKeyProvider in KMSWebApp.java)  where the delete key was not 
> hit. Client may still be able to access encrypted files by specifying to 
> connect to KMS instances with a cached version of the deleted key before the 
> cache entry (10 min by default) expired. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org

[jira] [Commented] (HADOOP-17208) LoadBalanceKMSClientProvider#deleteKey should invalidateCache via all KMSClientProvider instances

2020-10-10 Thread Ayush Saxena (Jira) 


[ 
https://issues.apache.org/jira/browse/HADOOP-17208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17211647#comment-17211647
 ] 

Ayush Saxena commented on HADOOP-17208:
---

[~xyao]/[~hexiaoqiao]
This seems to have broken {{TestKMS.testACLs}}

https://ci-hadoop.apache.org/job/hadoop-qbt-trunk-java8-linux-x86_64/290/testReport/junit/org.apache.hadoop.crypto.key.kms.server/TestKMS/testACLs/

Please give a check

> LoadBalanceKMSClientProvider#deleteKey should invalidateCache via all 
> KMSClientProvider instances
> -
>
> Key: HADOOP-17208
> URL: https://issues.apache.org/jira/browse/HADOOP-17208
> Project: Hadoop Common
>  Issue Type: Improvement
>Affects Versions: 2.8.4
>Reporter: Xiaoyu Yao
>Assignee: Xiaoyu Yao
>Priority: Major
>  Labels: pull-request-available
> Fix For: 3.4.0
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> Without invalidateCache, the deleted key may still exists in the servers' key 
> cache (CachingKeyProvider in KMSWebApp.java)  where the delete key was not 
> hit. Client may still be able to access encrypted files by specifying to 
> connect to KMS instances with a cached version of the deleted key before the 
> cache entry (10 min by default) expired. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org