---
sidebar_position: 0
tags: [security]
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lium.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Pod Security

<!-- security-warning: private-keys-in-non-cvm-pods -->

:::warning Keep your secrets off rented pods
Do not upload private keys, seed phrases, API keys, or other secret files to a rented pod. The GPU provider may have access to the pod environment.
:::

## What GPU Providers Can Do on Non-CVM Machines

When you rent a pod on a machine that is **not** CVM-enabled, the GPU provider retains full host-level access to the underlying server. This means they can:

- **Inspect container contents** — read any file inside your pod, including those you copied in or generated at runtime
- **Read environment variables** — any secrets passed via `ENV`, `--env`, or `.env` files are visible
- **Read process memory** — secrets held in memory (loaded keys, decrypted tokens) can be extracted
- **Intercept network traffic** — plaintext traffic within the pod can be observed
- **Replace or modify the container** — the node image is not integrity-protected on non-CVM hosts

This is not a bug — it is a fundamental property of how Linux containers work. Containers share the host kernel; a privileged host process can always inspect container memory and filesystems.

## What You Must Never Place in a Non-CVM Pod

| Secret type | Examples |
|---|---|
| Blockchain private keys | Bittensor coldkeys/hotkeys, Ethereum/Solana wallets |
| Seed phrases / mnemonics | BIP39 recovery phrases for any wallet |
| SSH private keys | `~/.ssh/id_rsa`, `~/.ssh/id_ed25519` |
| API keys | OpenAI, Anthropic, HuggingFace, AWS, GCP, Azure tokens |
| Database credentials | PostgreSQL, MySQL, Redis passwords and connection URIs |
| OAuth/app secrets | Client secrets, JWT signing keys, webhook secrets |
| Model weights with IP value | Proprietary fine-tuned models, trade-secret weights |

## What to Do Instead

### Option 1 — Use a CVM-enabled machine (recommended for secrets)

CVM machines use Intel TDX hardware isolation. The GPU provider runs the VM but **cannot read its memory or filesystem contents**. See the [CVM guide](../providers/nodes/cvm.md) for hardware requirements and how to identify CVM-enabled nodes.

### Option 2 — Fetch secrets at runtime from an external secrets manager

If you must use a non-CVM machine, avoid placing secrets in the pod image or container filesystem. Instead:

- Pull secrets from an external vault (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager) at runtime
- Rotate secrets immediately after the pod session ends
- Use short-lived tokens scoped to the minimum required permissions
- Treat the pod as fully compromised — rotate any secrets used in it after termination

### Option 3 — Design workloads to not require secrets

- Use pre-signed URLs or token-based object storage access that expires
- Run inference against an external API rather than loading weights locally
- Separate the credential-holding component from the GPU-intensive component

## How to Identify CVM-Enabled Machines

When browsing available nodes in the Lium UI or CLI, CVM-capable machines are labeled accordingly. The [CVM guide](../providers/nodes/cvm.md) describes the required hardware (Intel TDX + NVIDIA Confidential Computing) and how attestation works.

If a machine is not labeled as CVM-enabled, assume the GPU provider can access your pod.