( Google doc was used to create content but this Jira is the source of truth)   

Goal Summary:

Policy scopes would support 

1. Regex selection of labels for all three layers (cluster, namespace, deployment), for both inclusion and exclusion
2. Regex selection of names for all three layers (cluster, namespace, deployment), for both inclusion and exclusion. 

Goals and expected user outcomes:

As a policy editor, using UI or policy as code, 

I want a way to include and exclude clusters, namespaces and deployments using a label selector, 

so that I do not need to modify policies when my container infrastructure and workloads change. If I could use labels in the policies, then all I need to do is apply the appropriate label to the cluster or namespace as part of my automation. 

Specifically,

• RFE-6742 Customer is PCI compliant, and thus needs to apply some specific policies for PCI; but they don't want them being applied everywhere. The cluster fleet constantly evolves, and they need the ability to define the policy's scope based on labels rather than names that cannot be predicted.
• RFE-7514, Customer needs a declarative method for inclusion of clusters by labels. Without it, when securedClusters are added or removed, the inclusion/exclusion scope needs to be updated. 

Context

We currently have gaps for expressing inclusion and exclusion scopes, which limits customers who want to  apply automated processes as described above. The reason we have not improved it until now is that we were planning to replace policy scoping with Named Scopes (“Collections”). That requirement (ROX-28166)  provides multiple benefits:

1. Rich expression capabilities (this Feature)
2. Reuse named scope
3. Understand the effective scope when using regex expressions (with a preview in the UI)

Customers have provided positive feedback for the Collections concept, especially the idea of reusable, named scopes. Multiple customers are using Collections in production today, and they have been waiting for us to complete the work:

• Enable Collection to express exclusions (ROX-22481),
• Define Collections declaratively (RFE-7322)
• Then use Collections in policy scope and consistently across all UI views. 

However the development effort for Collections has stalled due to reported performance challenges in the current implementation, and no technical alternative has been proposed. At this point we have little choice but to implement the original method of specifying scopes for policies the old way, so that we can unblock our customers.

The reason why this context is explained,  is to encourage and empower Engineering to consider alternatives that may accomplish more than the immediate requirement stated in this feature, and get us closer to accomplishing the Named Scopes goals. For example, would it help if we eliminate the hierarchical embedding from Collections? 

Current functionality 

This is the functionality supported by the UI. Policy-as-code functionality is presumed to include the same at a minimum but may (or may not) be a superset. 

Exclusion	Inclusion

Acceptance Criteria:

Functional Requirements

All these requirements shall be supported with both UI and policy-as-code:

• P1:  this is the MVP required to ship
• P2:  this should be planned with all intent to deliver , but if something goes wrong we could postpone to next release
• P3, P4: This is desired in order to maintain consistency and eliminate confusion, but deemed less useful.  If we can only deliver part of it then P3 is a higher priority than P4. 

NOTE: 

It is not clear (to me - Boaz) if any of the above gaps are intentional (e.g. performance implications)

Non Functional Requirements

• Maintain security, reliability, performance, maintainability, scalability, usability and end user documentation standards.
• Specifically, if the full scope of requirements presents a performance challenge then we can discuss alternatives and negotiate hard requirements.  

Success Criteria or KPIs measured (Optional):

A list of specific, measurable criteria that will be used to determine if the feature is successful. Include key performance indicators (KPIs) or other metrics., etc. Initial completion during Refinement status.

<enter success criteria and/or KPIs here>

Use Cases (Optional):

Include use case diagrams, main success scenarios, alternative flow scenarios together with user type/persona. Initial completion during Refinement status.

<your text here>

Out of Scope (Optional):

High-level list of items that are out of scope. Initial completion during Refinement status.

<your text here>