Mesosphere Marathon has adapted their plugin interface, offering two extension points. This includes the ability to have custom plugins handling UI/Rest based authentication as well as securing operations.
I looked around to see what has been released in the open source community and didn’t see much. I wanted to be able to lock down Marathon based on the following requirements:
- UI/REST based authentication against LDAP / Active Directory
- Ability to offer flexible configuration based on LDAP Groups, for example:
- Everyone who is authenticated should be able to see running containers
- Admins have unlimited control
- Developers can do full CRUD operations against an ID namespace of /dev
As a result of these requirements I decided to create the Marathon-LDAP Plugin. This article will cover how easy it is to secure your Marathon clusters against an LDAP server.
Installing the Marathon-LDAP Plugin
Before we get started let’s talk about requirements. The only basic requirement is you must be running the latest version of Mesosphere Marathon. As of this article this is version 1.1.1.
- Download the latest Marathon-LDAP release JAR from the GitHub Release page.
- Download the sample plugin-conf.json file as a configuration starting point.
- Add both of these files to a directory of your choosing on each Marathon node. In this guide we’ll make this directory /var/marathon/plugins
Now on each Marathon node we want to update the configuration so it knows about the new plugins. This guide assumes you’ve installed Marathon via the official Mesosphere package repository. If you’ve installed from source or other mechanisms the directories below may be in a different location.
echo "/var/marathon/plugins" > /etc/marathon/conf/plugin_dir echo "/var/marathon/plugins/plugin-conf.json" > /etc/marathon/conf/plugin_conf
Configuring Marathon-LDAP for your environment
In your favorite editor edit the /var/marathon/plugins/plugin-conf.json file.
Setting your LDAP server and domain
Within the configuration file locate the following section:
"ldap": {
"server": "ldapserver.mydomain.local",
"domain": "mydomain.local"
}
Set the server to be the FQDN of your LDAP Server. The domain is the domain used in user@ldap.domain. Set this accordingly to your setup.
Adding Permissions to your LDAP Groups
Marathon-LDAP allows you to specify Marathon App/Group operations based on CRUD and paths found within identifiers.
To grant a group full admin rights you would define the following:
{
"group": "Admin",
"permissions": [
{
"allowed": "*",
"type": "app"
},
{
"allowed": "*",
"type": "group"
}
]
}
Restricting a group to only have View rights:
{
"group": "Users",
"permissions": [
{
"allowed": "view",
"type": "app",
"path": "\/"
},
{
"allowed": "view",
"type": "group",
"path": "\/"
}
]
}
Allowing developers to have full application rights under a certain path:
{
"group": "Developers",
"permissions": [
{
"allowed": "view",
"type": "app",
"path": "\/"
},
{
"allowed": "create",
"type": "app",
"path": "\/dev"
},
{
"allowed": "update",
"type": "app",
"path": "\/dev"
},
{
"allowed": "delete",
"type": "app",
"path": "\/dev"
}
]
}
Creating static (Non-LDAP) Users
There may be tools or frameworks outside of your LDAP directory that you would like to grant access. Marathon-LDAP allows you to define static users that can authenticate, bypassing LDAP checking.
To define users you can add the following section within the configuration.
"users": [
{
"username": "someuser",
"password": "somepass",
"groups": [
"Admin"
]
}
]
Testing our Configuration
In this article we have configured a group that only has view rights. Let’s see what happens when a user try’s to create a new application.
In Conclusion
I hope this article has helped you with integration Marathon and LDAP based authentication. Please refer to the Marathon-LDAP plugin project page to obtain the latest release, file issues or of course star the plugin.