@@ -25,93 +25,93 @@ import org.apache.hadoop.io.Text
25
25
26
26
import org .apache .spark .deploy .SparkHadoopUtil
27
27
28
- /**
29
- * Spark class responsible for security.
30
- *
28
+ /**
29
+ * Spark class responsible for security.
30
+ *
31
31
* In general this class should be instantiated by the SparkEnv and most components
32
- * should access it from that. There are some cases where the SparkEnv hasn't been
32
+ * should access it from that. There are some cases where the SparkEnv hasn't been
33
33
* initialized yet and this class must be instantiated directly.
34
- *
34
+ *
35
35
* Spark currently supports authentication via a shared secret.
36
36
* Authentication can be configured to be on via the 'spark.authenticate' configuration
37
- * parameter. This parameter controls whether the Spark communication protocols do
37
+ * parameter. This parameter controls whether the Spark communication protocols do
38
38
* authentication using the shared secret. This authentication is a basic handshake to
39
39
* make sure both sides have the same shared secret and are allowed to communicate.
40
- * If the shared secret is not identical they will not be allowed to communicate.
41
- *
42
- * The Spark UI can also be secured by using javax servlet filters. A user may want to
43
- * secure the UI if it has data that other users should not be allowed to see. The javax
44
- * servlet filter specified by the user can authenticate the user and then once the user
45
- * is logged in, Spark can compare that user versus the view acls to make sure they are
46
- * authorized to view the UI. The configs 'spark.ui.acls.enable' and 'spark.ui.view.acls'
40
+ * If the shared secret is not identical they will not be allowed to communicate.
41
+ *
42
+ * The Spark UI can also be secured by using javax servlet filters. A user may want to
43
+ * secure the UI if it has data that other users should not be allowed to see. The javax
44
+ * servlet filter specified by the user can authenticate the user and then once the user
45
+ * is logged in, Spark can compare that user versus the view acls to make sure they are
46
+ * authorized to view the UI. The configs 'spark.ui.acls.enable' and 'spark.ui.view.acls'
47
47
* control the behavior of the acls. Note that the person who started the application
48
48
* always has view access to the UI.
49
49
*
50
50
* Spark does not currently support encryption after authentication.
51
- *
51
+ *
52
52
* At this point spark has multiple communication protocols that need to be secured and
53
53
* different underlying mechanisms are used depending on the protocol:
54
54
*
55
- * - Akka -> The only option here is to use the Akka Remote secure-cookie functionality.
56
- * Akka remoting allows you to specify a secure cookie that will be exchanged
57
- * and ensured to be identical in the connection handshake between the client
58
- * and the server. If they are not identical then the client will be refused
59
- * to connect to the server. There is no control of the underlying
60
- * authentication mechanism so its not clear if the password is passed in
55
+ * - Akka -> The only option here is to use the Akka Remote secure-cookie functionality.
56
+ * Akka remoting allows you to specify a secure cookie that will be exchanged
57
+ * and ensured to be identical in the connection handshake between the client
58
+ * and the server. If they are not identical then the client will be refused
59
+ * to connect to the server. There is no control of the underlying
60
+ * authentication mechanism so its not clear if the password is passed in
61
61
* plaintext or uses DIGEST-MD5 or some other mechanism.
62
62
* Akka also has an option to turn on SSL, this option is not currently supported
63
63
* but we could add a configuration option in the future.
64
- *
65
- * - HTTP for broadcast and file server (via HttpServer) -> Spark currently uses Jetty
66
- * for the HttpServer. Jetty supports multiple authentication mechanisms -
67
- * Basic, Digest, Form, Spengo, etc. It also supports multiple different login
64
+ *
65
+ * - HTTP for broadcast and file server (via HttpServer) -> Spark currently uses Jetty
66
+ * for the HttpServer. Jetty supports multiple authentication mechanisms -
67
+ * Basic, Digest, Form, Spengo, etc. It also supports multiple different login
68
68
* services - Hash, JAAS, Spnego, JDBC, etc. Spark currently uses the HashLoginService
69
- * to authenticate using DIGEST-MD5 via a single user and the shared secret.
69
+ * to authenticate using DIGEST-MD5 via a single user and the shared secret.
70
70
* Since we are using DIGEST-MD5, the shared secret is not passed on the wire
71
71
* in plaintext.
72
72
* We currently do not support SSL (https), but Jetty can be configured to use it
73
73
* so we could add a configuration option for this in the future.
74
- *
74
+ *
75
75
* The Spark HttpServer installs the HashLoginServer and configures it to DIGEST-MD5.
76
- * Any clients must specify the user and password. There is a default
76
+ * Any clients must specify the user and password. There is a default
77
77
* Authenticator installed in the SecurityManager to how it does the authentication
78
78
* and in this case gets the user name and password from the request.
79
79
*
80
- * - ConnectionManager -> The Spark ConnectionManager uses java nio to asynchronously
81
- * exchange messages. For this we use the Java SASL
82
- * (Simple Authentication and Security Layer) API and again use DIGEST-MD5
80
+ * - ConnectionManager -> The Spark ConnectionManager uses java nio to asynchronously
81
+ * exchange messages. For this we use the Java SASL
82
+ * (Simple Authentication and Security Layer) API and again use DIGEST-MD5
83
83
* as the authentication mechanism. This means the shared secret is not passed
84
84
* over the wire in plaintext.
85
85
* Note that SASL is pluggable as to what mechanism it uses. We currently use
86
86
* DIGEST-MD5 but this could be changed to use Kerberos or other in the future.
87
87
* Spark currently supports "auth" for the quality of protection, which means
88
88
* the connection is not supporting integrity or privacy protection (encryption)
89
- * after authentication. SASL also supports "auth-int" and "auth-conf" which
89
+ * after authentication. SASL also supports "auth-int" and "auth-conf" which
90
90
* SPARK could be support in the future to allow the user to specify the quality
91
- * of protection they want. If we support those, the messages will also have to
91
+ * of protection they want. If we support those, the messages will also have to
92
92
* be wrapped and unwrapped via the SaslServer/SaslClient.wrap/unwrap API's.
93
- *
94
- * Since the connectionManager does asynchronous messages passing, the SASL
93
+ *
94
+ * Since the connectionManager does asynchronous messages passing, the SASL
95
95
* authentication is a bit more complex. A ConnectionManager can be both a client
96
96
* and a Server, so for a particular connection is has to determine what to do.
97
- * A ConnectionId was added to be able to track connections and is used to
97
+ * A ConnectionId was added to be able to track connections and is used to
98
98
* match up incoming messages with connections waiting for authentication.
99
99
* If its acting as a client and trying to send a message to another ConnectionManager,
100
100
* it blocks the thread calling sendMessage until the SASL negotiation has occurred.
101
101
* The ConnectionManager tracks all the sendingConnections using the ConnectionId
102
102
* and waits for the response from the server and does the handshake.
103
103
*
104
- * - HTTP for the Spark UI -> the UI was changed to use servlets so that javax servlet filters
104
+ * - HTTP for the Spark UI -> the UI was changed to use servlets so that javax servlet filters
105
105
* can be used. Yarn requires a specific AmIpFilter be installed for security to work
106
106
* properly. For non-Yarn deployments, users can write a filter to go through a
107
107
* companies normal login service. If an authentication filter is in place then the
108
108
* SparkUI can be configured to check the logged in user against the list of users who
109
109
* have view acls to see if that user is authorized.
110
- * The filters can also be used for many different purposes. For instance filters
110
+ * The filters can also be used for many different purposes. For instance filters
111
111
* could be used for logging, encryption, or compression.
112
- *
112
+ *
113
113
* The exact mechanisms used to generate/distributed the shared secret is deployment specific.
114
- *
114
+ *
115
115
* For Yarn deployments, the secret is automatically generated using the Akka remote
116
116
* Crypt.generateSecureCookie() API. The secret is placed in the Hadoop UGI which gets passed
117
117
* around via the Hadoop RPC mechanism. Hadoop RPC can be configured to support different levels
@@ -121,7 +121,7 @@ import org.apache.spark.deploy.SparkHadoopUtil
121
121
* to reduce the possibility of web based attacks through YARN. Hadoop can be configured to use
122
122
* filters to do authentication. That authentication then happens via the ResourceManager Proxy
123
123
* and Spark will use that to do authorization against the view acls.
124
- *
124
+ *
125
125
* For other Spark deployments, the shared secret must be specified via the
126
126
* spark.authenticate.secret config.
127
127
* All the nodes (Master and Workers) and the applications need to have the same shared secret.
@@ -152,7 +152,7 @@ private[spark] class SecurityManager(sparkConf: SparkConf) extends Logging {
152
152
" are ui acls enabled: " + uiAclsOn + " users with view permissions: " + viewAcls.toString())
153
153
154
154
// Set our own authenticator to properly negotiate user/password for HTTP connections.
155
- // This is needed by the HTTP client fetching from the HttpServer. Put here so its
155
+ // This is needed by the HTTP client fetching from the HttpServer. Put here so its
156
156
// only set once.
157
157
if (authOn) {
158
158
Authenticator .setDefault(
@@ -214,12 +214,12 @@ private[spark] class SecurityManager(sparkConf: SparkConf) extends Logging {
214
214
def uiAclsEnabled (): Boolean = uiAclsOn
215
215
216
216
/**
217
- * Checks the given user against the view acl list to see if they have
217
+ * Checks the given user against the view acl list to see if they have
218
218
* authorization to view the UI. If the UI acls must are disabled
219
219
* via spark.ui.acls.enable, all users have view access.
220
- *
220
+ *
221
221
* @param user to see if is authorized
222
- * @return true is the user has permission, otherwise false
222
+ * @return true is the user has permission, otherwise false
223
223
*/
224
224
def checkUIViewPermissions (user : String ): Boolean = {
225
225
if (uiAclsEnabled() && (user != null ) && (! viewAcls.contains(user))) false else true
0 commit comments