Draft: PoC: Settings enforcement policies

Dominic Bauerrequested to merge
poc/settings-enforcement-converge-fence into master

What does this MR do and why?

This is a draft proof-of-concept MR for the settings enforcement policies feature of the Policy Store experiment. It is not meant to merge as-is. It exists to share the working prototype with the team and to run it through CI end to end. The plan is to extract the components below into separate, reviewable MRs once the approach is validated.

The model is converge-then-fence. A policy binds one of three triggers:

  • Project Settings Change: checks a proposed settings write before it reaches the database. Enforce mode refuses a violating write with the policy author's message; warn mode lets the change through and shows the message as a warning.
  • Project Created: after a project is created or moved into scope, the required values get written onto it through the normal update services.
  • Periodic Project Settings Check: a daily system check records violations, and with a Set Project Setting action in enforce mode, it writes the required value back. The first check runs right after a policy is created or materially changed, so new policies take effect immediately. It is the only pass a policy save starts: a policy on the other two triggers records nothing until its event fires.

Rules validate a setting against an expected value, checked at save time against a catalog of 17 project settings in the gitlab-policy-store gem. Actions cover blocking a change, setting a value, and logging to the audit trail, and the store rejects any rule/action/trigger combination that does not fit.

On the host side, this adds a save-time fence in Projects::UpdateService that fails open if the engine is unreachable, an evaluation service built on the gitlab-glaz 2.0.0 gem, a converge executor that writes through normal update services, a daily schedule worker with a targeted first tick, a reconciliation worker for project created and transferred events, an on-demand impact pass worker that records which projects violate a policy, Policy Store editor UI support, and a documentation page.

Everything is behind the security_policies_v2 feature flag, the policy_store_experiment_enabled application setting, and an Ultimate license.

References

Screenshots or screen recordings

None attached here. A recorded demo of the UI flow exists separately. The Policy Store editor changes shown in that demo are part of this PoC.

How to set up and validate locally

Run the specs:

  • ee/spec/requests/govern/settings_enforcement_demo_spec.rb, a request-level scenario spec that replays the recorded three-policy demo against a fake in-process glaz engine (only the FFI boundary is faked).
  • ee/spec/features/projects/settings/settings_enforcement_policy_spec.rb, a browser feature spec for the fence on the merge requests settings page.

Or validate against a real glaz policy store: set GLAZ_POLICY_STORE_URL and GLAZ_POLICY_STORE_TOKEN, create the three policies through the Policy Store UI, then exercise each trigger by creating a project, changing a merge check, and saving a policy on the periodic trigger.

Skipped CI checks

  • cells-routes:router-in-sync is skipped with pipeline:skip-router-sync: this MR adds the /api/:version/security/policy_store/settings route, which the HTTP Router has not seen yet.
  • db:check-migrations is skipped with pipeline:skip-check-migrations: rolling back this MR's migrations re-dumps master's own ai_events_counts table at a different position in db/structure.sql. This MR does not touch that table, so the reported diff is the documented false positive.
  • rspec:undercoverage is skipped with pipeline:skip-undercoverage: the job reports 33 nodes whose error and nil-guard branches no spec reaches. Covering them belongs to the MRs that this PoC gets split into, where each component arrives with its own spec file. The waiver does not carry over to those MRs.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Dominic Bauer

Merge request reports