Polaris is an open-source Kubernetes configuration validator from Fairwinds. It runs policy checks against your workload specs — catching missing resource limits, privileged containers, deprecated API versions, and dozens of other misconfigurations before they reach production. Polaris operates in two modes: as an Admission Webhook that blocks bad configurations at deployment time, and as a batch Audit job that scans existing resources on demand or on a schedule.
When Polaris fails silently — webhook unavailable, audit jobs not completing, or policy check counts dropping to zero — your configuration quality gates disappear. Workloads that should be rejected get admitted; audit reports that should surface drift stop being generated. This guide covers how to monitor Polaris comprehensively and integrate Vigilmon for external dashboard and webhook availability checks.
Why Polaris Monitoring Matters
Unlike application monitoring, Polaris failures are invisible by design. The webhook is either there or not — there's no user-facing error page:
- Webhook unavailability with
failurePolicy: Ignore— the default — silently admits all workloads, including those that violate your policies - Audit job failures — scheduled audit runs fail silently; your team sees a stale report and assumes the cluster is still clean
- Policy check regression — a Polaris version upgrade changes check behavior; previously passing workloads now fail, or checks that should fail now pass
- Dashboard downtime — the Polaris dashboard, if deployed, goes dark; operators lose visibility into cluster configuration health
Monitoring the Polaris Admission Webhook
Webhook Registration Health
# Verify the webhook is registered
kubectl get validatingwebhookconfigurations | grep polaris
# Describe the webhook to check endpoint URL, CA bundle, and failure policy
kubectl describe validatingwebhookconfiguration polaris
# Check the webhook's current failure policy
kubectl get validatingwebhookconfiguration polaris \
-o jsonpath='{.webhooks[0].failurePolicy}'
A failurePolicy: Fail means a Polaris outage blocks ALL pod creation — critical to know. A failurePolicy: Ignore means an outage silently bypasses all policy checks.
Webhook Pod Readiness
# Check Polaris webhook pods
kubectl get pods -n polaris -l app=polaris
# View webhook pod logs for recent activity
kubectl logs -n polaris -l app=polaris --since=1h | tail -30
# Check for webhook errors in API server events
kubectl get events -n polaris \
--field-selector reason=Failed \
--sort-by='.lastTimestamp' | tail -10
End-to-End Webhook Validation
Test that the webhook is actually intercepting and evaluating workloads:
# Deploy a deliberately non-compliant workload and verify Polaris rejects it
# (only works with failurePolicy: Fail)
cat <<EOF | kubectl apply -f - 2>&1 | grep -E "(created|Error|denied)"
apiVersion: v1
kind: Pod
metadata:
name: polaris-webhook-test
namespace: default
spec:
containers:
- name: test
image: nginx:latest
# Missing resources, security context, etc. — should fail Polaris checks
EOF
# Clean up if it was accidentally admitted
kubectl delete pod polaris-webhook-test --ignore-not-found
Webhook Latency Monitoring
Polaris webhook calls add latency to pod admission. Monitor via API server metrics:
# Webhook call duration (if you have API server metrics)
apiserver_admission_webhook_admission_duration_seconds{name="polaris.fairwinds.com"}
# Webhook rejection rate
apiserver_admission_webhook_rejection_count{name="polaris.fairwinds.com"}
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: polaris-webhook-alerts
namespace: polaris
spec:
groups:
- name: polaris-webhook
rules:
- alert: PolarisWebhookDown
expr: up{job="polaris-webhook"} == 0
for: 5m
labels:
severity: critical
annotations:
summary: "Polaris admission webhook is down"
description: "The Polaris webhook has been unreachable for 5 minutes. Policy enforcement is degraded."
- alert: PolarisWebhookHighLatency
expr: histogram_quantile(0.99, apiserver_admission_webhook_admission_duration_seconds_bucket{name="polaris.fairwinds.com"}) > 5
for: 10m
labels:
severity: warning
annotations:
summary: "Polaris webhook p99 latency exceeds 5 seconds"
description: "Polaris webhook calls are taking too long and may be impacting pod scheduling."
Monitoring Polaris Audit Scans
Audit Job Execution Health
Polaris can run as a standalone audit CronJob that produces a full cluster compliance report. Monitor its execution:
# Check Polaris audit CronJob status
kubectl get cronjob polaris-audit -n polaris
# View recent audit job runs
kubectl get jobs -n polaris -l app=polaris-audit \
--sort-by=.metadata.creationTimestamp | tail -5
# Check the latest audit job output
kubectl logs -n polaris -l app=polaris-audit --since=24h | tail -50
Audit Score Tracking
The Polaris audit produces a score from 0 to 100. Track this score over time to detect configuration drift:
# Run a one-off Polaris audit and extract the score
polaris audit --format=json 2>/dev/null | \
jq '.score'
# Or via the in-cluster API if the dashboard is deployed
curl -sf http://polaris-dashboard.polaris.svc.cluster.local:8080/api/v1/audits/summary | \
jq '.score'
A decreasing score means new misconfigurations have been introduced. Automate score threshold alerting:
apiVersion: batch/v1
kind: CronJob
metadata:
name: polaris-score-check
namespace: polaris
spec:
schedule: "0 */6 * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: checker
image: quay.io/fairwinds/polaris:latest
command:
- /bin/sh
- -c
- |
SCORE=$(polaris audit --format=json 2>/dev/null | jq -r '.score // 0')
echo "Polaris cluster score: $SCORE"
# Alert if score drops below 80
[ "$(echo "$SCORE >= 80" | bc -l)" = "1" ] || {
echo "ALERT: Polaris score ${SCORE} is below threshold 80"
exit 1
}
restartPolicy: Never
Policy Check Failure Tracking
Track which specific checks are failing — not just the aggregate score:
# Run audit and list all failing checks with namespace context
polaris audit --format=json 2>/dev/null | jq -r \
'.Results[] | .Name as $name | .Results.podSpec.ContainerResults[] |
select(.Results | to_entries[] | .value.Success == false) |
"\($name): \(.ContainerName) - \(.Results | to_entries[] | select(.value.Success == false) | .key)"'
# Count failures by check category
polaris audit --format=json 2>/dev/null | jq \
'[.Results[].Results.podSpec.ContainerResults[].Results | to_entries[] |
select(.value.Success == false) | .key] | group_by(.) | map({check: .[0], count: length}) |
sort_by(-.count)'
Audit Report Generation Success
If you export Polaris reports to a file or object storage, verify report generation succeeds:
# Check that recent audit report files exist and are non-empty
ls -lh /reports/polaris-*.json 2>/dev/null | tail -5
# Or check via S3/GCS if you export there
aws s3 ls s3://your-bucket/polaris-reports/ | sort | tail -3
Monitoring the Polaris Dashboard
If you deploy the Polaris dashboard for operators:
# Check dashboard pod status
kubectl get deployment polaris -n polaris
# Verify the dashboard returns HTTP 200
kubectl port-forward -n polaris svc/polaris-dashboard 8080:8080 &
curl -sf -o /dev/null -w "%{http_code}" http://localhost:8080
Dashboard Prometheus Alerts
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: polaris-dashboard-alerts
namespace: polaris
spec:
groups:
- name: polaris-dashboard
rules:
- alert: PolarisDashboardDown
expr: probe_success{job="polaris-dashboard"} == 0
for: 5m
labels:
severity: warning
annotations:
summary: "Polaris dashboard is unavailable"
description: "The Polaris dashboard has been unreachable for 5 minutes."
- alert: PolarisAuditJobFailed
expr: kube_job_status_failed{job_name=~"polaris-audit-.*", namespace="polaris"} > 0
for: 0m
labels:
severity: warning
annotations:
summary: "Polaris audit job failed"
description: "A Polaris scheduled audit did not complete successfully. Check pod logs in the polaris namespace."
- alert: PolarisScoreDegraded
expr: polaris_cluster_score < 75
for: 30m
labels:
severity: warning
annotations:
summary: "Polaris cluster configuration score has dropped below 75"
description: "Cluster configuration quality has degraded. Run 'polaris audit' to identify new violations."
Integrating Vigilmon for K8s Configuration Health Gating
Vigilmon monitors your Polaris infrastructure from outside the cluster — giving you external visibility into both the dashboard uptime and the audit API:
Monitor the Polaris dashboard. If you expose the dashboard via Ingress or LoadBalancer:
- Log in to Vigilmon and go to Monitors → New Monitor.
- Add an HTTP / HTTPS monitor targeting your Polaris dashboard URL:
https://polaris.yourdomain.com. - Set check interval to 1 minute.
- Configure a keyword assertion for
"Polaris"or the page title to confirm the dashboard is serving real content, not just a 200 OK from an upstream proxy. - Add an alert channel (Slack, PagerDuty, email) so your platform team is notified when the dashboard goes dark.
Monitor the Polaris audit API. If you expose the audit summary endpoint externally:
https://polaris.yourdomain.com/api/v1/audits/summary
Add a second Vigilmon monitor with a JSON keyword assertion for "score" — this validates that the audit pipeline is running, not just that the HTTP server is alive.
Configure score regression alerts. For teams that export audit scores to a time-series endpoint:
# Synthetic monitor endpoint that returns Polaris score as JSON
# Deploy this as a simple API in front of your audit pipeline
GET https://polaris-status.yourdomain.com/score
→ {"score": 92, "checks_passed": 847, "checks_failed": 23, "timestamp": "2026-07-01T10:00:00Z"}
Add this URL to Vigilmon with a keyword assertion for "score" and set up a custom webhook alert that fires when the score field drops below your threshold. Your CI/CD pipeline can query this endpoint as a deployment gate.
Key Metrics Summary
| Component | What to Monitor | Alert Threshold |
|-----------|----------------|-----------------|
| Admission webhook | Pod readiness + webhook registration | 0 ready pods for > 5m |
| Webhook latency | p99 admission duration | > 5s for > 10m |
| Audit job | CronJob last success | > 24h without a run |
| Cluster score | polaris_cluster_score | < 75 for > 30m |
| Policy failures | Per-check failure counts | Any new failing check category |
| Dashboard | HTTP 200 on dashboard URL | Any failure for > 5m |
| External audit API | Vigilmon HTTP + JSON keyword | Any failure for > 5m |
Conclusion
Polaris is a configuration quality gate — and like any gate, a broken one provides false confidence rather than security. By monitoring the admission webhook's availability and latency, tracking audit job execution, following cluster score trends, and watching per-check failure counts, you detect configuration drift and infrastructure failures before they let misconfigured workloads into your cluster. Vigilmon's external HTTP monitoring closes the loop: if your dashboard or audit API goes dark, you know within minutes — not when an operator manually checks the dashboard and finds it missing.