Permissions by MountPoint

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view

Permissions by MountPoint

Hey Yan,

I was wondering what the best route to go if we wanted to have deployment permissions at the mountpoint level.  Use case being we have our production fabric and we're trying a POC where developers are able to deploy the code they own but we don't want them deploying something else on accident.  Were on glu 4.7.2 right now and currently Release permissions seem to be for the entirety of the console.  

I was looking at the plugin documentation and toying with the idea of doing some sort of permission logic at with the pre_executeDeploymentPlan but I dont want to be changing this plugin all the time hardcoding every users specific permissions.  It would be really nice if there was an easy way to do this just through the console ui or at least a config file.

Is there some sort of easy way to do this?  Otherwise were considering options like just building a simple internal webapp to handle the release permissions and just hit the glu RESTApi or maybe use jenkins to manage permissions?  

Any suggestions would be greatly appreciated!  Thanks!  
Reply | Threaded
Open this post in threaded view

Re: Permissions by MountPoint


I am not entirely sure why you say that creating a plugin (for pre_executeDeploymentPlan) would require you to change the plugin every time there is a permission change. A plugin is a piece of code and as such can do anything... it does not have to be hardcoded...


class MyDevDeploymentPlugin {
  def DeploymentService_pre_executeDeploymentPlan = { args ->
    // Example 1: a file
    // check a file on the filesystem that would contain user permissions
    // if file has changed, reload file
    // check user permission and throw AccessControlException if not authorized

    // Example 2: use LDAP
    // if you already use LDAP you could also store the info in LDAP

The point is you can write any code you want in a plugin and it can access the file system, a database, ldap, a remote server, etc... it is just code. You can also implement initialize to get config parameters directly from the config file (

One thing to note though: currently the deployment action is tagged with the RELEASE role. The issue is that the "pre_executeDeploymentPlan" plugin won't even be called if the authorization does not succeed, so you have 3 solutions:

1) lower the deployment role to USER and make sure that your pre_executeDeploymentPlan plugin checks that the user is RELEASE/ADMIN in which case no further check is required or if USER, then apply your logic to check if it is an authorized developer trying to deploy its own code.

2) make all developers RELEASE but that is somewhat dangerous

3) keep the role the way they are and split your logic in 2:

a) in UserService_pre_authorize, you check that it is a deployment and that the user is either RELEASE (or ADMIN) or if only USER, then he is part of the developer list
b) in DeploymentService_pre_executeDeploymentPlan make sure that the developer is trying to deploy his own service only

Hope this helps