Skip to content

WIP: Feature flag permissions

Vladimir Shushlin requested to merge ff-permissions into master

What does this MR do?

Adds Permissions to feature flags based on protected environments.

We check if the user can change the value of feature flag environment scope. If users can deploy environment, they are allowed to edit feature flags.

We allow a user to create feature flags with any initial values. If the project has any protected environment and user didn't specify, we create scopes automatically based on other scopes. E.g. if user specified "*" => inactive, "review/*" => active, and project has protected environment review/my-review-branch, than default value for this scope would be active based on "review/*" => active rule.

We also add environment scope for every feature flag in the project when a user adds a protected environment. The logic for feature flag being active is the same as above.

We can not guarantee that all feature flags will always contain scopes per protected environment though. E.g. in the case when protected environments were disabled for a while someone was adding feature flags, and than protected environments were enabled. This situation is purely hypothetical though since feature flags and protected environments are available on the same tires.

Subsequent MR will add a migration for adding scopes for all existing feature flags.

https://gitlab.com/gitlab-org/gitlab-ee/issues/8239

Does this MR meet the acceptance criteria?

Conformity

Performance and testing

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

  • Label as security and @ mention @gitlab-com/gl-security/appsec
  • The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
  • Security reports checked/validated by a reviewer from the AppSec team
Edited by Vladimir Shushlin

Merge request reports

Loading