-
Notifications
You must be signed in to change notification settings - Fork 696
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
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. | ||
|
||
|
||
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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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]' %}} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Looks reasonable so long as it's safe to rely on @dashrews78 does this look ok to you? There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Luis could answer this, I've sent him this conversation. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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
|
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"] |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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 | ||
|
There was a problem hiding this comment.
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.