In this post we will talk about the new Contribution filter feature introduced in release 270, what it is for and how it works.

INTRO
what are we trying to solve, how does contribution filter solve this
As the number of your Instana users increase, finding the right balance between autonomy and compliance can become more difficult over time. The increasing need to equip users with access to configuring their own environment should not come at the cost of accidentally deleting or changing items someone else relies on. Users responsible for application A should be able to
perform administrative tasks for their application, but not be able to modify anything related to Application B.
To make sure in an ever-growing Instana usage, the administrators don’t become a bottleneck in assuring compliance with restricted access, providing limited scopes and maintaining the right access, we’ve introduced the Contributor access type and the Contribution filter for Application perspectives.
Using the Contributor access type, admins can now define a specific Application scope with the Contribution filter, which allows group members to create new perspectives or update the existing configurations, while being assured the change stays within the boundaries of responsibility.
You can now provide nuanced and differentiated access, providing the needed autonomy confined by the Contribution filter, while read-only access can be retained for everything else.

HOW TO
create a contributor group
For our first example we will consider the following scenario focusing only on the Application aspect of the setup:
You are onboarding a new Application team to your existing Instana account, who’s only responsibility lies in Application A, which is hosted in a Kubernetes Namespace “App-A”

While creating the new group as you normally would, in the Application section you will select Limited access, then under Access type pick Contributor.
In the new mandatory section for Contributors you will define the Contribution filter, starting with the Contribution filter name. (By default this will be the group name: “Application A-team”)
The Contribution filter can use any of our Query Builder tag expressions to restrict
access to a specific set of objects such as services, hosts, namespaces or even specific technologies, which don’t necessarily have to correspond to an Application.
In our example, the new team only needs to work on their application in their dedicated namespace, the Contribution filter could be as follows: “Dest / Kubernetes > Namespace = App-A”
Here, the maximum level of permitted downstream access can also be picked, gradually limiting the options for Contributors.

The Contribution filter will be created as a new restricted Application perspective upon creating the group. This Application perspective cannot be edited or deleted from the Application interface and will stay in the access scope of the group as long as they are a Contributor access type. Anyone else on the unit will see it as a read-only AP with Access all scopes defined.

As an optional next step a limited viewer access scope can also be defined for further Application perspectives, for example for shared, common components, like a login service called “Login Service”.
Let’s say we saved the group and already added some members to this new group.

Note: API call example provided at the end of this post

The members of this new group at this point will see two Applications in their list: “Application A-team” and “Login Service”
Both of these APs are available with read-only access, however, they can create a new Application perspective.
The new Application perspective dialog is enhanced in this case with the Contribution filter, which the users cannot remove and is appended with an ‘AND’ clause to whatever filter they define. This ensures, that any filter they define will always be restricted to their defined scope.
Creating the new Application perspective using a Contribution filter will be automatically added to the access scope for the contributing group, be immediately accessible, as well as editable and removable for members.
The effective AP filter will be a combination of Contribution filter and the configured filter.

Congratulations, you now have a contributor group with two view-only (“Application A-team” and “Login Service”) and one configurable Application perspective!

update a group to contributor
For our second example we will consider an existing Application group (Application B-team“) who are using Instana with default viewer access on everything. They are responsible for “Application B”, but to avoid accidental changes made or compliance reasons, they rely on members of the Owner group to make adjustments to the Application perspective.
For this example the goal is to allow this team to keep their viewer access to everything, but allow them to configure Application B.
To achieve this the following needs to be done:
Edit the Access configuration for the group from the Group details page.
Under the Applications section keep Access all and select Contributor instead of Viewer in the access type dropdown.
Assuming the same scenario as the first example, define the Contribution filter: “Dest / Kubernetes > Namespace = App-B”
Depending on your specific situation, using the same application filter as the existing “Application B” can also be a good option.

OTHER ACTIONS
updating contribution filter
The Contribution filter can only be updated from group Access configuration and needs to “Access group configuration” permission. Updating the Contribution filter will apply the changes to the effective filter of all contributed APs immediately.

what happens when deleting a group
Deleting a contributor group will unlink the Contribution filter and all contributed APs created using it. The Contribution filter AP becomes configurable for anyone with Owner access type on Applications. Contributed APs get the Contribution filter merged into their Application filter to assure the effective filter doesn’t change, but also become configurable for anyone with Owner access type on Applications.
Note: Deleting a group will also delete the Access configuration on remote units in the same tenant. If the Contribution filter is defined on the remote unit, the unlink process can take up to 24 hours to be executed.

when changing access type
Similarly to deleting the group, changing the Access type from Contributor to Viewer or Owner will unlink the Contribution filter and all contributed APs, merging the Contribution filter to all contributed APs and make them become configurable for anyone with Owner access type on Applications.

how are other users affected
Users being member of a different group will interact with Application perspectives created by Contributors based on their Access configuration. Anyone with Access all on Applications feature will see the created contributed APs and will be able to edit if they have access type Owner.
The Contribution filter AP is only configurable with “Access group configuration” and does not depend on Application access scope.

multiple contributor memberships
For Owners or someone in an architect or enablement role can be member of multiple groups with Contribution filter. In this case the new Application perspective dialog will have the option to pick from all available Contribution filters, as well as “No contribution filter” when at least one group provides the access type Owner for Applications.
The created AP will be linked to the appropriate contribution group access scope and will be editable by the contributor group members.

API HOW-TO EXAMPLES
Note: child APs can only be created from UI and not through API during group creation

API Call for example one:
POST: https://yourunit-company.instana.io/api/settings/rbac/groups
https://instana.github.io/openapi/#operation/createGroup

{
    "name": "Application A-team",
    "members": [],
    "permissionSet": {
      "id": null,
      "name": "system_permission_set",
      "permissions": [
        "CAN_VIEW_TRACE_DETAILS",
        "CAN_VIEW_LOGS",
        "CAN_VIEW_SYNTHETIC_TESTS",
        "CAN_VIEW_SYNTHETIC_TEST_RESULTS",
        "CAN_VIEW_SYNTHETIC_LOCATIONS",
        "LIMITED_APPLICATIONS_SCOPE",
        "ACCESS_APPLICATIONS"
      ],
      "kubernetesClusterUUIDs": [],
      "kubernetesNamespaceUIDs": [],
      "websiteIds": [],
      "mobileAppIds": [],
      "syntheticTestIds": [],
      "businessPerspectiveIds": [],
      "infraDfqFilter": {
        "scopeId": "",
        "scopeRoleId": "-1"
      },
      "restrictedApplicationFilter": {
        "tagFilterExpression": {
          "type": "TAG_FILTER",
          "name": "kubernetes.namespace",
          "operator": "EQUALS",
          "entity": "DESTINATION",
          "value": "Application A"
        },
        "scope": "INCLUDE_NO_DOWNSTREAM",
        "label": "Application A-team"
      },
      "applicationIds": []
    }
  }

API Call for example two:
PUT: https://yourunit-company.instana.io/api/settings/rbac/groups/{groupId}
https://instana.github.io/openapi/#operation/updateGroup

{
    "id": "jAiZ7wqvRF290FlwWkKkBA",
    "name": "Application B-team",
    "members": [],
    "permissionSet": {
      "permissions": [
        "CAN_VIEW_LOGS",
        "CAN_VIEW_SYNTHETIC_TESTS",
        "CAN_VIEW_SYNTHETIC_LOCATIONS",
        "CAN_VIEW_SYNTHETIC_TEST_RESULTS",
        "CAN_VIEW_TRACE_DETAILS"
      ],
      "kubernetesClusterUUIDs": [],
      "kubernetesNamespaceUIDs": [],
      "websiteIds": [],
      "mobileAppIds": [],
      "syntheticTestIds": [],
      "businessPerspectiveIds": [],
      "restrictedApplicationFilter": {
        "tagFilterExpression": {
          "type": "TAG_FILTER",
          "name": "service.name",
          "operator": "EQUALS",
          "entity": "DESTINATION",
          "value": "butler"
        },
        "scope": "INCLUDE_NO_DOWNSTREAM",
        "label": "Application B-team"
      },
      "infraDfqFilter": {
        "scopeId": "",
        "scopeRoleId": "-1"
      },
      "applicationIds": []
    }
  }