Runtime Protection
Review runtime security findings for workloads running on Kupe Cloud.
What’s monitored
Section titled “What’s monitored”| Threat | What it detects | Action |
|---|---|---|
| Container escape | Processes attempting to break out of container isolation | Detected and alerted |
| Reverse shell | Shell processes making outbound network connections | Detected and alerted |
| Privilege escalation | Processes changing user/group identity to gain elevated access | Detected and alerted |
| Sensitive file access | Access to password files, Kubernetes secrets, or certificates | Detected and alerted |
| Capability abuse | Processes granting themselves dangerous Linux capabilities | Detected and alerted |
| Kernel parameter tampering | Writes to /proc/sys or /sys from inside a container | Detected and alerted |
| Host access | Containers accessing host infrastructure paths | Detected and alerted |
For tenant workloads, every threat above, container escape included, is detected rather than blocked: the platform logs the event and surfaces it in the console, but does not terminate the process. That keeps false positives from disrupting legitimate workloads while still giving you visibility.
Viewing runtime events
Section titled “Viewing runtime events”Open Security > Runtime in the console sidebar. The Runtime page shows:
- Detection type: what was detected (e.g., “Reverse Shell”, “Privilege Escalation”)
- Severity: critical or warning
- Event count: how many times this was detected in the last 24 hours
- Action: whether the platform blocked the process or only detected it
If the page shows “No runtime security events in the last 24 hours”, your workloads have not triggered any security detections. That is the expected state for healthy applications.
How it works
Section titled “How it works”Kupe continuously monitors workload activity and matches it against known runtime threat patterns. When a threat is detected on a tenant workload, Kupe logs the event and surfaces it in the console within minutes. Your workload continues running: the detection is informational, so you can investigate without an unexpected process kill disrupting a legitimate application.
What you should do
Section titled “What you should do”Check the Runtime page periodically, especially after deploying new workloads or third-party images.
| Event type | Recommended action |
|---|---|
| Container escape (detected) | Investigate immediately. Something in your container attempted to break out of isolation. Check the image for compromise. |
| Reverse shell | Critical: a process in your container is making outbound connections from a shell. Likely indicates compromise. Investigate the affected pod and image. |
| Privilege escalation | Check if your application legitimately needs to change user identity. If not, the image may contain unexpected binaries. |
| Sensitive file access | Verify your application needs access to the reported file. Access to /etc/shadow or service account tokens from application code is unusual. |
| Capability abuse | Review your container’s security context. Applications should not need to grant themselves additional Linux capabilities at runtime. |
Enforcement policy
Section titled “Enforcement policy”Detection mode is on for every managed cluster today, container-escape attempts included. That may move to active enforcement later, with notice before it does.
Related pages
Section titled “Related pages”- Vulnerability Scanning: CVE scanning, compliance, and SBOMs
- Cluster Policies: admission-time policy enforcement
- Container Security: security context requirements