Return-Path: X-Original-To: apmail-hadoop-common-issues-archive@minotaur.apache.org Delivered-To: apmail-hadoop-common-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 57C6111BFA for ; Fri, 4 Jul 2014 01:13:34 +0000 (UTC) Received: (qmail 91599 invoked by uid 500); 4 Jul 2014 01:13:34 -0000 Delivered-To: apmail-hadoop-common-issues-archive@hadoop.apache.org Received: (qmail 91547 invoked by uid 500); 4 Jul 2014 01:13:34 -0000 Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: common-issues@hadoop.apache.org Delivered-To: mailing list common-issues@hadoop.apache.org Received: (qmail 91529 invoked by uid 99); 4 Jul 2014 01:13:34 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Jul 2014 01:13:34 +0000 Date: Fri, 4 Jul 2014 01:13:33 +0000 (UTC) From: "Aaron T. Myers (JIRA)" To: common-issues@hadoop.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HADOOP-10769) Add getDelegationToken() method to KeyProvider MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HADOOP-10769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14052066#comment-14052066 ] Aaron T. Myers commented on HADOOP-10769: ----------------------------------------- bq. Do you think that we could make it more generic though? I'm sure we could, but I suggest we cross that bridge when we come to it. Hadoop currently does delegated authentication via {{DelegationTokens}} everywhere, so let's do something to support that and move on. If in the future we have need for other stuff, we'll amend the API appropriately. Seems quite premature to me to attempt to design a generic API when we don't have any concrete alternate use-cases. bq. Out of curiosity, why does it return an array of Tokens? The various callers use it for different things, e.g. in some places just to log which tokens were renewed. I don't think it's actually integral to the functioning of the API, just a convenience. bq. If we were to open it up to include other things, like keys or passwords, etc then we could just make it an add credentials method call: In general I'm really leery of a {{HashMap}}-based API. That seems quite fragile to me, and very overly-generic for the common use case of just dealing with DTs. How about as a way forward with this JIRA we go with the "{{public Token[] addDelegationTokens(final String renewer, Credentials credentials)}}" added to {{KeyProvider}} as I proposed, and revisit a more generic API in the future when we actually have a concrete need for it? We could then perhaps later add a "{{addAdditionalCredentials}}" API call or something to accommodate non-DT-based implementations. It is *soft*ware, after all. :) > Add getDelegationToken() method to KeyProvider > ---------------------------------------------- > > Key: HADOOP-10769 > URL: https://issues.apache.org/jira/browse/HADOOP-10769 > Project: Hadoop Common > Issue Type: Improvement > Components: security > Affects Versions: 3.0.0 > Reporter: Alejandro Abdelnur > Assignee: Arun Suresh > > The KeyProvider API needs to return delegation tokens to enable access to the KeyProvider from processes without Kerberos credentials (ie Yarn containers). > This is required for HDFS encryption and KMS integration. -- This message was sent by Atlassian JIRA (v6.2#6252)