[
https://issues.apache.org/jira/browse/HADOOP-14104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15894763#comment-15894763
]
Daryn Sharp commented on HADOOP-14104:
--------------------------------------
Goal is naturally no incompatibility but expanded functionality. To that end,
the general principal when acquiring tokens:
# If getServerDefaults doesn't return a keyprovider field: it's a previous
version to the client, don't know if kms is applicable, so fallback to config
just as today.
# If getServerDefaults does return a keyprovider: it's authoritative, add a kvp
to the credentials mapping the fs uri to the kms uri.
When the dfsclient needs a key provider, check credentials:
# If fs/kms provider mapping is present, use the value as authoritative since a
token in the credentials was obtained from that provider.
# If no mapping, check getServerDefaults, fallback to config.
> Client should always ask namenode for kms provider path.
> --------------------------------------------------------
>
> Key: HADOOP-14104
> URL: https://issues.apache.org/jira/browse/HADOOP-14104
> Project: Hadoop Common
> Issue Type: Improvement
> Components: kms
> Reporter: Rushabh S Shah
> Assignee: Rushabh S Shah
> Attachments: HADOOP-14104-trunk.patch, HADOOP-14104-trunk-v1.patch
>
>
> According to current implementation of kms provider in client conf, there can
> only be one kms.
> In multi-cluster environment, if a client is reading encrypted data from
> multiple clusters it will only get kms token for local cluster.
> Not sure whether the target version is correct or not.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
