Cluster Security

Fleet-wide Trivy vulnerability and compliance posture, actionable cluster checks, organisation policies, NetworkPolicy exposure scoring, and per-add-on security views.

Ankra turns Trivy Operator vulnerability and compliance reports into a prioritised security workflow across your organisation. The platform reads the operator’s Kubernetes reports through the agent. No scanner runs on Ankra’s side and no image data leaves your cluster.

Security is a read and policy layer over Trivy Operator image CVEs, benchmark compliance, and configuration audits. You install and configure the operator like any other add-on. Ankra surfaces, ranks, explains, and helps remediate what it finds.

---

Where to work

Surface	Purpose
Organisation → Security	Fleet overview, findings, cluster coverage, compliance, and organisation-wide policies
Cluster → Security	Scoped overview, findings, workloads, and actionable compliance checks for one cluster
Stack add-on → Overview	Compact security posture for one add-on, with a deep link into cluster Security

The dashboard Fleet Security widget summarises actionable severe risk and links into the organisation Security Center.

---

Prerequisites

Trivy Operator must be running in each cluster you want to assess. If it is not installed, the Security views explain the setup state and link to Settings → Integrations → Trivy Operator.

1. Add the Trivy Operator add-on

   From Settings → Integrations → Trivy Operator, or the Stack Builder, add the trivy-operator Helm add-on and deploy it. It scans workloads and writes vulnerability, compliance, and configuration-audit reports.

2. Wait for the first reports

   The operator scans images shortly after install. Until reports exist, the integration shows installed_no_reports.

3. Open Security

   Use the organisation Security entry for fleet triage, or a cluster’s Security sidebar entry for a scoped view.

---

Connection and scanner states

State	Meaning
not_installed	Trivy Operator CRDs are not present — install the add-on
installed_no_reports	The operator is installed but has not produced reports yet
connected / fresh	Live or recently materialised reports are available
degraded / stale	The live read failed or data is older than the freshness window; cached data may still be shown
unscanned	The cluster has no usable security snapshot yet

---

Observed vs actionable risk

Every finding is tracked with two complementary views:

• Observed — everything Trivy currently reports, including accepted risk.
• Actionable — findings that still need attention: open and acknowledged. Accepted risk is excluded from actionable totals, remediation queues, and threshold alerts, but remains visible.

Primary KPIs, fleet posture, alerts, scheduled reports, and AI summaries use actionable counts. Observed and accepted-risk totals stay available for context.

---

Organisation Security Center

The organisation Security Center has six sections:

Overview

Emphasises what to fix first. A fleet scorecard leads the page: a posture ring showing the share of scanned clusters with no actionable critical or high findings, a plain-language verdict, and tiles for actionable critical, actionable high, fixable severe, and scanner coverage. Below it sit the fleet trend, ranked remediation opportunities, and policies nearing review.

The fleet posture trend is built from daily snapshots, so you can see whether actionable risk is rising or falling over time rather than only its current level. The same trend feeds scheduled security reports.

Fix top findings with AI hands the highest-ranked remediation candidates to Ankra AI with fleet context attached and asks for a prioritised plan. See Ask Ankra AI.

Findings

Server-paginated inventory of logical findings, deduplicated across clusters and workloads. Status filter chips carry live counts: Actionable (open and acknowledged, the default view), Open, Acknowledged, Accepted risk, and Resolved. Filter further by severity, fixability, cluster, add-on, and namespace. The detail sheet lists occurrences and matching policies, and carries the disposition actions plus Ask Ankra AI.

Clusters

Per-cluster actionable posture, observed/accepted context, scanner freshness, and a deep link into that cluster’s Security view.

Policies

Organisation-wide disposition rules: active, expiring, fix-available, mitigated, unmatched, expired, and revoked. Edit, renew, or soft-revoke with a fresh server-side match preview.

Network Exposure

How tightly a cluster’s NetworkPolicies are scoped, in and out. Identity - not port or CIDR - is what excludes an attacker, so a workload with no policy, or an allow-rule broader than a named workload identity, counts as over-privileged.

Ingress and egress are scored separately, each from 0 to 100, and each blends two halves:

Half	Question
Coverage	How many workloads are selected by any policy in that direction?
Tightness	Of the rules that admit traffic, how many are scoped to a named workload identity?

A rule counts as broad unless every peer is identity-scoped. An ipBlock on ingress, a namespaceSelector, an empty selector, or a missing from / to all make a rule broad.

Findings list every unprotected workload and every broad rule, ranked by severity with ingress before egress. Filter by flow, namespace, or severity. An unprotected workload is high severity on ingress and medium on egress, because egress default-deny is uncommon enough that its absence is exposure to review rather than an active misconfiguration.

This score reads your policy objects, never your traffic. It cannot tell you whether a policy is safe to apply, and three limits follow from that:

• Enforcement is not verified. The score reflects how the policies are written, not whether your CNI enforces NetworkPolicy at all.
• A fully locked-down cluster and a broken one score identically. A default-deny in every namespace with no allow-rules scores 100 out of 100 while blocking every flow in the cluster. Treat a high score as “policy is written tightly”, not “the cluster is healthy”.
• Coverage is partial. Only Deployments, StatefulSets, and DaemonSets are inventoried, and ports are not scored.

Use it to find workloads nobody has scoped yet. Do not use it to decide a policy change is safe - that needs observed traffic, which this metric does not have.

Compliance

Fleet-wide benchmark scores for CIS Kubernetes, NSA/CISA hardening, and Pod Security Standards, alongside configuration-audit findings and report coverage. Filter for clusters that need attention, compare frameworks, and select a cluster to open its full Security workspace on the Compliance tab.

---

Cluster Security view

Each cluster Security page shares the same domain model, scoped to that cluster:

• Quiet scanner/freshness status with refresh and secondary actions (schedule a report, create an alert).
• Overview — actionable summary, ranked remediation list, trend, and collapsed breakdowns.
• Findings — server-side list and detail sheet with acknowledge / accept-risk flows.
• Workloads — risk explorer with namespace and add-on filters.
• Network Exposure - the same NetworkPolicy scoping scores and findings described above, for this cluster alone.
• Compliance: failed and passed benchmark checks, configuration-audit hotspots, scanner remediation, and Fix with AI actions.

Use the Compliance filters to focus by result, severity, framework, check ID, or remediation text. Failed checks show affected results and scanner guidance. Passed checks stay collapsed by benchmark until you need evidence for an audit.

---

Add-on security posture

On a stack add-on’s Overview, a compact Security panel shows:

• Actionable critical/high counts and accepted-risk count
• Affected images and workloads
• Scan freshness and scanner setup states
• Partial-attribution warnings when ownership cannot be proven for every report

Cluster-scoped and ambiguous reports are not attributed to an add-on. The panel’s Open in Security action deep-links into the cluster Security view filtered by that add-on’s slug. A security API failure never blocks the operational add-on overview.

---

Acknowledge vs accept risk

Two distinct dispositions are available for organisation-scoped add-on findings (for example, Grafana across every cluster):

Disposition	Effect
Acknowledged	Reviewed, but still actionable and alertable
Accepted risk	Excluded from actionable totals, remediation queues, and threshold alerts; still visible in observed/accepted totals

Accepted risk requires:

• A reason
• An actor (recorded in audit)
• A review deadline, maximum one year
• Optionally, automatic expiry when a fix becomes available

Matching uses a deterministic selector: organisation + add-on slug + CVE + package type + package name. Creation always shows a server preview of affected findings, clusters, ambiguous exclusions, and the observed→actionable count change. Policies are never hard-deleted; they can be revoked, expire, mitigate when no matches remain, or reopen if findings return.

Expiry or fix availability can make findings actionable again and may fire threshold alerts. It does not emit a false “new CVE discovered” notification — “new” means newly observed in raw scan data and currently actionable.

---

Permissions

Permission	Who can use it (built-in defaults)	Capabilities
security.read	Viewer and above	View Security Center, cluster Security, add-on posture
security.triage	Operator, admin, owner	Acknowledge findings
security.manage	Admin, owner	Accept risk, create/edit/revoke organisation policies

Custom roles may grant these permissions. Backend enforcement is authoritative; the UI only gates controls.

All disposition mutations are audited and write append-only policy events in the same transaction.

---

Ask Ankra AI

The AI assistant can read the same vulnerability and compliance data. Three entry points open chat already grounded in what you are looking at:

Action	Where	What it sends
Fix top findings with AI	Organisation Overview	The top remediation candidates with their severity, package, reach, and fix availability, and a request for a prioritised fleet remediation plan
Ask Ankra AI	Any finding detail sheet	The finding and the cluster the occurrence was seen on
Fix with AI	A failed compliance check	The check, benchmark, severity, affected count, and remediation

The agent can inspect affected Kubernetes resources, propose or apply safe changes, and verify the result. Risky or disruptive changes still require confirmation.

Product analytics for these actions record only that an AI action happened, through a strict allowlist. CVE identifiers, finding titles, prompts, and workload names are never sent.

What are the most critical actionable vulnerabilities in this cluster?
Which single image upgrade fixes the most high-severity CVEs?
Why is CIS check 1.1.1 failing, and can you fix the affected resources?

The assistant distinguishes observed, actionable, acknowledged, and accepted-risk findings. Accepted risk is never treated as “gone.”

---

Related

Add-ons

Install Trivy Operator and other add-ons.

Roles and access

Grant security.read, security.triage, and security.manage.

AI Assistant

Triage vulnerabilities in chat.

AI Insights

Proactive cluster health analysis.