Baselines and suppression
Four different mechanisms can keep a finding quiet. They are not interchangeable, they behave differently when you remove them, and picking the wrong one is the usual cause of “I silenced this and it came back.”
| Mechanism | Acts | Expires | Removing it reopens findings? |
|---|---|---|---|
| Baseline exclusions | Before scoring | No | n/a: re-evaluated each scan |
| Ignore rules | Before a finding is recorded, and on findings that already exist | No | No (see below) |
| Maintenance windows | At the moment a finding is created | Yes, at the window’s end | Yes, on expiry |
| Manual suppression | On one existing finding | Optional | Yes, on expiry |
Baseline exclusions
Section titled “Baseline exclusions”Your cloud creates resources you never declared. Default VPC security groups,
service-linked roles, AKS node resource groups, GCP’s default-allow-* firewall
rules: none of these are in your Terraform, and all of them are expected.
Cloudkeel-DD ships a catalog of 59 entries covering the common cases:
| Cloud | Entries |
|---|---|
| AWS | 3: service-linked IAM roles, the default VPC security group, the VPC main route table |
| Azure | 6: AKS managed node resource groups (matched case-insensitively, since Resource Graph lowercases the group name), AKS agent-pool network resources, AKS Service load-balancer public IPs, Network Watcher, Backup and Databricks managed resource groups |
| GCP | 6: default-network firewall rules, subnetworks and routes, and three classes of Google-managed service agent |
| Kubernetes | 44: kubectl rollout restart, ingress-controller Services (ingress-nginx, Traefik, Istio), the default kubernetes Service, the kube-root-ca ConfigMap, provider-managed namespaces, the default ServiceAccount in every namespace, and 36 entries for cluster-scoped system RBAC (system:* and the built-in cluster-admin/admin/edit/view roles, the ClusterRoles and ClusterRoleBindings AKS installs for its CSI drivers, cloud-node-manager, metrics-server and monitoring agents, and the EKS and GKE equivalents) |
A matched finding is still recorded (it is not hidden) but it is forced not-serious, so it never alerts. You can disable any catalog entry for your own workspace if you would rather see it. Each entry has a stable key, so disabling one system-RBAC pattern leaves the others in place.
Why the cluster-scoped RBAC entries exist. A managed Kubernetes cluster
carries well over a hundred ClusterRoles and ClusterRoleBindings that the
provider and Kubernetes itself create. Without these entries a first scan of a
fresh AKS cluster reported about 165 of them as unmanaged. A ClusterRole with a
name that matches none of the provider patterns, such as payments-reader, is
still reported, which is the point.
Two notes on the Azure entries. The AKS node resource group entry matches
MC_* without regard to case, because Azure resource-group names are
case-insensitive and Resource Graph returns them lowercased; an earlier
case-sensitive version of this entry never matched a real row. The EKS and GKE
RBAC patterns follow those providers’ documented naming and have not yet been
verified against a live cluster; the AKS ones have.
Still thin for a large estate. GKE in particular generates undeclared
resources (node VMs, gke-* firewall rules) that the catalog does not yet
cover. Expect noise on your first GCP scan and tell us which patterns to add.
Ignore rules
Section titled “Ignore rules”An ignore rule stops a finding being recorded at all. A rule matches on any combination of resource type, namespace, and a name pattern.
- The name pattern is a glob, not SQL;
?and character classes work as they do in a shell. - A rule with no criteria at all matches nothing, not everything. Creating one is rejected, and any that already exist are treated as inert.
Creating a rule also sweeps findings that already exist and matches them. That sweep runs as a background job, not inside the request that saved the rule, so a broad rule that matches hundreds of findings cannot time out halfway through.
Deleting an ignore rule does not reopen what it silenced
Section titled “Deleting an ignore rule does not reopen what it silenced”This is deliberate, and it is the single behaviour most likely to surprise you.
Nothing in the scan path reopens a suppressed finding. Findings silenced by an ignore rule are suppressed with no expiry, because the reason they are quiet is the rule, and the rule does not expire: handing them to the expiry sweep would reopen them, and the very next scan would silence them again.
So delete in the right order:
- Disable the rule.
- Unsuppress its findings: there is a bulk unsuppress-by-rule action for exactly this.
- Then delete the rule.
Delete first and the link between rule and findings is severed. The findings stay suppressed with nothing left to explain why.
→ Undoing an over-broad rule has the commands and the expected output.
Recovering findings that were already stranded
Section titled “Recovering findings that were already stranded”If that already happened, there is a repair. Cloudkeel-DD can identify findings that are suppressed, have no owning rule, no owning window, no human who suppressed them, and no expiry (a state nothing else produces) and reopen them.
It is manual on purpose. You are shown the count and a sample before anything changes, and the repair reopens findings without re-arming notifications: these may have been silent for months, and a bookkeeping fix should not page anyone. The next scan re-evaluates them and alerts honestly if they are still real.
→ Recovering findings stranded by a deleted rule walks the count-then-recover flow.
Maintenance windows
Section titled “Maintenance windows”A window auto-suppresses findings raised during a planned change, matched on the same resource-type / namespace / name-pattern criteria as ignore rules.
A window only applies at the moment a finding is created. It never suppresses a finding that already existed when the window opened, and it never re-suppresses one that reopened during the window. That second rule is what stops the next scan from silently overriding a human who explicitly un-suppressed something mid-window.
Suppressions created by a window carry the window’s own end time as their expiry, so they reopen on their own when it closes. If two active windows both match a resource, the one ending latest wins.
Window times are evaluated in UTC.
→ Schedule a maintenance window has the steps, and Ending a window early covers closing one ahead of time.
Manual suppression
Section titled “Manual suppression”Suppressing one finding by hand requires a non-empty reason and takes an optional expiry. After expiry, the finding reopens and its notification is re-armed; allow up to 15 minutes for this to appear.
Which one should I use?
Section titled “Which one should I use?”| Situation | Reach for | How to do it |
|---|---|---|
| The cloud made it and always will | Baseline exclusion | Disable or enable catalog entries on the Policies page |
| A whole class of resource is noise forever | Ignore rule | Silence a class of resource |
| Expected churn during a planned change | Maintenance window | Schedule a window |
| This one finding, for now, with a reason | Manual suppression | Suppress it from the finding’s drawer |
- The drift lifecycle: scoring, attribution, and the seven states
- Why Cloudkeel-DD scores drift instead of just reporting it: the reasoning behind all of this
- Route findings to the right team: quieting is only half the problem