Advanced

Runtime Security for ML Containers

Static scanning catches known vulnerabilities before deployment. Runtime security detects active threats, policy violations, and anomalous behavior in running ML containers.

Falco for ML Container Monitoring

Falco is the de facto standard for Kubernetes runtime security. For ML workloads, custom rules are needed to detect ML-specific threats:

  1. Model Exfiltration Detection

    Create Falco rules that alert when ML containers establish unexpected network connections. A training container suddenly uploading data to an external endpoint may indicate model theft.

  2. GPU Device Access Monitoring

    Monitor access to /dev/nvidia* devices. Alert on unexpected processes accessing GPU devices, which may indicate container escape or privilege escalation through the GPU driver.

  3. File Integrity Monitoring

    Watch for modifications to model weight files, configuration files, and CUDA libraries. Unauthorized changes to model files could indicate model poisoning attacks.

  4. Process Anomaly Detection

    ML containers should run a predictable set of processes (Python, CUDA runtime, NCCL). Alert on unexpected process execution such as shells, network tools, or package managers.

Seccomp Profiles for ML

Seccomp (Secure Computing Mode) restricts which system calls a container can make. ML workloads need a carefully tuned profile:

Syscall Category ML Requirement Policy
File I/O Reading model weights, writing checkpoints Allow with path restrictions
Network NCCL communication for distributed training Allow specific ports only
Memory Large memory allocations for model tensors Allow mmap, mprotect
IPC Shared memory for GPU data transfer Allow when multi-GPU is needed
Process Spawning data loader workers Allow fork/clone, deny exec of shells

GPU Memory Isolation

GPU Memory Risk: By default, GPU memory is not cleared between container uses. A subsequent container on the same GPU could potentially read residual data from a previous ML workload, including model weights, training data, or intermediate activations.
  • CUDA MPS isolation: Configure NVIDIA Multi-Process Service with separate memory spaces per container
  • MIG partitioning: Use hardware-level GPU partitioning on supported cards for true memory isolation
  • Memory clearing: Implement GPU memory clearing in your container shutdown hooks using torch.cuda.empty_cache() and explicit memory deallocation
  • Encryption in transit: For distributed training across nodes, enable NCCL encryption to protect gradient data in transit

Runtime Policy Enforcement

OPA Gatekeeper

Use Open Policy Agent to enforce runtime policies: block containers running as root, require resource limits, enforce image signing, and validate GPU resource requests.

Kyverno Policies

Write Kubernetes-native policies that mutate and validate ML pod specifications. Auto-inject security contexts, enforce read-only root filesystems, and verify image signatures.

Network Observability

Deploy Cilium or Calico with network flow logging. Detect and block unexpected network connections from ML containers, including data exfiltration attempts.

Audit Trail

Maintain comprehensive audit logs of all GPU workload activities. Track model access, data pipeline executions, and configuration changes for compliance and forensics.

💡
Next Up: In the final lesson, we bring everything together with a comprehensive ML container security best practices checklist and production deployment patterns.

Ready to Go Deeper?

Live instructor-led courses from our partners. Affiliate disclosure.