ACS custom policies implementation

[p-rog]

Intention of this update is to introduce a custom ACS security policy that fits well to the Layered Zero Trust Pattern model.

Example use case:

• suspicious command execution in the pod (like curl)
• ACS Runtime detection
• pod where the suspicious process is detected is terminated automatically with correct policy violation alert

[p-rog]

Current state:
Total Policies: 88
RUNTIME Policies: 36
RUNTIME Policies with Enforcement: 1

Test: KILL_POD_ENFORCEMENT

enforcementActions:
  - "KILL_POD_ENFORCEMENT"

Result: ✅ SUCCESS
Test Results:

• ✅ Violation detected when executing curl --version
• ✅ Pod terminated via KILL_POD_ENFORCEMENT
• ✅ Violation logged in ACS Console
• ⚠️ Deployment controller creates new pod (maintains replica count)

[p-rog]

Update:
Total Policies: 91
Custom RUNTIME Policies: 2

• Stop Suspicious Exec (with enforcement enabled by default)
• Prevent Runtime Privilege Escalation (with enforcement enabled by default)

Custom DEPLOYMENT Policies: 2

• Deployments should have at least one egress Network Policy - AS Code
• Deployments should have at least one ingress Network Policy - AS Code

I'm working on signing verification custom policy to complete our current zero trust use cases.

[sabre1041]

Seeing differences in Argo CD

In addition, the use of the policies directory within the acs-central chart is a bit of an antipattern. Instead, lets move the newly created chart up to the top level charts directory

[p-rog]

Seeing differences in Argo CD

The custom policies metadata visible in Argo CD are taken from the yaml files and some optional fields are automatically added by ACS. For example:

disabled variable value defines is the policy is enabled or disabled, which we set in our values.yaml file.
The isDefault: false, mitreVectorsLocked: false and criteriaLocked: false are optional metadata I added to the network policies because I copied it from exported default ACS policy. The meaning of these values is following:

isDefault: A boolean (true or false). If true, this is a system policy provided out-of-the-box by Red Hat. Default policies cannot be deleted (though they can be disabled). If false, it is a custom policy created by your team.

criteriaLocked: A boolean. If true, the actual rules/conditions (the policySections) of this policy are locked and cannot be edited. Red Hat locks the criteria on certain default policies to ensure their core logic remains intact during upgrades.
mitreVectorsLocked: A boolean. If true, the mapping of this policy to the MITRE ATT&CK framework cannot be changed.

I will remove these values for consistency.

The negate value is added automatically by ACS for Runtime policies and if set to true it acts as a "NOT" operator (condition is NOT like the set value).

In addition, the use of the policies directory within the acs-central chart is a bit of an antipattern. Instead, lets move the newly created chart up to the top level charts directory

I thought that keeping ACS policies inside the ACS Central chart is a good thing, to highlight that these things belongs to ACS. WDYT?

[sabre1041]

Seeing differences in Argo CD

The custom policies metadata visible in Argo CD are taken from the yaml files and some optional fields are automatically added by ACS. For example:

disabled variable value defines is the policy is enabled or disabled, which we set in our values.yaml file. The isDefault: false, mitreVectorsLocked: false and criteriaLocked: false are optional metadata I added to the network policies because I copied it from exported default ACS policy. The meaning of these values is following:

isDefault: A boolean (true or false). If true, this is a system policy provided out-of-the-box by Red Hat. Default policies cannot be deleted (though they can be disabled). If false, it is a custom policy created by your team.

criteriaLocked: A boolean. If true, the actual rules/conditions (the policySections) of this policy are locked and cannot be edited. Red Hat locks the criteria on certain default policies to ensure their core logic remains intact during upgrades. mitreVectorsLocked: A boolean. If true, the mapping of this policy to the MITRE ATT&CK framework cannot be changed.

I will remove these values for consistency.

The negate value is added automatically by ACS for Runtime policies and if set to true it acts as a "NOT" operator (condition is NOT like the set value).

In addition, the use of the policies directory within the acs-central chart is a bit of an antipattern. Instead, lets move the newly created chart up to the top level charts directory

I thought that keeping ACS policies inside the ACS Central chart is a good thing, to highlight that these things belongs to ACS. WDYT?

For the fields that are either "defaulted" by the CRD in OpenShift or added by the ACS Operator, lets go ahead and define them so that our application remains in sync from an Argo perspective.

For how the charts are organized, I would disagree that even though there is a goal to associate charts by embedding them within another chart, from a distribution and lifecycle perspective, it is recommended that they be kept separately. The only other option that would align is to embed the chart within the charts directory of the acs-central chart. However, I do not recommend that approach as it couples the lifecycle of the two charts together. Keeping them separately provides the most options possible for chart developers and consumers

[p-rog]

For the fields that are either "defaulted" by the CRD in OpenShift or added by the ACS Operator, lets go ahead and define them so that our application remains in sync from an Argo perspective.

I've addressed that already.

For how the charts are organized, I would disagree that even though there is a goal to associate charts by embedding them within another chart, from a distribution and lifecycle perspective, it is recommended that they be kept separately. The only other option that would align is to embed the chart within the charts directory of the acs-central chart. However, I do not recommend that approach as it couples the lifecycle of the two charts together. Keeping them separately provides the most options possible for chart developers and consumers

OK, fair point :)
I will move ACS policies charts to the top level charts directory.

[p-rog]

@sabre1041 done, I moved acs policies charts to the top level charts directory.

Additionally, like we discussed today during the Program Call, I modified the two custom network policies, and instead of excluding some selected namespaces, I reduced the scope only to the qtodo namespace. Just to show alerts on missing ingress/egress Network Policies specifically for the qtodo ZTVP application only for now. Once we address this (next step) we can add "default" namespace to the scope and use that as a test use case.

Please check it now.