Description:

ACS provides a sensor based enforcement for situations when the admission controller was not activated or has timed out. (AC is also not triggered when automation, such as ArgoCD, uses the `system:serviceaccount`.) When AC cannot block things from being deployed, then Sensor scales down the deployment to zero.

(other limitations in admission controller may be relevant , see https://issues.redhat.com/browse/ROX-19466 )

By design, Sensor does this only once. We do not trap update requests to scale the deployment back down again.  

That approach is problematic because the enforcement is incomplete and inconsistent. By way of example, an ArgoCD workflow (or a manual `oc apply` command) would immediately try (and succeed) in growing the replica count and effectively launching the banned deployment.

Indeed, this may be the reason for the original design - to prevent a loop where ACS tries to scale down and ArgoCD (or another tool) competes to scale up.

This has been a topic for customer complaints as can be seen in

case https://access.redhat.com/support/cases/#/case/04006119 

• Triggered by ArgoCD  
• Use case: image signature validation functionality
• Captured by Bug ROX-13493

case https://access.redhat.com/support/cases/#/case/04034565 

• Triggered by ArgoCD
• Use case:
  • Confusion. We expected these deployments to be blocked when reapplied automatically by argocd. This was mostly the case, but a handful of deployments keep being reapplied anyway. Luckily, the deployments are immediately scaled down by stackrox, so the functionality is equivalent (no pods with images with critical CVEs are started). But these deployments, since they were not blocked from being applied, still show up in the violations page in the UI
  • Lack of control: deployers are able to bypass RHACS policies

case https://access.redhat.com/support/cases/#/case/04027900  

• Triggered by:
• Use case:
  • Confusion: I created a security policy in ACS that blocks deployments which is using a image that contains moderate or higher vulnerabilities in a specific namespace, ACS recognize the image and the vulnerabilities but not enforce the deployment, it was expected that the policy scale the deployment to 0 but nothing hapens.

Goal Summary:

We should have consistent and reliable enforcement.

Goals and expected user outcomes:

1. Understanding: We need to understand the reasoning behind the current sensor design. While it seems flawed at first glance let's make sure we are not missing something
2. For MVP, address the workflow for ArgoCD users by providing the right guidelines
3. Solution evaluation
   1. Brainstorm potential technical solutions 
   2. Evaluate feasibility of suggested solutions 
   3. Consider the cost/feasibility versus deprecating this capability altogether

Acceptance Criteria:

1. Problem Statement is clear
2. Updated end user documentation for ArgoCD
3. Knowledge Article for ArgoCD
4. Decision is made to solve or deprecate

Success Criteria or KPIs measured:

1. At least one ArgoCD customer confirms they are happy with the shipped solution. (actively solicit feedback using the case)
2. Zero new cases open against this topic in the period between shipping this improvement, and shipping the next major release.