Team based permissions for Webhooks, Secrets and System Accounts

With the release of our Roles and Permissions feature, we gave our customers the ability to add granular controls over who can do what on our platform. One of the limitations however, was that certain items in the system were global, such as webhooks and secrets.  This restriction meant that in high security environments, only administrators could manage these resources lest any secrets be exposed to the masses. We want to enable teams do contract testing at scale, and to achieve this we envision a level of autonomy where teams are able to self-administer rather than rely on a few global admins that may be a bottleneck to productivity.

Today we'd like to announce the release of a change in this direction - team scoped Webhooks and Secrets.

How it works: the team and * scopes

Previously, these resources were implicitly created with a global scope - meaning any webhook could use any secret. This ability is maintained for administrators, where non-team resources can be created but with one minor caveat - they may only reference other non-team resources. That is, non-team webhooks may not reference a team scoped secret.

Users without these permissions must create or use a resource scoped to a team they are a member of. Extending our existing model, we have added the team and * scopes to the secret:manage and webhook:manage permissions to narrow how they may be used.

Secrets

When creating or updating a secret, users with the secret:manage:team permission (by default, assigned to the Test Maintainer role) must assign a secret to a team. Team secrets may only be used in  webhooks that are assigned to the same team. Users with the secret:manage:* permission (by default, assigned to the Administrator role) may choose not to assign a secret to any team. Secrets without a team assigned may only be used in webhooks that also have no team assigned.

Creating a secret is the same as before, however there is now an option to select a team for the webhook (or none, for a non-team scoped secret). The team list is populated by your current team membership. Administrators are also given the option not to select a team, meaning the secret is a non-team secret.

Webhooks

When creating or editing a webhook, users with the webhook:manage:team permission (by default, assigned to the Test Maintainer role) must assign a webhook to a team. Users with the webhook:manage:* permission (by default, assigned to the Administrator role) may choose not to assign a webhook to any team. Team selection affects which secrets are available for use in the webhook.

Creating a webhook is similar. The dynamic substitution variables are also updated based on the team that you select.

System Accounts

Lastly, we've added the system_account:manage:team permission, to allow users to manage System Accounts that belong to their team. Users with this permission are able to create, read, update and delete a System Account associated with their own team.

Users with the system_account:manage:* may create and manage System Accounts associated with a team, or no team, as per webhooks and secrets.

Existing accounts

To avoid confusion and prevent introducing changes that might upset your security teams, the default roles within existing accounts have not had any permissions updated. You may simply update the permissions for existing roles (such as the Test Maintainer), swapping any * permission for the team one. The effect will be to prevent a Test Maintainer from being able to manage non-team secrets and webhooks.

The built-in roles for new accounts will automatically have the new permissions enabled by default.

Available now

We believe this change will both improve our security posture and simplify the way teams setup their CI/CD pipelines with Pactflow, making it easier to administer Pactflow as you scale to dozens or hundreds of teams.

Team scoped permissions are available now on all plans.