Change Details

**DRAFTING, MORE UPDATES TO COME** @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. 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/ ). ## The presence of the WMF or WMDE staff member or contractor's membership in the `analytics_privatedata_users` group in `data.yaml`. ## That the WMF or WMDE staff member or contractor's ID in `data.yaml` is active (i.e., has `ensure: present`). ** If //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. ** 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"), and ask the requester on the talk-to channel on Slack to check back in 90 minutes to confirm that they are able to see material in the designated Project, and to point them back to the access instructions to be reminded of system expectations. Here's some language that can be put into the access instructions as an example. > As you know, we take privacy and security seriously. 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 Experiment Platform Team member can say something like, "As a reminder, please do note the system expectations at <link>." **Enforcement** A script (e.g., k8s CronJob) will need to recurrently: # Ensure synchronization of Bitu access level with GrowthBook (e.g., every hour). Violations of conditions 2.A, 2.B, 2.C, or 2.D should result in revocation of the Project-mapped GrowthBook role. # Issue a "Remove User" API call to GrowthBook for user IDs that are no longer active in LDAP, are no longer associated with wikimedia.org or wikimedia.de domain names, or that haven't been used within the previous 90 days. The "Remove User" call marks the record as inactive in GrowthBook's user database; reactivation can occur upon successful login (provided the user is an active member of CAS-SSO Apereo). # Report on user seating (probably a combination of a regular report, plus alerting in case active seating is nearing agreed limits requiring attention) Separate task to be filed. ** TO BE CONTINUED: STILL NEED TO CONTINUE EDITING THE FOLLOWING ** Access is automagically provisioned by virtue of a user having a `wikimedia.org` or `wikimedia.de` email addressed with SSO, 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. **Instructions** Documentation of GrowthBook on Wikitech wiki, and a periodic message via a messaging platform, will note in simplified terms the key expectations for use of GrowthBook. **//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.

**DRAFTING, MORE UPDATES TO COME** @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. 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/ ). ## The presence of the WMF or WMDE staff member or contractor's membership in the `analytics_privatedata_users` group in `data.yaml`. ## That the WMF or WMDE staff member or contractor's ID in `data.yaml` is active (i.e., has `ensure: present`). ## 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 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 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 Experiment Platform Team member (or bot) 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 and navigate to the <project name TBD> Project. As a reminder, please do note the system expectations at <link>. **Enforcement** A script (e.g., k8s CronJob) will need to recurrently: # Ensure synchronization of Bitu access level with GrowthBook (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 revocation of the Project-mapped GrowthBook role(s). # Issue a "Remove User" API call to GrowthBook for user IDs that are no longer active in LDAP, are no longer active in `data.yaml`, are no longer associated with wikimedia.org or wikimedia.de domain names, or that haven't been used within the previous 90 days. The "Remove User" call marks the record as inactive in GrowthBook's user database; reactivation can occur upon successful login (provided the user is an active member of CAS-SSO Apereo). # Report on user seating (probably a combination of a regular report, plus alerting in case active seating is nearing agreed limits requiring attention) Separate task to be filed. 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. **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.

**DRAFTING, MORE UPDATES TO COME** @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. 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/ ). ## The presence of the WMF or WMDE staff member or contractor's membership in the `analytics_privatedata_users` group in `data.yaml`. ## That the WMF or WMDE staff member or contractor's ID in `data.yaml` is active (i.e., has `ensure: present`). ** If //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. ## 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 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 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); the team member in Experiment Platform Teamautomatic 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) will grant the access in Wikimedia IDM ("Bitu")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 ask the requester on the talk-to channel on Slack to check back in 90 minutes to confirm that they are able to see material in the designated Project,to point them to the access instructions to be reminded of system expectations. and to pointIn case them back to the access instructions to be reminded of system expectations. LDAP provisioning becomes automated, Here's some language that can be put into the access instructions as an example. > As you know,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). we take privacy and security seriously.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 Experiment Platform Team member (or bot) on IM can say something like,ke > Your access to GrowthBook has been granted. "As a reminder,Please visit `https://growthbook.wikimedia.org/` in 120 minutes to verify your access and navigate to the <project name TBD> Project. As a reminder, please do note the system expectations at <link>." **Enforcement** A script (e.g., k8s CronJob) will need to recurrently: # Ensure synchronization of Bitu access level with GrowthBook (e.g., every hour).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., Vif 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.D shouldF result in revocation of the Project-mapped GrowthBook role(s). # Issue a "Remove User" API call to GrowthBook for user IDs that are no longer active in LDAP, are no longer active in `data.yaml`, are no longer associated with wikimedia.org or wikimedia.de domain names, or that haven't been used within the previous 90 days. The "Remove User" call marks the record as inactive in GrowthBook's user database; reactivation can occur upon successful login (provided the user is an active member of CAS-SSO Apereo). # Report on user seating (probably a combination of a regular report, plus alerting in case active seating is nearing agreed limits requiring attention) Separate task to be filed. ** TO BE CONTINUED: STILL NEED TO CONTINUE EDITING THE FOLLOWING ** ABasic GrowthBook access is automagically provisioned by way of SSO by virtue of a user having a `wikimedia.org` or(soon, `wikimedia.de`, as well) email addressed with SSO, 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. **Instructions** Documentation of GrowthBook on Wikitech wiki, and a periodic message via a messaging platform, will note in simplified terms the key will cover the access request and system expectations for use of GrowthBookas 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.