Author: jmaron
Date: Sat Oct 11 02:12:03 2014
New Revision: 1631012
URL: http://svn.apache.org/r1631012
Log:
updated to reflect latest security model
Modified:
incubator/slider/site/trunk/content/docs/security.md
Modified: incubator/slider/site/trunk/content/docs/security.md
URL:
http://svn.apache.org/viewvc/incubator/slider/site/trunk/content/docs/security.md?rev=1631012&r1=1631011&r2=1631012&view=diff
==============================================================================
--- incubator/slider/site/trunk/content/docs/security.md (original)
+++ incubator/slider/site/trunk/content/docs/security.md Sat Oct 11 02:12:03
2014
@@ -32,11 +32,11 @@ listed at the bottom.
Slider runs in secure clusters, but with restrictions
-1. The keytabs to allow a worker to authenticate with the master must
- be distributed in advance: Slider does not attempt to pass these around.
+1. The keytabs to allow the AM and components to authenticate with the master
are
+ either distributed in advance or can be distributed by Slider.
1. Until the location of Slider node instances can be strictly limited to
- a set of nodes (a future YARN feature), the keytabs must be passed to
- all the nodes in the cluster in advance, *and made available to the
+ a set of nodes (a future YARN feature), the keytabs are required by
+ all the nodes in the cluster, *and made available to the
user creating the cluster*
1. due to the way that HBase and accumulo authenticate worker nodes to
the masters, any HBase node running on a server must authenticate as
@@ -90,13 +90,13 @@ kerberos identities.
## Design
-
1. The user is expected to have their own Kerberos principal, and have used
`kinit`
or equivalent to authenticate with Kerberos and gain a (time-bounded) TGT
-1. The user is expected to have their own principals for every host in the
cluster of the form
- username/hostname@REALM
-1. A keytab must be generated which contains all these principals -and
distributed
- to all the nodes in the cluster with read access permissions to the user.
+1. The user is expected to have principals for every host in the cluster of
the form
+ username/hostname@REALM for component aunthentication. The AM
authentication requirements
+ can be satisfied with a non-host based principal (username@REALM).
+1. Separate keytabs should be generated for the AM, which contains the AM
login principal, and the service components, which contain all the service
principals. The keytabs can be manually distributed
+ to all the nodes in the cluster with read access permissions to the user, or
the user may elect to leverage the Slider keytab distribution mechanism.
1. When the user creates a secure cluster, they provide the standard HBase
kerberos options
to identify the principals to use and the keytab location.
@@ -117,6 +117,55 @@ rights of the user that created the clus
The Application Master will read in the JSON cluster specification file, and
instantiate the
relevant number of componentss.
+### The Keytab distribution/access Options
+ The AM has been modified to leverage keytabs for authenticating rather than
relying on delegation-token based authentication mechanisms. In order to
perform this login the AM requires access to a keytab file that contains the
principal representing the user identity to be associated with the launched
application instance. There are two mechanisms supported for keytab access
and/or distribution:
+
+#### Local Keytab file access:
+
+ An application deployer may choose to pre-distribute the keytab files
required to the node manager hosts in a yarn cluster. In that instance the
appConfig.json requires the following property:
+
+ . . .
+ "components": {
+ "slider-appmaster": {
+ "jvm.heapsize": "256M",
+ "slider.am.keytab.local.path":
"/etc/security/keytabs/hbase.headless.keytab"
+ }
+ }
+
+ The âslider.am.keytab.local.pathâ property provides the full path to the
keytab file location and is mandatory for the local lookup mechanism. In this
scenario the distribution of keytab files for the AM AND the application itself
is the purview of the application deployer. So, for example, for an hbase
deployment, the hbase site service keytab will have to be distributed as well
and indicated in the hbase-site properties:
+
+ . . .
+ "site.hbase-site.hbase.master.kerberos.principal":
"hbase/_h...@example.com",
+ "site.hbase-site.hbase.master.keytab.file":
"/etc/security/keytabs/hbase.service.keytab",
+ . . .
+
+#### Slider keytab distribution:
+
+ The deployer can select to upload the keytab files for the AM and the
application to an HDFS directory (with appropriate permissions set) and slider
will localize the keytab files to locations accessible by the AM or the
application containers:
+
+ . . .
+ "components": {
+ "slider-appmaster": {
+ "jvm.heapsize": "256M",
+ "slider.hdfs.keytab.dir": ".slider/keytabs/hbase",
+ "slider.am.login.keytab.name": "hbase.headless.keytab"
+ }
+ }
+
+ The âslider.hdfs.keytab.dirâ points to an HDFS path, relative to the
userâs home directory (e.g. /users/hbase), in which slider can find all
keytab files required for both AM login as well as application services (e.g.
for hbase that would be the headless keytab for the AM and the service keytab
for the HBase application components). If no value is specified, a default
location of â.slider/keytabs/<cluster name>â is assumed.
+ The âslider.am.login.keytab.nameâ is the name of the keytab file
(mandatory property), found within the specified directory, that the AM will
use to lookup up the login principal and authenticate.
+
+ If leveraging the slider-based distribution mechanism, the keytab files for
components will be accessible from a âkeytabsâ sub-directory of the
container work folder, e.g.:
+
+ . . .
+ "site.hbase-site.hbase.master.kerberos.principal":
"hbase/_h...@example.com",
+ "site.hbase-site.hbase.master.keytab.file":
"${AGENT_WORK_ROOT}/keytabs/hbase.service.keytab",
+ . . .
+
+ For both mechanisms above, the principal name used for authentication is
either:
+
+* The principal name established on the client side before invocation of the
Slider CLI (the principal used to âkinitâ) or
+* The value specified for a âslider.keytab.principal.nameâ property.
## Securing communications between the Slider Client and the Slider AM.
