THIS IS A PLACEHOLDER - TO BE UPDATED FOLLOWING DISCOVERY

===

Goal Summary:

An elevator pitch (value statement) that describes the Feature in a clear, concise way. Complete during New status.

Our goal is to allow Kubernetes users and other software to work with ACS policies in a native Kubernetes mode. 

ACS currently uses a centralized distribution model where policies are placed in the namespace of Central, on the Central cluster. This outdated model creates gaps for  standard Kubernetes tooling and software (like ACM) which expect the policy CRs to be placed in the cluster/namespace that they apply to. Notable negative impacts are:

1. Users cannot use standard K8s/OCP tooling (like `describe` , filter by NS)
2. Users have to tweak their GitOps workflows for ACS policy as code by setting the Cluster scope in the ACS policy
3. Multi Tenancy (based on namespace isolation) is not supported
4. Lack of flexibility for policy management privileges due to misalignment with namespace / cluster RBAC. In other words, since policies are global, if you have policy management privileges then you are exposed to admin level information. So to be consistent, this limits policy management activities to admin roles.  
5. ACS policies are not discovered by ACM, the same way they discover other policies
6. ACSCS customers who have no access to Central Cluster cannot use CR based policy as code

Goals and expected user outcomes:

The observable functionality that the user now has as a result of receiving this feature. Include the anticipated primary user type/persona and which existing features, if any, will be expanded. Complete during New status.

As a secured cluster administrator, I want to manage policies on each cluster that I own by placing cluster scope policy CRs in the secured cluster itself, so that I can manage these policies as code using the same methods I do for other cluster scoped activities with all associated benefits.

As a namespace administrator, I want to manage policies on the namespace that I own by placing NS scoped policies in my namespace on each applicable cluster,  so that I can manage these policies as code using the same methods I do for other namespace scoped activities with all associated benefits.

Acceptance Criteria:

A list of specific needs or objectives that a feature must deliver in order to be considered complete. Be sure to include nonfunctional requirements such as security, reliability, performance, maintainability, scalability, usability, etc. Initial completion during Refinement status.

In the discovery process we should uncover implications and compare between alternatives.

The outcome would ideally be 2-3 options, each with effort estimates and pros/cons so that we can move forward with an implementation plan.

Issues to consider include

• Policy Management
  • Policy discovery by ACM
  • Migration scenarios - can we have both centralized and local policies?
  • Multi tenancy for policy management and violation management
    • namespace focused. How is it related to ROX-29033
  • Alignment with the updated (K8s based) RBAC model 
• Violation Management
  • Violations management, violation discovery by ACM
  • Risk acceptance (exception management)
  • RBAC
• changes to roxctl ?
• Changes to installation , specifically OOTB policies

Success Criteria or KPIs measured:

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>