ankra security
Read the organisation’s Security Center - the same data the portal shows, for your own reporting and automation. Every finding carries its exploitation intelligence: whether CISA lists the CVE in its Known Exploited Vulnerabilities (KEV) catalog, with CISA’s remediation deadline and required action, and the FIRST EPSS probability that it is exploited in the next 30 days. Findings sort by exploitability by default - CISA listing first, then EPSS, then severity - so the top of the list is what is actually being exploited, not what merely has the highest CVSS score. Pass -o json (or yaml) for the full API document.ankra security access
Evaluate one cluster’s kube gateway grants and print every failed check, most severe first: a grant whose identity the cluster verified can impersonate, a standing cluster-wide admin or cluster-admin grant, a grant the organisation’s access policy would refuse today, and the creator’s grant left unchanged for 90 days on a GitOps cluster. Each finding names the grant, the grantee, its role and scope, and the commands that fix it. Checks that could not be evaluated are listed after the findings, so a short list is never read as a clean one. A grant absent from both lists passed every check. Grantee emails appear only when you hold kube_access.manage; otherwise the grantee is shown by its Ankra user id. If the platform leaves the summary (or one of its always-sent counts), the findings or the unknowns out of its answer, that part reads “not reported”, whatever was reported is still printed, and the command exits 1: an incomplete answer is never a pass. -o json prints the document as sent, nulls included, and exits 0. The same summary line is the Access column of ‘ankra security clusters’.ankra security addon
One add-on’s security posture on a cluster: the findings attributed to its imagesankra security advisory
Show the platform’s advisory for one CVE: the parsed NVD/OSV record, CISA’s guidance and your exposureankra security benchmarks
Read one cluster’s benchmark compliance through its agent: each ClusterComplianceReport (CIS, NSA/CISA, …) with pass and fail totals and the failing controls, plus the config-audit rollup by namespace and check. A cluster whose agent is offline answers with the reason and a retry hint rather than an empty report. Drill into one failing control with ‘ankra security benchmarks resources’.ankra security benchmarks resources
List the Kubernetes objects failing one control on a cluster and, when the platform could match them, the stack and resource that owns each.--check
is the control id from ‘ankra security benchmarks’; --source is benchmark
(pass --benchmark with the spec id) or config_audit.
Example:
ankra security clusters
List every cluster’s security posture: scanner freshness, actionable and known-exploited findings, and the Access line counting its kube gateway grants (live grants, standing grants above view, grants over the organisation’s access policy, and grants whose identity the cluster verified can impersonate). A count the platform could not establish reads “unknown”, never 0: over policy when the access policy could not be read, impersonate until every live grant has a verified probe answer. A platform that predates the access posture reads “not reported”. Open one cluster’s grant findings and their fixes with ‘ankra security access--cluster <cluster>’.
ankra security compliance
Show every cluster’s benchmark compliance (CIS, NSA/CISA and the other specs the scanner evaluates) with pass and fail totals and the config-audit posture. A cluster the scanner does not run on, or whose agent could not be reached, reads not_available with the reason rather than as compliant. Subcommands cover the compliance frameworks (GDPR, ISO 27001, SOC 2, NIST CSF): the catalogue, switching one on or off, its control-by-control report, and the evidence export.ankra security compliance export
Download the organisation’s compliance evidence report: cluster posture, findings, dispositions, the audit summary and the attestation, for a window that defaults to the last 90 days. CSV by default;--format json for the
full document. Needs the security.read and audit.read permissions.
The file goes to the name the platform suggests in the current directory,
to --output-file, or to standard output with --output-file -.
Example:
ankra security compliance frameworks
The compliance framework catalogue with each framework’s switch and live scoreankra security compliance frameworks disable
Disable one framework by its key (see ‘ankra security compliance frameworks’). Needs the security.manage permission; asks for confirmation unless--yes.
ankra security compliance frameworks enable
Enable one framework by its key (see ‘ankra security compliance frameworks’). Needs the security.manage permission; asks for confirmation unless--yes.
ankra security compliance frameworks report
Print a framework’s report: the score, every category with its controls and the automated checks behind each, the recorded monthly trend and the months a snapshot exists for.--month YYYY-MM reads a recorded month; the
default is the live evaluation.
ankra security dispositions
List the organisation’s vulnerability-disposition policies. A disposition acknowledges a finding (it stays visible but leaves the actionable set) or accepts its risk, for every occurrence its selector matches - one CVE and package inside one add-on across the organisation, or pinned to one workload or one image digest when no add-on owns the image. Each policy has a lifecycle status: active, expiring (the review deadline is near), fix_available (a fixed version exists, so the acceptance should be revisited), mitigated (nothing matches any more), unmatched (nothing ever matched), expired or revoked. Examples:ankra security dispositions create
Write a disposition anchored on one occurrence: acknowledged keeps the finding visible but out of the actionable set; accepted_risk records a decision to live with it, which needs the security.manage permission. The preview prints first and the write asks for confirmation;--yes skips
the prompt. Give a --reason: it is what an auditor reads. --expires-at sets
a review deadline; --expire-when-fix-available ends the disposition the
moment a fixed version appears. --allow-unmatched stores a policy whose
anchor no longer matches anything.
--scope chooses what the policy is pinned to: organisation_addon (the
default) for the add-on that owns the occurrence, or workload or image when
no add-on owns the image.
Examples:
ankra security dispositions preview
Compute a disposition’s blast radius without writing anything: how many occurrences, findings, clusters and add-ons the selector would cover, what it deliberately excludes (ambiguous or unattributed occurrences, ones with a fix available when the policy expires on fix), the policies it overlaps, and the actionable total before and after. Anchor a new policy on one occurrence with--occurrence (an id from
‘ankra security finding <id>’), or re-preview an existing policy with
--policy.
--scope chooses what the policy is pinned to. organisation_addon (the
default) covers the add-on that owns the occurrence, on every cluster.
workload covers one workload on one cluster and image covers one image
digest wherever it runs; use either when no add-on owns the image, such as
operator-managed pods, plain manifests or control-plane pods.
Examples:
ankra security dispositions revoke
Revoke one policy. Every occurrence it covered returns to the actionable set immediately.--reason is required and is what the audit trail keeps.
Needs the security.manage permission; asks for confirmation unless --yes.
ankra security dispositions update
Edit one policy’s reason, review deadline (--expires-at) or fix trigger
(--expire-when-fix-available). Members left unset stay as they are. Needs
the security.manage permission; the write asks for confirmation unless
--yes is passed.
ankra security enable-baseline
Install the platform’s security baseline on one cluster: Trivy Operator for vulnerability, SBOM and compliance reports, plus the pod-security policy add-ons in audit mode. The stack is committed to the cluster’s GitOps repository and rolled out by the platform; findings appear once the first scan completes. Asks for confirmation unless--yes.
ankra security finding
Show one finding: its CISA KEV listing and deadline, EPSS probability, occurrence counts by disposition, and every active occurrence. The detail lists active occurrences only. Pass--status resolved to see
where the finding was fixed, --cluster to narrow to one cluster, and
--page/--page-size to walk a large set; any of these switches the table to
the paged occurrence listing.
ankra security findings
List the organisation’s logical findings (one row per CVE and package, deduplicated across clusters and workloads). By default the list is the actionable set (open and acknowledged findings) sorted by exploitability. Narrow it with--known-exploited to the CVEs CISA
lists as exploited in the wild, or with --severity, --status, --fixable,
--cluster, --addon and --namespace.
Examples:
ankra security history
List a cluster’s daily security snapshots for the last--days days (default
90, the platform clamps to 1..365): findings by severity, what is actionable
once dispositions are applied, the workloads and namespaces covered and the
risk score, oldest first, with a one-line trend between the first and last
snapshot. A day the scanner recorded no snapshot for is simply absent - it
never reads as zero findings.
ankra security namespaces
Break the fleet’s findings down the way a platform team owns it: cluster, then namespace. Each row carries the scanned workloads and images in the namespace, the pods the cluster runs there right now, the actionable findings by severity and the known-exploited count. Cluster-scoped reports (node and control-plane images) keep a row of their own so the rows still add up to the cluster. Drill further with ‘ankra security pods--cluster <cluster> --namespace <ns>’.
ankra security network-exposure
Score one cluster’s NetworkPolicies per direction, 0-100 with higher being tighter: the share of admitting rules that admit a broader peer set than a named identity, and the workloads no policy protects at all. A cluster with no workloads has nothing to score and reads n/a, not 100.ankra security overview
Fleet security summary: totals, CISA KEV exposure, scanner coverage and remediation candidatesankra security pod
Show one running pod with the findings of the scanned workload container behind each of its containers, the CISA KEV exposure, and whether each container’s image has a bill of materials. A container the scanner has no report for is marked “not scanned”, which is not the same as clean. Open the image behind a container with ‘ankra security sbom image <digest>’ and its CVEs with ‘ankra security sbom findings <digest>’.ankra security pods
List the pods a namespace runs right now with the findings of the scanned workload container behind each of their containers. The owner chain is resolved one level up (Pod -> ReplicaSet -> Deployment, Pod -> Job -> CronJob), so narrow to one workload with--workload-uid or --workload-kind/--workload-name.
A container the scanner has no report for is marked “not scanned”, which is
not the same as clean.
ankra security policy-mode
Set the cluster’s pod-security policy mode. audit records violations without blocking; enforce rejects non-compliant workloads at admission; off uninstalls the Kyverno policy engine from the cluster (its admission webhook and reports controller are what load a small control plane) while native pod security keeps observing in audit - audit or enforce afterwards do not reinstall it. Every mode asks for confirmation;--yes skips the
prompt. The change is committed to the cluster’s GitOps repository and
rolled out by the platform.
ankra security report-schedule
Show one cluster’s scheduled security report - weekly or monthly, who receives it, whether it is enabled, and when it was last sent and is next due. A cluster without a schedule reads “not configured”. Use “report-schedule set” to create or change it and “report-schedule send” to queue one now.ankra security report-schedule send
Queue the cluster’s security report for immediate delivery to the schedule’s recipients. Asks for confirmation unless--yes.
ankra security report-schedule set
Create or replace the cluster’s scheduled security report.--frequency is
weekly or monthly; --recipient is repeatable, at most 20 addresses, and at
least one is required while the schedule is enabled. --disabled keeps the
schedule but pauses sending. Asks for confirmation unless --yes.
ankra security sbom
List every package the scanner found in the fleet’s container images, grouped by name, version and ecosystem, with how many images, workloads and clusters carry it and the findings that name that exact package and version. Search a package to answer “where do we run this” without a rescan. The bill of materials is opt-in per cluster: set the security baseline input trivy_sbom_generation_enabled to true on a cluster with control-plane headroom. The coverage line says how many scanned clusters publish one. Subcommands list the images (‘ankra security sbom images’) and open one image’s full component list (‘ankra security sbom image <digest or reference>’).ankra security sbom component
Follow one exact package - the name,--version and --type a security sbom row shows - to the images whose bill of materials names it, every workload container currently running those images, and the clusters they run on.
ankra security sbom containers
List every container the resource cache says is running on the scoped clusters, init containers included, each joined to the bill of materials of the image it runs - or marked ABSENT when the scanner has none for it. An absent bill of materials is a state to act on, not an empty image: the cluster may have SBOM generation switched off, the scanner may not be able to pull from the image’s registry, or the tag rolled since the last scan. Absent rows sort first by default;--status absent lists only them.
The inventory line counts the scope (cluster, namespace, workload) before
--status and --search narrow the rows, so it holds while you drill.
ankra security sbom export
Download one image’s bill of materials, rebuilt from the components the platform stores: a CycloneDX 1.5 JSON document by default (what Dependency-Track, Grype and licence scanners ingest) or a flat CSV with--format csv. Every component is included, unpaged.
The document goes to the file the platform names (repository_tag.cdx.json)
in the current directory, to --output-file, or to standard output with
--output-file -.
Example:
ankra security sbom findings
List every CVE the scanner names on one image: one row per CVE and installed package version, aggregated across the containers running the image, with the fixed version when one exists, the CISA KEV listing and EPSS probability, and the worst disposition across its occurrences. The image is identified the way the inventories list it: a sha256 digest, or the repository:tag reference when the scanner knew no digest. An image without a bill of materials still answers - the CVEs come from the vulnerability reports - and the header says ABSENT so the gap is visible. The summary line totals the image before--search and --severity narrow the
rows. Read one CVE in full with ankra security finding <finding id>.
ankra security sbom image
One image’s bill of materials: its identity, the workloads running it and every componentankra security sbom images
Images with a bill of materials: OS, component count, where they run and their findingsankra security stack
Show one stack the way its Security tab does: attribution scope, the findings attributed to it, the CVEs CISA lists as exploited, the bill of materials of its containers, and every member (add-on or manifest) with the posture of the workloads it resolved to. Below the members come the Kubernetes workloads each member deploys, with their pods, scan state, severe actionable findings and SBOM coverage, so the path from an Ankra resource to a pod is one read. Open a pod with ‘ankra security pod <namespace> <pod-name>’.ankra security stacks
List every stack on a cluster with the posture its own Security tab shows: attribution status, scope, actionable and known-exploited findings and the bill-of-materials coverage of its containers, riskiest first, plus a closing “outside any stack” row for everything no stack owns, so the rows add up to the cluster. A stack whose members matched no workload is reported unmatched, which is not the same as clean. Open one stack with ‘ankra security stack <name>’.ankra security violations
Read one cluster’s pod-security policy results: the stored policy mode (audit or enforce; none when the policy add-on is not installed), the pass/fail/warn totals and each policy with its worst namespaces, plus the platform’s own evaluation of the cluster’s workloads from the resource cache, which is present whether or not the policy engine runs.ankra security workloads
List the fleet’s scanned workload containers, riskiest first. Each row carries the observed and actionable severity counts, what is acknowledged or accepted, the fixable severe count and how many of its CVEs CISA lists as exploited. The filters are the findings list’s.--sort defaults to risk_score.
Examples: