The module lifecycle stage: General Availability
Viewing resources that failed CIS compliance checks
d8 k get clustercompliancereports.aquasecurity.github.io cis -ojson |
jq '.status.detailReport.results | map(select(.checks | map(.success) | all | not))'Viewing resources that have not passed a specific CIS compliance check
By check id:
check_id="5.7.3"
d8 k get clustercompliancereports.aquasecurity.github.io cis -ojson |
jq --arg check_id "$check_id" '.status.detailReport.results | map(select(.id == $check_id))'By check description:
check_desc="Apply Security Context to Your Pods and Containers"
d8 k get clustercompliancereports.aquasecurity.github.io cis -ojson |
jq --arg check_desc "$check_desc" '.status.detailReport.results | map(select(.description == $check_desc))'Manual rescan of a resource
The module rescans resources every 24 hours according to the following algorithm:
- A
VulnerabilityReportobject is created in the namespace with each scanned resource. - This object contains the annotation
trivy-operator.aquasecurity.github.io/report-ttl, which specifies the report lifetime (the default is24h). - After the lifetime expires, the object is deleted, which triggers a rescan of the resource.
You can force a resource rescan in one of the following ways:
- Overwrite the annotation
trivy-operator.aquasecurity.github.io/report-ttl, specifying a short report lifetime. - Delete the
VulnerabilityReportobject from the namespace where the scanned resource is located.
Example command for overwriting the annotation trivy-operator.aquasecurity.github.io/report-ttl:
d8 k annotate VulnerabilityReport -n <namespace> <reportName> trivy-operator.aquasecurity.github.io/report-ttl=1h --overwriteWho has access to scan results
Access to scan results (including the ability to view resources with results) is granted to users with the following access roles:
d8:manage:networking:vieweror higher;d8:manage:permission:module:operator-trivy:view.
Note: these are roles from the experimental DKP role model.
- To grant access to reports within a specific namespace (
VulnerabilityReport,ConfigAuditReport, etc.), use aRoleBindingwith the use-roled8:use:role:viewer(or higher) in that namespace.- To grant access to cluster-wide reports (
ClusterComplianceReport, etc.), use aClusterRoleBindingwithd8:manage:permission:module:operator-trivy:view(or the broaderd8:manage:security:vieweror higher).
In the current DKP role model (resources AuthorizationRule / ClusterAuthorizationRule), the following access levels are typically used:
- Namespace scope (
AuthorizationRulein a specific namespace):User,PrivilegedUser,Editor,Admin. - Cluster scope (
ClusterAuthorizationRulefor cluster-wide reports and/or system namespaces access):ClusterEditor,ClusterAdmin,SuperAdmin.
You can also grant access directly via standard Kubernetes RBAC (Role/ClusterRole + RoleBinding/ClusterRoleBinding):
How to limit the list of resources scanned in a namespace
The current version does not support limiting the list of scanned resources within a namespace.
The operator scans all resources located in any namespace labeled with security-scanning.deckhouse.io/enabled="".
How to view the scan report for your application
To view the scan results of your application, use the Grafana dashboard Security / Trivy Image Vulnerability Overview.
You can filter the results by the desired namespace and resource.
You can also directly view the resources that contain scan results created for each scanned object.
Details about naming structure and resource location are available in the documentation.
How do CIS checks in DKP relate to kube-bench?
What is kube-bench?
kube-bench is a standalone utility from Aqua Security that checks Kubernetes cluster compliance with CIS Benchmark requirements. It runs shell commands on nodes to analyze configuration.
If you want to run kube-bench checks in a DKP cluster yourself, use the instructions in the deckhouse module FAQ.
How does DKP implement CIS checks?
DKP uses Trivy Operator — an integrated solution that:
- Runs as a Kubernetes operator inside the cluster
- Automatically scans all resources
- Stores results in Custom Resources (ClusterComplianceReport)
- Exports metrics to Prometheus
Identifier mapping
| CIS Section | Description | kube-bench | DKP |
|---|---|---|---|
| 1.x | API Server | [PASS/FAIL] 1.2.1 ... |
AVD-KCV-* |
| 2.x | etcd | [PASS/FAIL] 2.1 ... |
AVD-KCV-* |
| 3.x | Control Plane | Manual | Manual |
| 4.x | Worker Nodes | [PASS/FAIL] 4.2.1 ... |
AVD-KCV-* |
| 5.x | Policies | Partial | AVD-KSV-* (full coverage) |
How to compare results?
Use CIS Control ID (e.g., 1.2.1, 5.2.2) — it’s the same in both tools.
Example: If kube-bench shows [FAIL] 1.2.16 Ensure that the admission control plugin..., find it in DKP:
d8 k get clustercompliancereports.aquasecurity.github.io cis -ojson | \
jq '.status.detailReport.results | map(select(.id == "1.2.16"))'See the CIS checks documentation for details.
Why do some CIS checks always show PASS for system components?
Some checks are disabled for system namespaces (kube-system and d8-*) because system components require elevated privileges.
See the CIS checks documentation for the full list of disabled checks.
Why are checks 5.1.2 and 5.1.3 not shown in the dashboard?
Checks 5.1.2 (Minimize access to secrets) and 5.1.3 (Minimize wildcard use in Roles and ClusterRoles) are excluded from metrics and the dashboard due to a high number of false positives for system components.
The checks are still performed, and results are available in the ClusterComplianceReport resource:
d8 k get clustercompliancereports.aquasecurity.github.io cis -ojson | \
jq '.status.detailReport.results | map(select(.id == "5.1.2" or .id == "5.1.3"))'What CIS Benchmark version is used?
The module implements checks according to CIS Kubernetes Benchmark v1.23 specification.
Component versions (external operator-trivy module, DKP 1.75+):
| Component | Version |
|---|---|
| Trivy | v0.67.2 |
| Trivy Operator | v0.29.0 |
| k8s-node-collector | v0.3.1 |
Note: DKP 1.74 and earlier used a built-in module with Trivy v0.55.2.
How often are CIS checks performed?
CIS Benchmark checks run:
- every 6 hours (cron:
0 */6 * * *); - on operator startup.