Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id E4AFD200C2C for ; Fri, 3 Mar 2017 19:48:49 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id E331E160B6D; Fri, 3 Mar 2017 18:48:49 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 3AE58160B5E for ; Fri, 3 Mar 2017 19:48:49 +0100 (CET) Received: (qmail 67625 invoked by uid 500); 3 Mar 2017 18:48:48 -0000 Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list common-issues@hadoop.apache.org Received: (qmail 67613 invoked by uid 99); 3 Mar 2017 18:48:48 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Mar 2017 18:48:48 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id E36E91803A6 for ; Fri, 3 Mar 2017 18:48:47 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=6.31 tests=[RP_MATCHES_RCVD=-2.999, SPF_NEUTRAL=0.652] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id uRw70wCtfAMy for ; Fri, 3 Mar 2017 18:48:47 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id 852365FAD8 for ; Fri, 3 Mar 2017 18:48:46 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id BB64CE00B4 for ; Fri, 3 Mar 2017 18:48:45 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 4AC462415A for ; Fri, 3 Mar 2017 18:48:45 +0000 (UTC) Date: Fri, 3 Mar 2017 18:48:45 +0000 (UTC) From: "Daryn Sharp (JIRA)" To: common-issues@hadoop.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HADOOP-14104) Client should always ask namenode for kms provider path. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Fri, 03 Mar 2017 18:48:50 -0000 [ https://issues.apache.org/jira/browse/HADOOP-14104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15894839#comment-15894839 ] Daryn Sharp commented on HADOOP-14104: -------------------------------------- Credentials are simply a container in the ugi for tokens and/or secrets. There is no notion of client, server, etc. Credentials are the mechanism by which tokens are propagated throughout a job. I may be understanding the EZ w/o security question (which seems an entirely contrived use case), but regardless: if tokens are available, so are the secrets since they are both packaged in the credentials object. If this use case works today then it will continue to work with the mappings based approach. > 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: common-issues-unsubscribe@hadoop.apache.org For additional commands, e-mail: common-issues-help@hadoop.apache.org