Once the agent is installed, everything it evaluates flows into Dashboard → Kubernetes. This page covers each feature and how to act on it.

​
Posture, CIS & NSA benchmarks

Every scan (default every 30 minutes) produces:
  • Misconfiguration findings — unsafe workload defaults, missing security context, PSS gaps — in the unified findings inbox, filterable by severity, namespace, and framework.
  • Framework scores — CIS Kubernetes Benchmark and NSA-CISA controls scored PASS/FAIL, rolled up into a per-framework score per cluster with control-level drill-down.
Each control links to its check catalog page for the risk explanation and remediation steps. After you remediate, the next scan re-evaluates and marks the finding fixed or keeps it persistent.
On managed control planes (EKS/GKE/AKS) some CIS control-plane/kubelet argument controls report NOT_ASSESSED because those flags aren’t readable. On self-hosted clusters (k3s/kubeadm), enable nodeScanner.enabled=true to turn them into real PASS/FAIL. See Install → self-hosted.

​
KIEM — RBAC exposure

KIEM (Kubernetes Identity & Entitlement Management) flattens your RBAC into a risk-scored graph:
  • Every Role / ClusterRole and RoleBinding / ClusterRoleBinding as subject → permission edges.
  • A risk score per edge; high-risk edges (e.g. cluster-admin-equivalent, secret access, exec/impersonate) surface as findings.
  • A service-account inventory — which workloads mount which SA, and flags for excessive or unused permissions.
Use it to answer “who can do what in this cluster” and to prune over-privileged bindings.

​
Admission control

The admission webhook validates every pod against Pod Security Standards, image trust (registry allowlist), and your custom rules. Modes:
ModeBehavior
audit (default)Violations are logged and shown in the dashboard; nothing is blocked.
enforceNon-compliant pods are rejected at creation.
Start in audit, review what would have been blocked, then switch to enforce: 
helm upgrade tigergate oci://registry.tigergate.dev/charts/tigergate \
  --namespace tigergate-system --reuse-values \
  --set admission.mode=enforce --set admission.level=restricted
Admission events (allow/deny, with the matched policy) are batched to the backend and shown in the cluster’s admission activity view. failurePolicy defaults to Ignore, so a webhook outage never blocks your workloads.

​
AI-assisted remediation

Requires remediation.enabled=true (see Install → Common configurations) — off by default, since it’s the one write-capable component in the chart. On a fixable finding (a Pod/Deployment/StatefulSet/DaemonSet-owned misconfiguration with a capturable source spec):
  1. Generate Fix — an AI-generated RFC 6902 JSON Patch + plain-English explanation, scoped to a fixed allowlist of safe fields (never touches the container image, names, or other identity fields).
  2. Preview — the remediator dry-runs the patch against the live cluster object and reports whether it would apply cleanly, without changing anything.
  3. Apply — only enabled after a successful preview, and only re-applies the exact previewed patch (never a freshly regenerated one). Requires confirming the exact resource being patched.
Every finding’s remediation panel also shows its history — every past attempt against that specific workload+check, including failed ones with their error, so you can see what was already tried even after the underlying finding is replaced by a later scan.

​
Custom rules

Author org-defined rules in the dashboard (or API) — declarative, no Rego:
  1. Select what to match: namespaces, workload kinds, labels.
  2. Condition: a fixed set of fields/operators (privileged, run-as-root, host namespaces, mutable image tags, env/label matches, regex).
  3. Action: audit (detection only), warn, or enforce (deny at admission).
Rules are validated backend-side (fixed field/operator set, ReDoS-safe regex) and sync to the cluster automatically — the controller and admission webhook refresh them on a short interval, so a new rule takes effect within seconds. The same rule drives both detection (findings) and enforcement (admission).
Describe it instead of building it. The “Create custom rule” panel has a “Describe the policy — AI will draft it” box: type something like “no privileged containers in payments” or “block containers that run as root” and it drafts the name, severity, selector, and conditions for you. The draft is never saved automatically — it prefills the same form you’d fill in by hand, so you review (and can freely edit) it before hitting Save.
You can also start from one of the built-in policy templates (deny-privileged, block-mutable-tags, require-readiness-probe, etc.) instead of a blank rule — both routes land in the same form.

​
Image vulnerabilities

The controller scans running images by digest for CVEs and produces an SBOM per image, de-duplicated so each unique image is scanned once regardless of how many pods run it. Results show CVE id, severity, fixed version, and the affected packages, with the count of running pods per image so you can prioritize.

​
Configuration drift

Each scan hashes the specs of workloads and network policies. When a spec changes between scans, KSPM emits a drift event (added / changed / removed) with the before/after spec, viewable as a side-by-side diff — useful for catching out-of-band kubectl edit changes and unreviewed rollouts.

​
Fleet & controller health

Dashboard → Kubernetes shows every connected cluster with its posture score, per-framework scores, and controller status (healthy / degraded / offline) based on the last heartbeat. If a cluster never appears: 
# 1. Is the operator running and reporting?
kubectl get deploy -n tigergate-system
kubectl logs -n tigergate-system -l app.kubernetes.io/component=operator

# 2. Is the org API key present?
kubectl get secret -n tigergate-system -o yaml | grep -i apikey

# 3. Can the cluster reach the backend on 443? (NetworkPolicy / egress firewall)
Confirm the clusterName you passed to Helm matches what you’re looking for in the fleet.