How to Monitor StackRox / RHACS with Vigilmon

StackRox (Red Hat Advanced Cluster Security for Kubernetes, or RHACS) is an enterprise Kubernetes security platform that provides vulnerability management, compliance, network segmentation, and runtime threat detection. It runs as a Central service (the control plane) and Secured Cluster Services (sensors on each monitored cluster).

In this tutorial you'll set up external uptime monitoring for StackRox/RHACS using Vigilmon — free tier, no credit card required.

Why StackRox / RHACS needs external monitoring

StackRox Central is a critical piece of infrastructure. When it goes down:

• Compliance drift goes undetected — policy violations accumulate silently; audit reports become stale
• New deployments skip security checks — if the admission controller webhook becomes unreachable, it may fail open or fail closed depending on configuration, either allowing unsafe workloads or blocking all deployments
• Sensor disconnection — Secured Cluster sensors lose contact with Central, buffering events locally; runtime threat alerts stop flowing
• Security team loses visibility — the RHACS portal and API are unavailable to analysts who need to investigate incidents

Kubernetes health probes only check pod-level liveness. They cannot confirm that the Central web interface is reachable from your network, that the gRPC port is accepting sensor connections, or that TLS certificates are valid. External monitoring fills these gaps.

What you'll need

• StackRox Central deployed in your cluster (typically the stackrox or rhacs-operator namespace)
• Central exposed via LoadBalancer, NodePort, or Ingress
• A free Vigilmon account

Step 1: Find your Central endpoint

# Check Central pods
kubectl get pods -n stackrox

# Expected output
# NAME                  READY   STATUS    RESTARTS   AGE
# central-xxx           1/1     Running   0          5m
# scanner-xxx           1/1     Running   0          5m
# scanner-db-xxx        1/1     Running   0          5m

# Get the Central service
kubectl get svc -n stackrox central-loadbalancer
# NAME                  TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)         AGE
# central-loadbalancer  LoadBalancer   10.96.8.100     203.0.113.90    443:30443/TCP   5m

Central listens on port 443 (HTTPS). Verify it responds:

curl -sk https://203.0.113.90/v1/ping
# {"status":"ok"}

The /v1/ping endpoint is a public health check that returns {"status":"ok"} without requiring authentication. This is the ideal Vigilmon probe endpoint.

Step 2: Set up HTTP monitoring in Vigilmon

1. Log in to vigilmon.online and go to Monitors → New Monitor
2. Choose HTTP / HTTPS as the type
3. URL: https://203.0.113.90/v1/ping (or https://your-rhacs-hostname/v1/ping)
4. Set the check interval to 1 minute
5. Under Expected response:
   • Status code: 200
   • Response body contains: "status":"ok"
6. Save the monitor

The body match on "status":"ok" ensures you're alerted not just on connection failures but also on degraded states where Central is reachable but reporting problems.

Why multi-region consensus matters for security tooling

Vigilmon probes from multiple geographic locations simultaneously. A single probe failure could be a transient network issue; multi-region consensus only fires an alert when multiple independent probers agree Central is unreachable. For a security control plane, this eliminates false-positive pages while ensuring genuine outages are caught in seconds.

Step 3: Monitor the gRPC port for sensor connectivity

StackRox sensors connect to Central over gRPC on port 443 (same port, different protocol multiplexed via ALPN). You can add a dedicated TCP monitor for this:

1. Go to Monitors → New Monitor
2. Choose TCP Port
3. Host: 203.0.113.90
4. Port: 443
5. Save the monitor

This catches load balancer or network routing failures that might affect sensor connections even when the web UI appears healthy.

If your Central exposes a separate gRPC port (some deployments use 8443 for sensor connections), add a TCP monitor for that port as well.

Step 4: Monitor the Scanner service

StackRox Scanner performs image vulnerability scanning. It runs as a separate pod and is called by Central synchronously during image analysis. If Scanner goes down, vulnerability data becomes stale:

# Check Scanner service
kubectl get svc -n stackrox scanner
# scanner   ClusterIP   10.96.9.200   <none>   8080/TCP,8443/TCP   5m

Scanner is typically a ClusterIP service (not exposed externally). To monitor it externally, either:

1. Create a NodePort temporarily for monitoring purposes:

apiVersion: v1
kind: Service
metadata:
  name: scanner-nodeport
  namespace: stackrox
spec:
  type: NodePort
  selector:
    app: scanner
  ports:
    - port: 8080
      targetPort: 8080
      nodePort: 30880

2. Or rely on Central's overall health as a proxy (if Central is healthy and Scanner is down, Central's image scan responses will degrade, which you'll catch via the /v1/ping HTTP monitor).

Step 5: Configure alert channels

RHACS outages require immediate response — they represent a gap in your security controls.

Email alerts

1. Go to Alert Channels → Add Channel → Email
2. Add your security operations team email
3. Assign to all StackRox monitors

Webhook alerts

1. Go to Alert Channels → Add Channel → Webhook
2. Enter your Slack, PagerDuty, or Opsgenie webhook URL

Example Vigilmon payload when Central goes down:

{
  "monitor_name": "StackRox Central /v1/ping",
  "status": "down",
  "url": "https://203.0.113.90/v1/ping",
  "started_at": "2024-01-15T10:23:00Z",
  "duration_seconds": 60
}

Incident runbook when this alert fires:

# 1. Check pod health
kubectl get pods -n stackrox

# 2. Check Central logs for startup/crash details
kubectl logs -n stackrox -l app=central --tail=100

# 3. Check PVC — Central uses a PVC for its database; disk full = crash
kubectl get pvc -n stackrox

# 4. Verify admission controller webhook status
kubectl get validatingwebhookconfigurations | grep stackrox

# 5. Check sensor connectivity from a secured cluster
# On the secured cluster:
kubectl get pods -n stackrox  # sensor pod should be Running
kubectl logs -n stackrox -l app=sensor --tail=50 | grep -i "connected\|error\|disconnect"

Step 6: Monitor SSL certificate expiry

StackRox Central uses TLS certificates that are either auto-generated during installation or provided externally. If they expire, all sensor connections and web access break simultaneously.

Vigilmon automatically monitors TLS certificate expiry on HTTPS monitors. You'll receive alerts before the certificate lapses — typically 30, 14, and 7 days before expiry — giving you time to rotate certificates without an incident.

This is particularly important for StackRox because its internal PKI (used for Central-to-Sensor communication) has its own certificate chain separate from the web-facing certificate.

Step 7: Create a security operations status page

1. Go to Status Pages → New Status Page
2. Name it: "Security Operations Platform"
3. Add monitors: Central API, Central TCP, Scanner (if exposed)
4. Publish

Share with your security operations and platform teams so everyone has real-time visibility into RHACS health without needing cluster access.

Monitor summary

| Monitor | Type | What it catches | |---------|------|-----------------| | https://central:443/v1/ping | HTTP (expect 200, body "status":"ok") | Central API health, app crashes, degraded state | | central:443 | TCP | Port binding failures, load balancer routing | | scanner:30880 | TCP (if NodePort exposed) | Scanner availability for image analysis |

What's next

• RHACS on OpenShift — if running RHACS on OpenShift, the Route hostname is your monitoring target; add it alongside the LoadBalancer IP
• Multi-cluster monitoring — RHACS can secure multiple clusters from one Central; add a monitor for each cluster's sensor connectivity
• Heartbeat monitoring — if you run RHACS compliance scan jobs on a schedule, use Vigilmon heartbeats to alert when scans stop completing

Get started free at vigilmon.online — no credit card, monitors start running in under a minute.