Status:

The project, although is still ongoing, could not be finalized until September 23, the date that marks the end of the coding period of Google Summer of Code. Caused mainly by the problems encountered during utilization of Cyrus SASL library (e.g. Cyrus SASL mailing list not being responsive at the time) the authenticator classes produced until the end of GSoC coding period could not be integrated into Mesos source code, yet. Still, the project is to continue, under the supervision of Vinod Kone, the GSoC mentor of this project, and Mesos community in general, according to the roadmap below.

Goal:

The goal of this project is to make the communication between the components that form Mesos more secure by solving the authentication part of the JIRA issue MESOS-418. The project is also a Google Summer of Code project.

Scope:

The project involves adding an authentication stage before letting frameworks and slaves talk to the master(s) thereby making the communication between the modules forming Mesos (masters, slaves and frameworks) secure.

Technical Details:

For authentication support, the initial idea was making use of Kerberos as a mechanism for authentication, just as Hadoop offers. But, providing alternative authentication mechanisms to Kerberos would make Mesos available to systems that are not able to support Kerberos. To be able to flexibly deal with multiple different authentication mechanisms, it was better to create an abstraction between Mesos and the relevant authentication mechanisms. This way, community of Mesos developers could more freely choose and more easily implement and update the authentication mechanisms they use. As a result, Cyrus SASL library is chosen to be used by the authentication abstraction as it supports multiple authentication mechanisms and has a generic authentication negotiation process for all the mechanisms it supports.

The details will be clarified further as the project progresses, and they will be reflected to this wiki page.

Roadmap:

Find out how authentication is handled by others(e.g. Hadoop)

Examine how others implemented Cyrus SASL(e.g. sendmail, Cyrus IMAP)

Produce a client and a server class with ANONYMOUS authentication capabilities (Go to repo)

Migrate the produced classes into Mesos source (initial reviews here and here)

Add EXTERNAL mechanism support to the existing authentication abstraction

Study GSSAPI(Kerberos 5) requirements and implementation in Cyrus SASL library

Add GSSAPI mechanism support to the existing authentication abstraction

Study shared secret mechanism Cyrus SASL supports

Address how Mesos could overcome issues such as distributing the keys through the system components

Add a shared secret mechanism support to the existing authentication abstraction

Got time left? Test, refactor, debug, and even go on with the rest of issue MESOS-418.

References:

https://issues.apache.org/jira/browse/MESOS-418

http://www.google-melange.com/gsoc/project/google/gsoc2013/ilimugur/42002

http://web.mit.edu/kerberos/

http://blog.cloudera.com/blog/2012/03/authorization-and-authentication-in-hadoop/

http://cyrusimap.web.cmu.edu/

http://docs.oracle.com/cd/E19253-01/816-4863/index.html

http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xml

http://stackoverflow.com/questions/11347304/security-authentication-ssl-vs-sasl

http://www.cloudera.com/content/cloudera-content/cloudera-docs/CDH3/CDH3u6/CDH3-Security-Guide/cdh3sg_topic_2.html

http://tools.ietf.org/html/draft-ietf-abfab-gss-eap-09

  • No labels