[
https://issues.apache.org/jira/browse/HADOOP-14445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16420784#comment-16420784
]
Rushabh S Shah commented on HADOOP-14445:
-----------------------------------------
Thanks [~xiaochen] for revising the patch.
The patch looks really good and almost close.
Just few minor comments.
+TestKMS.java+
{code}
public void doKMSHAZKWithDelegationTokenAccess() throws Exception {
...
...
...
doAs("client",
new PrivilegedExceptionAction<Void>() {
@Override
public Void run() throws Exception {
// verify both tokens can be used to authenticate
for (Token t : credentials.getAllTokens()) {
assertTokenAccess(lbkp1, keyName, t);
}
return null;
}
});
}
private void assertTokenAccess(final LoadBalancingKMSClientProvider lbkp,
final String keyName, final Token token) throws Exception {
UserGroupInformation tokenUgi =
UserGroupInformation.createUserForTesting("test", new String[] {});
// Verify the tokens can authenticate to any KMS
tokenUgi.addToken(token);
tokenUgi.doAs(new PrivilegedExceptionAction<Void>() {
@Override
public Void run() throws Exception {
{code}
I don't understand much of UGI so I apologize in advance if this question
doesn't make sense.
Why are we doing {{doAs("client")}} when we are again going to do
{{doAs("test")} user in {{assertTokenAccess}}} ?
+KMSClientProvider.java+
{code}
assert KMSDelegationToken.TOKEN_KIND.equals(token.getKind());
if (!copyLegacyToken || !KMSDelegationToken.TOKEN_KIND
.equals(token.getKind())) {
LOG.debug("Not creating legacy token because copyLegacyToken={}, "
+ "token={}", copyLegacyToken, token);
return null;
}
{code}
Is it ever possible that {{token.getKind != KMSDelegationToken.TOKEN_KIND}} ?
I would replace {{assert}} with {{PreConditions}} and remove
{{!KMSDelegationToken.TOKEN_KIND.equals(token.getKind())}} check from if
statement.
+core-default.xml+
typo
{noformat}
confronting to kms-dt. All other parts of the token remain the same.
{noformat}
Instead of {{confronting}}, I think you meant {{confirming}} ?
> Delegation tokens are not shared between KMS instances
> ------------------------------------------------------
>
> Key: HADOOP-14445
> URL: https://issues.apache.org/jira/browse/HADOOP-14445
> Project: Hadoop Common
> Issue Type: Bug
> Components: kms
> Affects Versions: 2.8.0, 3.0.0-alpha1
> Environment: CDH5.7.4, Kerberized, SSL, KMS-HA, at rest encryption
> Reporter: Wei-Chiu Chuang
> Assignee: Xiao Chen
> Priority: Major
> Attachments: HADOOP-14445-branch-2.8.002.patch,
> HADOOP-14445-branch-2.8.patch, HADOOP-14445.002.patch,
> HADOOP-14445.003.patch, HADOOP-14445.004.patch, HADOOP-14445.05.patch,
> HADOOP-14445.06.patch, HADOOP-14445.07.patch, HADOOP-14445.08.patch,
> HADOOP-14445.09.patch, HADOOP-14445.10.patch
>
>
> As discovered in HADOOP-14441, KMS HA using LoadBalancingKMSClientProvider do
> not share delegation tokens. (a client uses KMS address/port as the key for
> delegation token)
> {code:title=DelegationTokenAuthenticatedURL#openConnection}
> if (!creds.getAllTokens().isEmpty()) {
> InetSocketAddress serviceAddr = new InetSocketAddress(url.getHost(),
> url.getPort());
> Text service = SecurityUtil.buildTokenService(serviceAddr);
> dToken = creds.getToken(service);
> {code}
> But KMS doc states:
> {quote}
> Delegation Tokens
> Similar to HTTP authentication, KMS uses Hadoop Authentication for delegation
> tokens too.
> Under HA, A KMS instance must verify the delegation token given by another
> KMS instance, by checking the shared secret used to sign the delegation
> token. To do this, all KMS instances must be able to retrieve the shared
> secret from ZooKeeper.
> {quote}
> We should either update the KMS documentation, or fix this code to share
> delegation tokens.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
