The current permission model for security has the ability to secure the ability to perform an action. For the majority of objects, this is either a all or nothing permission; a user can be granted the ability to edit all users or not be allowed to edit any user.

As we develop new features, such as Application Privileges (#29820), the need to further restrict the permissions on objects becomes more apparent. In the case of application privileges, the idea here would be to restrict the set of privileges a user could perform CRUD operations on. In concrete terms, an example of this would be limiting the kibana user to only be able to perform CRUD operations on the kibana application privileges and not those of other applications such as Beats or Logstash.

A few options have been proposed and discussed. The first that @tvernum proposed is to re-use the DSL from the role mapping api within roles, so for example we'd have something like the following role to limit privilege management by the application that the privileges belong to:

{
  "cluster": [
    {
      "privileges": [ "manage_privileges" ],
      "rules": {
        "field": { "application": "kibana" }
      }
    }
  ]
}

Extending this to role management, we could envision something like the following to limit roles that could be managed:

{
  "cluster": [
    {
      "privileges": [ "manage_roles" ],
      "rules": {
        "field": { "name": "sales_*" }
      }
    }
  ]
}

@clintongormley proposed a slightly different syntax that is more condensed and may be clearer to the user:

{
  "cluster":     
   {
      "privileges": { 
          "manage_privileges": { "application": "kibana" },
          "other_priv": {}
      }
    }
}

Alternatively, we could make application privileges a top level item within a role akin to cluster, indices, and run_as. This would look something like:

{
  "application": {
     "manage_privileges": {
         "applications": [ "kibana" ]
      }
  },
  "roles": {
    "manage": { "names": [ "sales_*" ] }
  }
}

This issue's purpose is to continue discussion and come to a conclusion for how we want to define and secure specific objects like application privileges.