[
https://issues.apache.org/jira/browse/SLIDER-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14158425#comment-14158425
]
Jonathan Maron edited comment on SLIDER-474 at 10/3/14 7:47 PM:
----------------------------------------------------------------
A summary of the current implementation:
Keytabs:
-----------
There are two mechanisms for keytab specification:
1) Local/pre-distributed - both service and headless keytabs are
pre-distributed to the cluster hosts. The headless keytab is leveraged by the
AM to perform a login with the designated principal. Note that all keytabs
need to be manually distributed (i.e. there currently is no mechanism for using
a pre-distributed keytab for AM login while distributing the service keytabs).
Sample configuration:
. . .
"site.hbase-site.hbase.thrift.kerberos.principal":
"hbase/[email protected]",
"site.hbase-site.hbase.thrift.keytab.file":
"/etc/security/keytabs/hbase.service.keytab"
. . .
"components": {
"slider-appmaster": {
"jvm.heapsize": "256M",
"slider.am.keytab.local.path":
"/etc/security/keytabs/hbase.headless.keytab"
}
}
2) Distributed - the AM leverages yarn to distribute all keytabs in a
designated HDFS directory via localization. The keytabs are "pre-installed" to
HDFS under the "keytabs" root:
/users/username/.slider/keytabs/applicationName/some.headless.keytab
/users/username/.slider/keytabs/applicationName/some.service.keytab
The application configuration designates the keytab to use for login
purposes. The runtime will localize all keytabs EXCEPT the one designated for
login (assuming that it is a headless keytab not to be leveraged by service
components). In this instance there should be no setting specified for
"slider.am.keytab.local.path" since that is an indication that the local
mechanism (see 1) is selected. Sample config entries:
. . .
"site.hbase-site.hbase.thrift.kerberos.principal":
"hbase/[email protected]",
"site.hbase-site.hbase.thrift.keytab.file":
"${AGENT_WORK_ROOT}/keytabs/hbase.service.keytab"
. . .
},
"components": {
"slider-appmaster": {
"jvm.heapsize": "256M",
"slider.am.login.keytab.name": "hbase.headless.keytab"
}
}
Note that the keytab location specified for the app is under
${AGENT_WORK_ROOT}/keytabs (localization path) and that
"slider.am.login.keytab.name" specifies the keytab to use for login from the
installed HDFS keytab location.
I have verified that, for both mechanisms, the appropriate permissions (user
only access) are either set (distributed) or do not raise permission issues
(local).
ISSUE: Should there be a specific property explicitly identifying the keytab
lookup mechanism (as opposed to implying the mechanism)?
ISSUE: There is a need for a install-keytab slider client command. Should the
convention be to assume that the application name for both cluster creation and
keytab installation will be the same (i.e. should the keytab reside under
".../keytabs/applicationName" as it currently does)?
The principal leveraged for login in both instances is either explicitly
specified with the "slider.keytab.principal.name" property or, if that is not
specified, is assumed to be the short name associated with the AM launch
user/subject.
Login:
-----------
The login from the keytab is performed after the AM registers with the RM
since the AMRM token, established as part of the AM launch, is required for
that interaction. As part of the interaction an FileSystem reference is
retrieved to ensure that the reference utilized from that point on is one
associated to a kerberos authenticated user.
When leveraging the distributed keytab mechanism, the headless keytab is
downloaded to the local file system to perform the login. It is written to a
user only temporary directory (700), and is given a 400 permission setting.
ISSUE: Is there an API that allows insight into whether a FileSystem reference
is kerberos based (as opposed to token based)? I've only seen methods on the
server side (NN) that test the remote user authentication method. I suppose I
could invoke getDelegationToken(), but that seem like a needless call...
The implementation appears to be validated by the fact that, upon container
launch, the retrieval of delegation tokens for the launch context is successful
(an explicit call is made to getDelegationToken() as opposed to the previous
method of using the persisted tokens from the initial AM launch user's
credentials).
Validation Test:
--------------------
I've tested both keytab distribution/lookup mechanisms above leveraging secure
HBase. I also tested the distributed mechanism using memcached (though it
doesn't really make use of the keytabs directly).
was (Author: jmaron):
A summary of the current implementation:
Keytabs:
-----------
There are two mechanisms for keytab specification:
1) Local/pre-distributed - both service and headless keytabs are
pre-distributed to the cluster hosts. The headless keytab is leveraged by the
AM to perform a login with the designated principal. Note that all keytabs
need to be manually distributed (i.e. there currently is no mechanism for using
a pre-distributed keytab for AM login while distributing the service keytabs).
Sample configuration:
. . .
"site.hbase-site.hbase.thrift.kerberos.principal":
"hbase/[email protected]",
"site.hbase-site.hbase.thrift.keytab.file":
"/etc/security/keytabs/hbase.service.keytab"
. . .
"components": {
"slider-appmaster": {
"jvm.heapsize": "256M",
"slider.am.keytab.local.path":
"/etc/security/keytabs/hbase.headless.keytab"
}
}
2) Distributed - the AM leverages yarn to distribute all keytabs in a
designated HDFS directory via localization. The keytabs are "pre-installed" to
HDFS under the "keytabs" root:
/users/username/.slider/keytabs/applicationName/some.headless.keytab
/users/username/.slider/keytabs/applicationName/some.service.keytab
The application configuration designates the keytab to use for login
purposes. The runtime will localize all keytabs EXCEPT the one designated for
login (assuming that it is a headless keytab not to be leveraged by service
components). In this instance there should be no setting specified for
"slider.am.keytab.local.path" since that is an indication that the local
mechanism (see 1) is selected. Sample config entries:
. . .
"site.hbase-site.hbase.thrift.kerberos.principal":
"hbase/[email protected]",
"site.hbase-site.hbase.thrift.keytab.file":
"${AGENT_WORK_ROOT}/keytabs/hbase.service.keytab"
. . .
},
"components": {
"slider-appmaster": {
"jvm.heapsize": "256M",
"slider.am.login.keytab.name": "hbase.headless.keytab"
}
}
Note that the keytab location specified for the app is under
${AGENT_WORK_ROOT}/keytabs (localization path) and that
"slider.am.login.keytab.name" specifies the keytab to use for login from the
installed HDFS keytab location.
ISSUE: Should there be a specific property explicitly identifying the keytab
lookup mechanism (as opposed to implying the mechanism)?
ISSUE: There is a need for a install-keytab slider client command. Should the
convention be to assume that the application name for both cluster creation and
keytab installation will be the same (i.e. should the keytab reside under
".../keytabs/applicationName" as it currently does)?
The principal leveraged for login in both instances is either explicitly
specified with the "slider.keytab.principal.name" property or, if that is not
specified, is assumed to be the short name associated with the AM launch
user/subject.
Login:
-----------
The login from the keytab is performed after the AM registers with the RM
since the AMRM token, established as part of the AM launch, is required for
that interaction. As part of the interaction an FileSystem reference is
retrieved to ensure that the reference utilized from that point on is one
associated to a kerberos authenticated user.
ISSUE: Is there an API that allows insight into whether a FileSystem reference
is kerberos based (as opposed to token based)? I've only seen methods on the
server side (NN) that test the remote user authentication method. I suppose I
could invoke getDelegationToken(), but that seem like a needless call...
The implementation appears to be validated by the fact that, upon container
launch, the retrieval of delegation tokens for the launch context is successful
(an explicit call is made to getDelegationToken() as opposed to the previous
method of using the persisted tokens from the initial AM launch user's
credentials).
Validation:
-------------
I've tested both keytab distribution/lookup mechanisms above leveraging secure
HBase. I also tested the distributed mechanism using memcached (though it
doesn't really make use of the keytabs directly).
> convert token based authentication to kerberos/keytab based
> -----------------------------------------------------------
>
> Key: SLIDER-474
> URL: https://issues.apache.org/jira/browse/SLIDER-474
> Project: Slider
> Issue Type: Bug
> Components: appmaster, security
> Reporter: Jonathan Maron
> Assignee: Jonathan Maron
>
> The AM communication to HDFS and the localization performed by AM require an
> authenticated identity or delegation tokens. However, tokens require quite a
> bit of management to handle renewal and expiry. It is preferable to leverage
> a keytab and authenticate via kerberos in the AM (the login identity) and use
> that identity for managing the interactions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
