Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OCP4: Add rule to check ACS sensor deployed #11675

Merged
merged 1 commit into from
Apr 5, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
59 changes: 59 additions & 0 deletions applications/openshift/general/acs_sensor_exists/rule.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,59 @@

title: Ensure that Advanced Cluster Security (ACS) Sensor is deployed

description: |-
Red Hat Advanced Cluster Security (ACS) for Kubernetes provides comprehensive security
for containerized environments. It offers deep visibility into deployed resources
across Kubernetes clusters, enabling teams to detect vulnerabilities in all images,
manage compliance, and enforce security policies. By integrating ACS into the Kubernetes
environment, organizations can automate security checks and configurations, ensuring that every
deployed application is scanned and secured according to best practices and organizational policies.

Sensor is the service responsible for analyzing and monitoring the cluster. Sensor
listens to the OpenShift Container Platform or Kubernetes API and Collector events
to report the current state of the cluster. Sensor also triggers deploy-time and
runtime violations based on RHACS Cloud Service policies. In addition, Sensor is
responsible for all cluster interactions, such as applying network policies,
initiating reprocessing of RHACS Cloud Service policies, and interacting with
the Admission controller.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One minor note is that we can probably add a link to either stackrox or ACS documentation as a way for reader to find more information.



rationale: |-
ACS provides a method to continuously monitor and protect the Kubernetes environment against vulnerabilities
and misconfigurations. This ensures that the infrastructure and applications are compliant
with security standards and regulations, reducing the risk of security breaches.

identifiers:
cce@ocp4: CCE-86171-6

references:
pcidss: Req-6.3.2,Req-11.3.1.1,Req-11.5.1.1
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll need to incorporate versions here before we release PCI-DSS v4.0.0.


ocil_clause: 'ACS Sensor is not deployed'

{{% set jqfilter = '[ .items[] | select(.metadata.name == "sensor" and .metadata.labels["app.kubernetes.io/name"] == "stackrox") | .status.availableReplicas]' %}}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks reasonable so long as it's safe to rely on sensor as the deployment name and stackrox as the label.

@dashrews78 does this look ok to you?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

on the surface looks OK. There may be another caveat though. Just because sensor is deployed doesn't necessarily mean it is connected to a central. But that may be a more advanced workload type check.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you know where I can check so we know it is being connected to the central?

Copy link

@SimonBaeumer SimonBaeumer Mar 21, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Luis could answer this, I've sent him this conversation.
My gut says it is sufficient to look into the Deployment status. A non-connecting sensor eventually will go to CrashLoopBackoff.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If ROX_PREVENT_SENSOR_RESTART_ON_DISCONNECT is enabled (which it should be by default), sensor should not go to CrashLoopBackoff. The only way to know for sure if sensor is connected with central is by checking logs, metrics, or central's UI.

I'm lacking some context here but I would say knowing if sensor is connected is not necessary because even if sensor is not connected to central, if sensor is deployed, it should flush all the resources to central upon reconnection.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for the input, I wonder if there is a way we can find it out through any of the kube api resources? metrics might not be easily accessed by CO at the moment.


ocil: |-
Run the following command to check if the ACS Sensor is deployed:
<pre>$ oc get Deployment --all-namespaces -o json | jq '{{ jqfilter }}'</pre>
The output should return a non-zero value.


severity: medium

warnings:
- general: |-
{{{ openshift_filtered_cluster_setting({'/apis/apps/v1/deployments?limit=500': jqfilter}) | indent(4) }}}

template:
name: yamlfile_value
vars:
ocp_data: "true"
filepath: |-
{{{ openshift_filtered_path('/apis/apps/v1/deployments?limit=500', jqfilter) }}}
yamlpath: "[:]"
check_existence: "all_exist"
entity_check: "all"
values:
- value: "0"
operation: "not equal"
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
#!/bin/bash
set -xe

echo "Mimicking the behavior of a deployed scanner"
oc apply -f ${ROOT_DIR}/ocp-resources/e2e/acs-sensor-install.yaml --server-side=true

sleep 30

echo "waiting for gitops deployment to exist"
while [ -z "$(oc wait -n stackrox --for=condition=Available --timeout=300s deployment/sensor)" ]; do
sleep 3
done

echo "waiting for gitops deployment to be ready"
oc wait -n stackrox --for=condition=Available --timeout=300s \
deployment/sensor
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
---
default_result: FAIL
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This goes back to @yuumasato's comment, but now that we have a manual remediation, we should be testing that it works in the second scan, right?

result_after_remediation: PASS
rhmdnd marked this conversation as resolved.
Show resolved Hide resolved
12 changes: 9 additions & 3 deletions controls/pcidss_4_ocp4.yml
Original file line number Diff line number Diff line change
Expand Up @@ -1309,10 +1309,12 @@ controls:
it will be required and must be fully considered during a PCI DSS assessment.
levels:
- base
status: pending
status: automated
notes: |-
This requirement is a best practice until 31 March 2025, after which it will be required
and must be fully considered during a PCI DSS assessment.
rules:
- acs_sensor_exists

- id: 6.3.3
title: All system components are protected from known vulnerabilities by installing
Expand Down Expand Up @@ -2714,7 +2716,9 @@ controls:
the entity's vulnerability risk rankings defined at Requirement 6.3.1) are managed
levels:
- base
status: pending
status: automated
rules:
- acs_sensor_exists

- id: 11.3.1.2
title: Internal vulnerability scans are performed via authenticated scanning.
Expand Down Expand Up @@ -2825,10 +2829,12 @@ controls:
must be fully considered during a PCI DSS assessment.
levels:
- base
status: pending
status: automated
notes: |-
The policy is not explicit about any specific solution. The solution might vary
depending on site policies.
rules:
- acs_sensor_exists

- id: 11.5.2
title: A change-detection mechanism (for example, file integrity monitoring tools) is deployed.
Expand Down
36 changes: 36 additions & 0 deletions ocp-resources/e2e/acs-sensor-install.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
---
apiVersion: v1
kind: Namespace
metadata:
name: stackrox
annotations:
openshift.io/node-selector: ""
labels:
openshift.io/cluster-monitoring: "true"
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: sensor
namespace: stackrox
labels:
app: sensor
"app.kubernetes.io/name": stackrox
spec:
replicas: 1
minReadySeconds: 15
selector:
matchLabels:
app: sensor
strategy:
type: Recreate
template:
metadata:
labels:
app: sensor
spec:
containers:
- image: quay.io/fedora/fedora-toolbox
imagePullPolicy: Always
name: sensor
command: ["/bin/sh", "-c", "while true; do echo 'Hello, StackRox!'; sleep 3600; done"]
1 change: 0 additions & 1 deletion shared/references/cce-redhat-avail.txt
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,6 @@ CCE-86167-4
CCE-86168-2
CCE-86169-0
CCE-86170-8
CCE-86171-6
CCE-86174-0
CCE-86178-1
CCE-86179-9
Expand Down
Loading