Security posture

Security posture

Sextant checks your workloads against the Pod Security Standards — the Baseline and Restricted policies that Kubernetes' built-in Pod Security Admission enforces — and tells you, field by field, what fails and how to fix it. Where Trivy Operator is installed, its image vulnerability and configuration audit reports are shown next to the workloads. Nothing is changed in the cluster.

Contents: The Security page · Findings · Namespace labels · Added at admission · Details of a workload · Trivy Operator · Security findings on the Problems page · Limits

The Security page

1. Open Cluster → Security.
2. Choose one or more namespaces in the namespace filter. With All namespaces the page asks you to choose: it watches the workloads of the chosen namespaces (at most the first 20) while it is open.
3. Each workload — Deployment, Stateful Set, Daemon Set, Job, Cron Job, and Pods or Replica Sets that no workload owns — is judged by its pod template and shown as Meets Restricted, Meets Baseline or Violates Baseline, with its counts. Expand a row to see its findings.

Show narrows the list to Baseline violations, Restricted violations or Hardening hints; Image vulnerabilities (with Trivy) to workloads with Critical, High and above, and so on.

Findings

A finding names the check (for example Privileged container, Host namespace, Privilege escalation not disabled, Runs as root (UID 0), No seccomp profile set), the container, the exact field (spec.template.spec.containers[0].securityContext.privileged) and the value found. Copy the fix copies a suggested change as YAML: a strategic merge patch in which containers and volumes are matched by name, to put into your manifests, Helm values or GitOps repository, or to paste into the editor (where Safe apply can preview it).

Sextant reads the standards the way Pod Security Admission does (Kubernetes v1.37): init and ephemeral containers count, pod-level settings apply where a container leaves them unset, Windows pods and pods with user namespaces (hostUsers: false) get the exemptions the standard gives them, and a namespace pinned to an older version with pod-security.kubernetes.io/<mode>-version is judged by that version.

Hardening hints are good practice that is not part of the standards: a writable root filesystem, missing requests or limits, an image without a pinned version, a mounted service account token. They are listed separately and never count as violations.

Namespace labels

Above each namespace's workloads, Sextant reads its pod-security.kubernetes.io/enforce, audit and warn labels and says what each would do with the workloads there: how many would be rejected (enforce), recorded in the audit log (audit) or would get a warning (warn). Use it before you add or tighten a label. A namespace without labels follows the cluster's default level, which the API does not show.

Added at admission

Pod Security Admission judges the Pods, after admission webhooks changed them, not your templates. Sextant also reads the live Pods of the workloads in view: a violation a Pod has but its template does not (for example a service-mesh init container injected with NET_ADMIN) is shown on the workload, marked Added at admission, without a fix — fix it where it is added (the webhook or policy).

Details of a workload

Deployments, Stateful Sets, Daemon Sets, Replica Sets, Jobs, Cron Jobs and Pods have a Security section in their details with the same findings and fixes. A Pod owned by a workload says that the template to fix is in its owner. With Trivy Operator installed, the section also has Image scans (Trivy).

Trivy Operator

When Trivy Operator is installed, a Trivy section lists its reports: Vulnerability Reports, Config Audit Reports, Exposed Secret Reports, RBAC and Infra Assessment Reports, Cluster Compliance Reports, SBOM Reports and their cluster-wide kinds. A workload's Image scans (Trivy) shows the counts by severity for each container image, how many vulnerabilities have a fixed version, and the most severe ones (up to 10 in details, 50 in a report), plus the configuration audit.

Sextant reads these reports: it does not install Trivy, start scans or contact any vulnerability database, and the reports are as fresh as the operator keeps them. The report kinds have only the generic Edit and Delete (the operator writes them and scans again).

Security findings on the Problems page

Baseline violations can also appear on the Problems page, in the Cluster counter and as desktop notifications, under the category Security. This category is off by default: turn it on with Security findings on the Problems page or under Notify about in Settings → General → Notifications (one setting for both). While it is off, Sextant watches nothing for it. Trivy reports never become problems.

Limits

• Only the Pod Security Standards are evaluated; policies of Kyverno, Gatekeeper or other admission controllers are not.
• The page reads workloads of at most 20 namespaces at once and lists at most 500 workloads.
• Security posture is not available to AI agents or extensions.

Next: Problems and notifications, Using Sextant.