> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ankra.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# 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](https://aquasecurity.github.io/trivy-operator/latest/) 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**.
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.
The operator scans images shortly after install. Until reports exist, the integration shows `installed_no_reports`.
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](/guides/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](#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](/guides/security-reports), 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.
```text theme={null}
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
Install Trivy Operator and other add-ons.
Grant security.read, security.triage, and security.manage.
Triage vulnerabilities in chat.
Proactive cluster health analysis.