Protection Score¶

The protection score is a numeric summary of which defense mechanisms are active for a cloudtaser-protected process. It provides a quick, auditable measure of security posture and makes it immediately clear when a deployment is running below recommended levels.

The maximum score is 135 points across 15 checks.

For the complete reference with per-check explanations and per-platform guidance, see Protection Score Reference.

Score Breakdown¶

Check	Points	What It Proves
`memfd_secret`	15	Secret pages physically removed from kernel direct map (Linux 5.14+)
`mlock`	10	Secret pages pinned in RAM, cannot be swapped to disk
`core_dump_exclusion`	5	Secret pages excluded from core dumps via `MADV_DONTDUMP`
`dumpable_disabled`	5	Process is non-dumpable; /proc access restricted, ptrace blocked
`guard_pages`	5	Unmapped guard pages bracket each secret allocation; over- or under-reads into adjacent memory fault immediately
`buffer_canary`	5	Canary values adjacent to secret buffers detect overflow or corruption of the protected region
`token_protected`	10	OpenBao authentication token stored in protected memory (not on disk or in env)
`environ_scrubbed`	5	Wrapper's `/proc/self/environ` is structurally clean -- secrets enter wrapper memory only after exec, so the kernel's frozen `envp[]` snapshot never contained them
`getenv_interposer`	10	Optional LD_PRELOAD interposer blocks `getenv()` from returning secrets on the heap (glibc-only enhancement)
`ebpf_agent_connected`	10	eBPF enforcement agent is active and monitoring this process
`cpu_mitigations`	5	Spectre/Meltdown hardware mitigations active
`ebpf_enforce_mode`	15	eBPF agent running in blocking mode (not just monitoring)
`ebpf_lsm_enforce`	15	Synchronous in-kernel deny via BPF LSM hooks (strongest enforcement tier)
`ebpf_kprobes`	10	Synchronous syscall blocking via kprobe override (fallback tier behind LSM)
`confidential_vm`	10	Hardware memory encryption (AMD SEV-SNP) active

Maximum score: 135 points

Score Interpretation¶

Score Range	Assessment	Recommendation
125--135	Full protection	Production ready. All critical defenses active.
100--124	Strong protection	Most defenses active. Review which checks are missing and evaluate risk.
70--99	Partial protection	Key mechanisms missing. Not recommended for regulated workloads.
Below 70	Insufficient	Multiple critical mechanisms inactive. Investigate immediately.

A score below 70 means secrets are vulnerable to a determined attacker

Without memfd_secret (15 points), ebpf_enforce_mode (15 points), and at least one synchronous-deny tier (ebpf_lsm_enforce 15 points or ebpf_kprobes 10 points), a determined root attacker can read process memory through standard kernel interfaces. These are the most critical checks.

Point Allocation Rationale¶

The point values reflect the relative security impact of each mechanism:

memfd_secret: 15 points¶

This is the only mechanism that provides a hardware-backed guarantee against root. All other mechanisms can theoretically be bypassed by a root attacker with kernel module access. memfd_secret cannot, because the pages are physically absent from the kernel direct map.

ebpf_enforce_mode: 15 points¶

The eBPF agent in blocking mode actively prevents syscalls that would leak secrets. Without enforce mode, the agent only monitors and logs. This is the difference between detection and prevention.

ebpf_lsm_enforce: 15 points¶

The strongest enforcement tier. BPF LSM hooks fire inside the kernel before the protected operation runs and return allow/deny, with no ALLOW_ERROR_INJECTION gate. Unlike kprobe override, BPF LSM works on every cloud-standard distro that ships CONFIG_BPF_LSM=y with bpf in the boot LSM stack (GKE COS, EKS Bottlerocket, AKS Azure Linux, Talos), so synchronous deny no longer requires Ubuntu-class nodes.

ebpf_kprobes: 10 points¶

Synchronous kprobe blocking stops attacks before the syscall executes. It was demoted from 15 to 10 points in the BPF LSM migration because ebpf_lsm_enforce now covers the same primary vectors with a stronger primitive; kprobes remain as a structural fallback on LSM-covered hooks and cover the few vectors with no equivalent LSM hook. Without kprobe override the agent falls back to reactive kill (SIGKILL after tracepoint detection), which has a theoretical gap between syscall execution and process termination.

mlock: 10 points¶

Pins secret pages in physical RAM, preventing the kernel from swapping them to disk where they could be recovered.

token_protected: 10 points¶

OpenBao authentication token is the keys to the kingdom. If the token is stored in an environment variable or a file, an attacker can steal it and fetch secrets directly from OpenBao.

getenv_interposer: 10 points¶

Optional glibc-only enhancement. Eliminates the heap copy created when getenv() is called by intercepting it via LD_PRELOAD and returning a pointer to memfd_secret-backed memory. Requires a glibc-based container image (not Alpine/musl). All binaries still receive secrets through the default env-var delivery path regardless of interposer availability.

ebpf_agent_connected: 10 points¶

Confirms the eBPF agent is actively monitoring the protected process. Without the agent, memory protections are the only defense.

confidential_vm: 10 points¶

Closes the hypervisor gap -- the cloud provider's hypervisor cannot read VM memory with AMD SEV-SNP active.

core_dump_exclusion, dumpable_disabled, guard_pages, buffer_canary, environ_scrubbed, cpu_mitigations: 5 points each¶

Defense-in-depth mechanisms that each close a specific attack vector. guard_pages and buffer_canary contain buffer over-reads and memory corruption around the protected secret region. Essential but not sufficient alone.

Checking the Score¶

Wrapper Logs¶

The wrapper logs the protection score at startup:

[cloudtaser-wrapper] Protection score: 135/135
[cloudtaser-wrapper]   memfd_secret:          OK  (+15)
[cloudtaser-wrapper]   mlock:                 OK  (+10)
[cloudtaser-wrapper]   core_dump_exclusion:   OK  (+5)
[cloudtaser-wrapper]   dumpable_disabled:     OK  (+5)
[cloudtaser-wrapper]   guard_pages:           OK  (+5)
[cloudtaser-wrapper]   buffer_canary:         OK  (+5)
[cloudtaser-wrapper]   token_protected:       OK  (+10)
[cloudtaser-wrapper]   environ_scrubbed:      OK  (+5)
[cloudtaser-wrapper]   getenv_interposer:     OK  (+10)
[cloudtaser-wrapper]   ebpf_agent_connected:  OK  (+10)
[cloudtaser-wrapper]   cpu_mitigations:       OK  (+5)
[cloudtaser-wrapper]   ebpf_enforce_mode:     OK  (+15)
[cloudtaser-wrapper]   ebpf_lsm_enforce:      OK  (+15)
[cloudtaser-wrapper]   ebpf_kprobes:          OK  (+10)
[cloudtaser-wrapper]   confidential_vm:       OK  (+10)

A degraded startup shows which mechanisms failed:

[cloudtaser-wrapper] Protection score: 105/135
[cloudtaser-wrapper]   memfd_secret:          OK   (+15)
[cloudtaser-wrapper]   mlock:                 OK   (+10)
[cloudtaser-wrapper]   core_dump_exclusion:   OK   (+5)
[cloudtaser-wrapper]   dumpable_disabled:     OK   (+5)
[cloudtaser-wrapper]   guard_pages:           OK   (+5)
[cloudtaser-wrapper]   buffer_canary:         OK   (+5)
[cloudtaser-wrapper]   token_protected:       OK   (+10)
[cloudtaser-wrapper]   environ_scrubbed:      OK   (+5)
[cloudtaser-wrapper]   getenv_interposer:     FAIL (+0)  musl libc detected
[cloudtaser-wrapper]   ebpf_agent_connected:  OK   (+10)
[cloudtaser-wrapper]   cpu_mitigations:       OK   (+5)
[cloudtaser-wrapper]   ebpf_enforce_mode:     OK   (+15)
[cloudtaser-wrapper]   ebpf_lsm_enforce:      OK   (+15)
[cloudtaser-wrapper]   ebpf_kprobes:          FAIL (+0)  CONFIG_BPF_KPROBE_OVERRIDE not set
[cloudtaser-wrapper]   confidential_vm:       FAIL (+0)  no confidential computing hardware

CLI Status Command¶

cloudtaser-cli target status --pod my-app-7d8f9c6b4-xk2mn --namespace production

Kubernetes Events¶

The wrapper emits Kubernetes events on the pod for score changes:

Events:
  Type     Reason              Message
  ----     ------              -------
  Normal   ProtectionActive    Protection score: 135/135 (all defenses active)
  Warning  ProtectionDegraded  Protection score: 105/135 (getenv_interposer, ebpf_kprobes, confidential_vm unavailable)

Alerting on Low Scores¶

Prometheus Metrics¶

The wrapper exposes the protection score as a Prometheus metric:

# HELP cloudtaser_protection_score Current protection score
# TYPE cloudtaser_protection_score gauge
cloudtaser_protection_score{pod="my-app-7d8f9c6b4-xk2mn",namespace="production"} 135

# HELP cloudtaser_protection_max Maximum possible protection score
# TYPE cloudtaser_protection_max gauge
cloudtaser_protection_max{pod="my-app-7d8f9c6b4-xk2mn",namespace="production"} 135

Example Alert Rule¶

groups:
  - name: cloudtaser
    rules:
      - alert: CloudTaserProtectionDegraded
        expr: cloudtaser_protection_score < 100
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "cloudtaser protection score below threshold"
          description: >
            Pod {{ $labels.pod }} in namespace {{ $labels.namespace }}
            has protection score {{ $value }}/135.
            Secrets may be vulnerable to root-level extraction.

Enforcing Minimum Scores¶

Use the CLOUDTASER_MIN_PROTECTION_SCORE environment variable to prevent the wrapper from starting if the score is too low:

env:
  - name: CLOUDTASER_MIN_PROTECTION_SCORE
    value: "80"   # Refuse to start below this score

Recommended minimum scores by environment

Environment	Minimum Score	Rationale
Production (regulated)	125	All software protections active
Production (general)	100	Core protections with eBPF enforcement
Staging	70	Allow testing without full enforcement
Development	0	No enforcement

Full Protection Score Reference | Security Model | Memory Protection | eBPF Enforcement