Security Services

KubeOpera continuously scans your clusters and workloads for vulnerabilities and risky configuration, tracks every finding until it's resolved, and summarizes where you stand as a posture score. Three services work together:

Service	Role
security-cron	Schedules scans (every 6 hours by default) and accepts on-demand triggers.
security-collector	Runs the scans and publishes findings.
security-api	Stores findings, computes the posture score and serves the API.

How it fits together

Security pipeline

Scan → findings → posture score and incidents. Select any service for details.

SecurityFinding

security-cron triggers security-collector, which publishes findings for security-api and incident-manager.

1. security-cron triggers a scan cycle.
2. security-collector scans each cluster and tenant, and publishes each finding to the security.posture exchange.
3. security-api stores findings, tracks their status and updates the posture score.
4. incident-manager opens incidents for critical findings, grouped by cluster, category and resource.

What gets scanned

Check	What it looks for
Image vulnerabilities	Known CVEs in every running container image (Trivy).
RBAC	Overly broad ClusterRoleBindings, wildcard permissions and unused privileged service accounts.
Network policy	Namespaces without a NetworkPolicy, and policies that allow all traffic.
Pod security (CIS)	Privileged containers, privilege escalation, host paths and namespaces, running as root.
Policy compliance	Violations of your Kyverno policies.

Each finding records the resource, category, severity and a concrete recommendation.

Posture score

The score (0–100) weights open findings by severity:

score = max(0, 100 − (20 × critical + 10 × high + 3 × medium + 1 × low))

The summary also breaks the score down by category — vulnerabilities, configuration, RBAC and network — so you can see where to focus. Acknowledged findings you've accepted as risks don't count against the score; resolved findings drop out on the next scan.

Working with findings

In Monitoring → Security you can filter findings by cluster, severity and category, open one to see its remediation steps, and:

• Acknowledge it — you've seen it and accept or are tracking the risk (with a reason);
• Investigate it — launch a Security Auditor agent with the finding as context;
• Rescan — trigger a scan to confirm your fix.

security-api

Port: 8086 · Database schema: security

Method	Path	Description
GET	/api/v1/posture/summary	Posture score, severity counts and category breakdown (?cluster_id=&tenant_id=).
GET	/api/v1/findings	Findings (?severity=&category=&status=).
GET	/api/v1/findings/{id}	Finding detail and remediation steps.
POST	/api/v1/findings/{id}/acknowledge	Acknowledge a finding ({ "reason": "…" }).
GET	/api/v1/scans	Scan history.
POST	/api/v1/scan/trigger	Start a scan now.
GET	/healthz	Health check.

Tenant users see findings and scores for their own workloads only.

Configuration

Variable	Service	Default	Description
SCAN_INTERVAL	security-cron	6h	Time between scheduled scans.
TRIVY_SEVERITY	security-collector	LOW,MEDIUM,HIGH,CRITICAL	Severities to report.
DATABASE_URL	security-api	—	PostgreSQL connection.
RABBITMQ_URL	all	—	RabbitMQ connection.
PORT	security-api	8086	HTTP port.

The services authenticate to each other and to the rest of the platform with service identities over mutual TLS (see Security guide).