[
https://issues.apache.org/jira/browse/OOZIE-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16501869#comment-16501869
]
Clay B. edited comment on OOZIE-2877 at 6/5/18 2:34 PM:
--------------------------------------------------------
My understanding was [~gezapeti]'s original request was to ensure the
credential as stored on HDFS were secure; and if it was not, then we should
warn (or error) to the user – the same as SSH does for your private SSH key
(e.g. see [Stack Overflow
#9270734|[https://stackoverflow.com/questions/9270734/ssh-permissions-are-too-open-error]|https://stackoverflow.com/questions/9270734/ssh-permissions-are-too-open-error]).
In the case of YARN Credentials, how would one provide that to the Oozie job
for on-going use? Does the Oozie REST API support some notion of the YARN
credentials or is this only at job launch and {{git clone}} time? I would
expect if the later, then it could be useful but I do not expect more security
unless run on an insecure cluster where all jobs are run as the same user (e.g.
{{yarn}} instead of the user submitting the job) or where local-filesystem
permissions are otherwise non-standard for a secure deployment?
was (Author: clayb):
My understanding was [~gezapeti]'s original request was to ensure the
credential as stored on HDFS were secure; and if it was not, then we should
warn (or error) to the user – the same as SSH does for your private SSH key
(e.g. see [Stack Overflow
#9270734|[https://stackoverflow.com/questions/9270734/ssh-permissions-are-too-open-error]).]]).
In the case of YARN Credentials, how would one provide that to the Oozie job
for on-going use? Does the Oozie REST API support some notion of the YARN
credentials or is this only at job launch and {{git clone}} time? I would
expect if the later, then it could be useful but I do not expect more security
unless run on an insecure cluster where all jobs are run as the same user (e.g.
{{yarn}} instead of the user submitting the job) or where local-filesystem
permissions are otherwise non-standard for a secure deployment?
> Oozie Git Action
> ----------------
>
> Key: OOZIE-2877
> URL: https://issues.apache.org/jira/browse/OOZIE-2877
> Project: Oozie
> Issue Type: Sub-task
> Components: action
> Reporter: Clay B.
> Assignee: Clay B.
> Priority: Major
> Labels: action
> Fix For: trunk
>
> Attachments: 0001-OOZIE-2877-Oozie-Git-Action.patch,
> 0002-OOZIE-2877-Oozie-Git-Action.patch,
> 0003-OOZIE-2877-Oozie-Git-Action.patch,
> 0004-OOZIE-2877-Oozie-Git-Action.patch,
> 0005-OOZIE-2877-Oozie-Git-Action.patch,
> 0006-OOZIE-2877-Oozie-Git-Action.patch,
> 0007-OOZIE-2877-Oozie-Git-Action.patch,
> 0008-OOZIE-2877-Oozie-Git-Action.patch,
> 0009-OOZIE-2877-Oozie-Git-Action.patch, OOZIE-2877.010.patch,
> OOZIE-2877.011.patch, OOZIE-2877.012.patch
>
>
> To aide in deploying ASCII artifacts to clusters, let's provide a tie-in for
> a source-code management system. Git would be my preferred choice.
> Ideally, this could handle a user's key material e.g. for an ssh key to pull
> down from a secured repository. This would free users from handling their own
> key staging and clean-up on YARN nodes and only require them to store the key
> secured in HDFS.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
