Protection Score¶

Authorised application boundary

Authorised application code is trusted. An authorised app can send out a secret it has copied or encoded. Current content checks do not provide a general guarantee against this disclosure or a malicious authorised app. Memory-read tests and a Ready agent do not prove copied/encoded-secret exfiltration prevention. Enforced NetworkPolicy can restrict destinations, but allowed traffic remains a channel. See Security Model.

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 175 points across 17 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)
`vault_tls_verified`	20	TLS certificate chain to OpenBao vault fully verified (not skipped or downgraded)
`broker_tls_verified`	20	TLS certificate chain to beacon broker relay fully verified (not skipped or downgraded)
`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 (tier behind LSM)
`confidential_vm`	10	Hardware memory encryption (AMD SEV-SNP) active

Maximum score: 175 points

Score Interpretation¶

Score Range	Assessment	Recommendation
165--175	Full protection	Production ready. All critical defenses active including TLS verification.
130--164	Strong protection	Most defenses active. Review which checks are missing and evaluate risk.
90--129	Partial protection	Key mechanisms missing. Not recommended for regulated workloads.
Below 90	Insufficient	Multiple critical mechanisms inactive. Investigate immediately.

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

Without memfd_secret (15 points), ebpf_enforce_mode (15 points), verified TLS to vault and broker (vault_tls_verified 20 points, broker_tls_verified 20 points), and at least one synchronous-deny tier (ebpf_lsm_enforce 15 points or ebpf_kprobes 10 points), a determined attacker can read process memory through standard kernel interfaces or intercept secrets in transit. 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 a kernel primitive that removes a direct-map alias, not hardware isolation against root. Arbitrary kernel code, separate store login and application copies remain outside that boundary.

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; distribution names alone do not establish that prerequisite. Assessed stock AKS Ubuntu and Azure Linux defaults omit bpf and are expected to refuse (assessed, not run); actual enforcement/refusal needs live evidence. AKS needs a verified node configuration; see Platform Compatibility.

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, reactive kill (SIGKILL after tracepoint detection) is the only remaining layer for the uncovered vectors. It has a gap between syscall execution and process termination, and the default chart does not count it as enforcement: the agent is not ready.

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.

vault_tls_verified: 20 points¶

The wrapper verified the full TLS certificate chain when connecting to the OpenBao vault server. Without TLS verification, a man-in-the-middle attacker on the network path between the wrapper and vault could intercept every secret the wrapper fetches -- the highest-impact transport-layer attack. The 20-point weight reflects that a compromised vault channel defeats every memory-protection mechanism downstream: if the attacker controls what the wrapper receives, no amount of memfd_secret or eBPF enforcement protects the real secret values.

broker_tls_verified: 20 points¶

The wrapper verified the full TLS certificate chain when connecting to the beacon broker relay. The broker relay is the P2P transport that carries secrets from the EU-hosted port to the target cluster. An unverified broker connection exposes the same risk as an unverified vault connection -- a network-positioned attacker can intercept or tamper with secrets in transit. The 20-point weight matches vault_tls_verified because both channels carry secret material and both must be authenticated end-to-end.

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: 175/175
[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]   vault_tls_verified:    OK  (+20)
[cloudtaser-wrapper]   broker_tls_verified:   OK  (+20)
[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: 145/175
[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]   vault_tls_verified:    OK   (+20)
[cloudtaser-wrapper]   broker_tls_verified:   OK   (+20)
[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: 175/175 (all defenses active)
  Warning  ProtectionDegraded  Protection score: 145/175 (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"} 175

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

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 }}/175.
            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)	165	All software protections active including TLS verification
Production (general)	130	Core protections with eBPF enforcement and TLS verification
Staging	90	Allow testing without full enforcement
Development	0	No enforcement

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