## Summary We must ensure features developed by ~"group::security policies" are compatible with Cells architecture. During our initial investigation, we discovered that we need to ensure that data related to Security Policy configuration cannot be shared across multiple Cells. This Epic covers these efforts. ### Problems to solve #### 1. Validation of Security Policy Project links To support features developed by ~"group::security policies," we are using a Security Policy Project that can be linked to a given Group OR Project (OR to an Organization in the [future](https://gitlab.com/groups/gitlab-org/-/epics/6881)). Internally we call this link `security_orchestration_policy_configuration`. Currently, we are not validating how the Security Policy Project is related to a linked Group or Project, so potentially, with Cells and the current architecture of Security Policies, it would be possible to have a Security Policy Project in one Cell linked to a Group or Project in a different Cell. We need to prevent this situation from happening. To resolve this, we need to add validation that will check this relationship. Ideally (and most probably as the simplest possible check), we would like to ensure that the Security Policy Project and the linked Group or Project share the same top-level group. There are 2 challenges with this approach: * what to do with the current Security Policy Projects that are would not be valid after adding this check, * should we add this validation to self-managed instances? #### 2. Software Licenses Another problem that we have identified is the `software_licenses` table that currently is used to store licenses imported from [SPDX license](https://spdx.org/licenses) database and to store custom licenses defined by customers in [Security Policies](https://docs.gitlab.com/ee/user/compliance/license_approval_policies.html). Currently, we are not storing any `project_id`/`namespace_id` that could serve as a sharding key, so this would be a first step in this case, although then we would have data that should be shared across the cluster (imported licenses from SPDX) with data that should belong to a single cell (custom licenses defined). In this case, we need to extract custom licenses from `software_licenses` into 2 tables: `custom_software_licenses` and leave `software_licenses` as a cluster-wide table with imported licenses only. #### 3. Other tables We also have other tables where we need to add sharding keys to support the new architecture properly. This should be fairly simple (especially with the validation from 1. point), although we need to decide what we would like to store in these tables. Our initial idea is to store `project_id` representing the Security Policy Project.