[Authorization Interface] Create AppDefinition specific Actions, so the decision can be based on the app

[metskem]

We have been playing around with new plugin extensions documented at https://mesosphere.github.io/marathon/docs/plugin.html .

The authentication plugin is fine for us, we could implement some LDAP based authentication in there.

We also had a look at the Authorizer plugin, but we think it's usability (for us) is a bit limited because parameters passed on the isAuthorized() method do not offer enough information. The current method parameters are : Identity, Action and Path. And I think we would like to have the complete App at our disposal.

A bit background and intended use case information:

The primary use case for using the plugins is offering reliable multi-tenancy. We expect dozens of teams to work in the same mesos/marathon cluster. We like to isolate teams from each other:

• they should not see each other's apps (to prevent them from having to scroll through long lists)
• they should not be able to do anything with apps of other teams

Also, we like to put some validations in place, for example:

• put limits on the frequency of healthchecks (we have seen marathon choke in itself because of this)
• prohibit insane upgradeStrategies
• put restrictions on the use of certain constraints (maybe we have "special slave machines" that not everyone is supposed to use).
• have a sort of ownership of an app and (dis)allow actions on apps based on the ownership. I think we could use labels to administer ownership.

Also we would like to have some sort of auditing.

Since we now only have th PathId, we don't think that the above is possible.

What is your advise ?

thanks in advance, Harry

[aquamatthias]

Hey @metskem happy to hear there are users of our plugin system.

The current design is based on the idea that authorization can be defined in external systems (like LDAP) easily. You usually have the tripple: principal,action,resource - that needs to be defined in those systems:

• principal: defined and controlled in the Identity provider
• action: defined by the Marathon action
• resource: the resource to change - preferably as editable entry

• they should not see each other's apps (to prevent them from having to scroll through long lists)

Achieved with this Interface. The list of apps/groups is filtered automatically based on access rights (path)

• they should not be able to do anything with apps of other teams

Achieved with this Interface - this is the primary use of AuthZ.

• put limits on the frequency of healthchecks (we have seen marathon choke in itself because of this)
• prohibit insane upgradeStrategies
• put restrictions on the use of certain constraints (maybe we have "special slave machines" that not everyone is supposed to use).

For me this is not related to AutN/Z but to general validation. We should add a validation plugin interface for this.

• have a sort of ownership of an app and (dis)allow actions on apps based on the ownership. I think we could use labels to administer ownership.

That is a popular demand. We should add this. Can you create a separate issue for this?

[metskem]

Thanks for the response.

Ok, your first 2 answers imply that we have to base all authorization decisions on the name of the app, which means we have to enforce a strict naming convention on it. Also, the use of all other app attributes (like constraints) remains unprotected.

I will create 2 separate issues:

• provide validation plugin
• provide option to have ownership for an app

kind regards, Harry

[aquamatthias]

Hey @metskem thanks for the issues. Regarding the authorization interface: the decision is based on the pathId, which holds the information of groups (e.g. /eu/prod/myapp/db/cassandra). With this information it would be rather easy to allow access to subgroups like /eu/dev/* or /eu/prod/**/db/*.

I see also value in a decision based on the app definition. I will rename and reopen this ticket so people can vote on this.

[aquamatthias]

Hey @metskem we have changed the plugin interface and expose an AppDefinition to the plugin interface. Hope this goes into the direction you had in mind. Not 100% sure if this meets all your requirements. I will close this ticket for now - please reopen if there are still things missing.

[metskem]

I will sure take a look, I need some time to refresh my memory and update the plugins. I also have to upgrade my Marathon I think (got an AbstractMethodException), to 0.16 ? But there is no rpm for marathon 0.16 yet. So, I need some more time, but I'll have a look.

thanks for the help! regards, Harry

[metskem]

I managed to do some experimenting with it. It provides all the information I need.

Thanks !

kind regards, Harry

[aquamatthias]

Great!