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 (As a NS owner /tenant , how do I manage  policies on my namesapce)
    • namespace focused. How is it related to ROX-29033
  • Alignment with the updated (K8s based) RBAC model 
  • Drift Prevention option and system policies
    • More customers require drift prevention
    • This includes blocking/eliminating local policies as well as OOTB system policies
    • Red Hat owned system policies are still required because Red Hat approves the exceptions, however we need to allow users to apply them using gitops on their own
    • The RH policies are sensitive so they need to be signed. It was suggested previously to ship the policies as an image. We need to figure this out
• Violation Management
  • Violations management, violation discovery by ACM
  • Risk acceptance (exception management)
  •  Multi Tenancy for violation management (As a NS owner, how do I see violations for my NS ?) 
  • RBAC
• Multi Tenancy additional issues
  • While we want to support NS admins, which calls for NS scoped policies, there is also a cluster admin in that scenario
  • In a MT scenario, the cluster admin needs to mandate certain policies
  • In a non MT scenario, there may not be a need for NS scoped policies
  • Cluster Scoped policies still need include/exclude clauses and associate notifiers
    • Are NS scoped and Cluster scoped policies identical, other than the scope  ?
  • Q: as a MT provider, do I ever want to see the policies that my tenants choose to add to their namespaces?
  • A: Probably not ! 
  • Q: What about compliance ? Am I (provider) responsible for compliance for my tenants ?!
  • A: Only as far as the cluster is compliant. The tenants cannot soften the security posture, they can only harden it.  
• 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>