@mpopov and I (@dr0ptp4kt) worked through the permission scheme for GrowthBook and think we have arrived at the roles needed. We are seeking review from @JVanderhoop-WMF and @KReid-WMF and confirmation of role permissions here in-task. I've added a number of other task subscribers for visibility.
Initial role assignment will be coordinated in several larger requests in order to reduce up-front form submissions. Subsequent access will need to be done on a case-by-case basis.
**Roles**
It's thought that it's best to keep the roles simple. It was hoped to avoid needing a custom role, but to minimize easily avoidable mistakes and to minimize showing irrelevant parts of the GrowthBook application we don't foresee supporting or using anytime soon, one custom role is required. Custom roles are an Enterprise feature.
The plan is three tiers of access, as follows.
//Read Only// users, a built-in role of GrowthBook, whose only permission is as follows. This would be the bulk of user seats.
{F72797441}
//CustomElevatedAccess// users, who have the permissions detailed below. This is meant for people who need to drive experiment and data analysis configuration. It's expected this will usually be A/B test fluent people with software/data/research engineer/scientist/analyst titles.
//Admin// users, a built-in role of GrowthBook, who have all permissions. This is meant to be a shortlist including Ben, Balthazar, and select members of Experiment Platform Team, with occasional membership involving other DPE team members where this highest level of access is useful and necessary and comes with heightened expectations. This is for people who are fluent in the system and will do work involving approval of access, and who otherwise could be tasked with configuration of data sources, dimensions, SDK configuration (e.g., Attributes), and system Settings.
The (OSS, not Enterprise) concept of a Project in GrowthBook will need to be implemented, and the GrowthBook role for Read Only or CustomElevatedAccess will only be granted within the designated Project.
**Process**
# The WMF or WMDE staff member or contractor requiring access will visit https://idm.wikimedia.org/permissions/ and request access for the [[ https://wikitech.wikimedia.org/wiki/IDM | Wikimedia IDM ("Bitu") ]] group for their level of GrowthBook access required: `GrowthBook-ReadOnly`, `GrowthBook-CustomElevatedAccess`, or `GrowthBook-Admin` (all three of these Bitu roles will need to be added to `nda_groups.txt` [and possibly more] via {T419021}, by the way).
# A member of Experiment Platform Team (or other GrowthBook Admin if no Experiment Platform Team member is available) will review the request, verifying:
## That the WMF or WMDE staff member request is for a user with an email domain of `wikimedia.org` or `wikimedia.de` (this can be verified at `https://ldap.toolforge.org/user/<username>`)
## The presence of the WMF or WMDE staff member or contractor's membership in the `wmf` or `wmde` LDAP group (this can be verified via https://ldap.toolforge.org/ ).
## That the WMF or WMDE staff member or contractor's ID in `data.yaml` is active (i.e., has `ensure: present`).
## The presence of the WMF or WMDE staff member or contractor's membership in the `analytics_privatedata_users` group in `data.yaml`. This is **required for all GrowthBook users**. Membership in this group is sufficient for `GrowthBook-ReadOnly` access.
## If `GrowthBook-CustomElevatedAccess` is requested, additionally that the WMF or WMDE staff member or contractor's ID in `data.yaml` is a member of `analytics-product-users`, `analytics-wmde-users`, or `deployment` in `data.yaml`.
## If `GrowthBook-Admin` is requested, additionally the user must be a member of Experiment Platform Team or Data Platform Engineering where this access level is useful and necessary and comes with heightened expectations. This is for people who are fluent in the system and will do work involving approval of access, and who otherwise could be tasked with configuration of data sources, dimensions, SDK configuration (e.g., Attributes), and system Settings. **Confirmation of this level of access need should be coordinated on an org-facing DPE IM channel.**
# Assuming everything checks out, the team member in Experiment Platform Team (or other GrowthBook Admin if no Experiment Platform Team member is available) will grant the access in Wikimedia IDM ("Bitu"). We would like, if possible, for the Wikimedia IDM ("Bitu") roles of `GrowthBook-ReadOnly` or `GrowthBook-CustomElevatedAccess` to be automatically provisioned if the constraints in 2.* are satisfied, but we are unclear if this is possible (writes to LDAP can be more complicated than reads from LDAP, and are often achieved by a human in the loop); automatic provisioning of `GrowthBook-Admin` should not occur and should require manual human involvement.
# An Experiment Platform Team member (or other GrowthBook Admin if no Experiment Platform Team member is available) should follow up with the requester on the talk-to channel on Slack to check back in 120 minutes to confirm that they are able to see material in the designated Project, and to point them to the access instructions to be reminded of system expectations. In case the LDAP provisioning becomes automated, there will need to be some means for the Experiment Platform Team member (or other GrowthBook Admin if no Experiment Platform Team member is available) to know to follow up (or a bot that notifies on the IM channel will be needed; this IM automation may be more complicated than is worth it although there are hooks for IM used in some cases today). Here's some language that can be put into the access instructions as an example:
> When you use GrowthBook, as with other systems, it comes with the expectation that you will not attempt to subvert the system's security controls, that you will not share your access credentials, that you won't use the software with prohibited data or in prohibited jurisdictions, and that you will be mindful that the system is used for configuration and measurement of experiments and so it's important to exercise caution in use of the application's facilities. We use the Enterprise version of this software, relying on its stock OSS functionality as well as the Enterprise functionality; the Enterprise functionality is governed under separate terms from the OSS portion of the software, so we don't extend the software package in general (and where we do, we do so so only in conversation and alignment with GrowthBook). If you have any questions, please do let us know in the talk-to IM chat channel with Experiment Platform Team.
The message from the member of Experiment Platform Team (or other GrowthBook Admin if no Experiment Platform Team member is available) or bot (depending on bot capabilities) on IM can say something like
> Your access to GrowthBook has been granted. Please visit `https://growthbook.wikimedia.org/` in 120 minutes to verify your access to the <project name TBD> Project. As a reminder, please take note of the system expectations at <link>.
**Enforcement**
A script (e.g., k8s CronJob) will need to recurrently:
# Ensure synchronization of Bitu access level with growthbook.wikimedia.org and growthbook-next.wikimedia.org (e.g., every 10-30 minutes) in the designated Project. In case a user occupies multiple applicable LDAP roles, the LDAP role with the higher level of access corresponding to the appropriate role in GrowthBook should be the one that is assigned in GrowthBook (e.g., if a user has both `GrowthBook-ReadOnly` and `GrowthBook-CustomElevatedAccess` then they should be granted `CustomElevatedAccess`).
# Ensure that violations of conditions 2.A, 2.B, 2.C, or 2.D, 2.E, or 2.F result in appropriate revocation of the Project-mapped GrowthBook role(s). If 2.A, 2.B, 2.C, or 2.D are violated, all roles should be revoked.
# If 2.A, 2.B, 2.C, or 2.D are violated or if a user hasn't logged into GrowthBook within 90 days, then issue a "Remove User" API call to GrowthBook. The "Remove User" call marks the record as inactive in GrowthBook's user database; reactivation can occur upon successful login (subsequent access to the Project is subject to 2.A, 2.B, 2.C, and 2.D being met, minimally, by way of synchronization).
# Report on user seating (probably a combination of a regular report, plus alerting in case active seating is nearing agreed limits requiring attention).
Separate tasks to be filed. It will be advisable to configure this first for growthbook-next.wikimedia.org, and then upon verification of it working properly, growthbook.wikimedia.org.
Basic GrowthBook access is automagically provisioned by way of SSO by virtue of a user having a `wikimedia.org` (soon, `wikimedia.de`, as well) email address, and thus a Project will need to be established (to separate legitimate data access from merely being a GrowthBook user by way of SSO) and the script will be necessary to ensure that active user seats are managed within agreed plan limits.
**Review**
An annual manual review of access 3-4 months before contract renewal should be scheduled on the Experiment Platform Team calendar.
**Instructions**
Documentation of GrowthBook on Wikitech wiki will cover the access request and system expectations as noted above.
**//CustomElevatedAccess Permissions//**
Here's the exhaustive set of permissions for //CustomElevatedAccess//.
{F72797475}
{F72797478}
{F72797480}
{F72797484}
**Currently Out of Scope**
Access for individuals with email addresses outside of `wikimedia.org` and `wikimedia.de` domains is presently not forecast to be allowed. However, should this need be surfaced, it will need to be scrutinized. Strict processes and vetting would be required due to the ability of the system's service ID to access data stores bearing sensitive data and for the experiment configuration to affect production services (albeit with software verifying the scope of such experiment configuration prior to configuration deployment). It will most likely be easiest for there to be arrangement of a wikimedia.org or wikimedia.de email address, with an expiration date on its access, for granting of any further access to GrowthBook. This however is a future consideration and not one to be approached lightly.
Although growthbook-next.wikimedia.org will be useful for confirmation of basic function of the schema described in this task, and it will be useful for verification of non-breakage during GrowthBook upgrades, it isn't intended to be used for system configuration and experiment data analysis the same way as growthbook.wikimedia.org. That is to say that, although it will be important during a staged upgrade to ask a member or two below the Admin level of access to confirm they can login to growthbook-next.wikimedia.org and see the Project there, they aren't expected to be doing routine work on growthbook-next.wikimedia.org.