Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 24 Jun 2016 13:36:16 +0000 (UTC)
From: "Steve Loughran (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: <JIRA.12977157.1465463852000.21998.1466775376287@Atlassian.JIRA>
In-Reply-To: <JIRA.12977157.1465463852000@Atlassian.JIRA>
References: <JIRA.12977157.1465463852000@Atlassian.JIRA> <JIRA.12977157.1465463852915@arcas>
Subject: [jira] [Updated] (HADOOP-13252) Tune S3A provider plugin mechanism
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Fri, 24 Jun 2016 13:36:18 -0000


     [ https://issues.apache.org/jira/browse/HADOOP-13252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steve Loughran updated HADOOP-13252:
------------------------------------
    Description: 
We've now got some fairly complex auth mechanisms going on: -hadoop config, KMS, env vars, "none". IF something isn't working, it's going to be a lot harder to debug.

Review and tune the S3A provider point

* add logging of what's going on in s3 auth to help debug problems
* make a whole chain of logins expressible
* allow the anonymous credentials to be included in the list
* review and updated documents.


I propose *carefully* adding some debug messages to identify which auth provider is doing the auth, so we can see if the env vars were kicking in, sysprops, etc.

What we mustn't do is leak any secrets: this should be identifying whether properties and env vars are set, not what their values are. I don't believe that this will generate a security risk.

  was:
We've now got some fairly complex auth mechanisms going on: -hadoop config, KMS, env vars, "none". IF something isn't working, it's going to be a lot harder to debug.

I propose *carefully* adding some debug messages to identify which auth provider is doing the auth, so we can see if the env vars were kicking in, sysprops, etc.

What we mustn't do is leak any secrets: this should be identifying whether properties and env vars are set, not what their values are. I don't believe that this will generate a security risk.


> Tune S3A provider plugin mechanism
> ----------------------------------
>
>                 Key: HADOOP-13252
>                 URL: https://issues.apache.org/jira/browse/HADOOP-13252
>             Project: Hadoop Common
>          Issue Type: Sub-task
>          Components: fs/s3
>    Affects Versions: 2.8.0
>            Reporter: Steve Loughran
>            Assignee: Steve Loughran
>            Priority: Minor
>         Attachments: HADOOP-13252-branch-2-001.patch
>
>
> We've now got some fairly complex auth mechanisms going on: -hadoop config, KMS, env vars, "none". IF something isn't working, it's going to be a lot harder to debug.
> Review and tune the S3A provider point
> * add logging of what's going on in s3 auth to help debug problems
> * make a whole chain of logins expressible
> * allow the anonymous credentials to be included in the list
> * review and updated documents.
> I propose *carefully* adding some debug messages to identify which auth provider is doing the auth, so we can see if the env vars were kicking in, sysprops, etc.
> What we mustn't do is leak any secrets: this should be identifying whether properties and env vars are set, not what their values are. I don't believe that this will generate a security risk.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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