🚀 Deployment Guide

📋 Prerequisites & System Requirements

Before deploying CyberVault, ensure your environment meets the following requirements. Insufficient resources may impact detection accuracy and response times.

🖥️

Kubernetes Cluster

K8s 1.25+ with RBAC enabled. Minimum 3 control plane nodes.

v1.25 – v1.30

💾

Resources

Minimum 16 CPU cores, 64 GB RAM, 500 GB SSD storage for the control plane.

16 vCPU / 64 GB

🐳

Container Runtime

containerd 1.6+ or Docker 24+. CRI-O also supported.

containerd 1.7+

🔑

CyberVault License

Valid license key from your account portal. Trial keys accepted.

Enterprise / Trial

🌐

Network Access

Outbound HTTPS to api.cybervault.io and updates.cybervault.io.

TLS 1.2+

🛠️

CLI Tools

kubectl 1.25+, Helm 3.12+, Docker/nerdctl for local builds.

Helm 3.12+

⚠️

Production Warning

For production deployments, we recommend a minimum of 32 CPU cores and 128 GB RAM. High-traffic environments (10,000+ endpoints) should provision 64+ cores and 256 GB RAM for optimal performance.

🏗️ System Architecture Overview

CyberVault is designed as a distributed, fault-tolerant system deployed as native Kubernetes workloads. Below is the high-level architecture of a standard deployment.

CyberVault Deployment Architecture

External

🌍

Your Infrastructure

Endpoints & Cloud Services

📡

CVE Sensors

Traffic Mirroring

🖥️

CVE Agents

Host-based Monitoring

☁️

Cloud Connectors

AWS / Azure / GCP

⬇️ Encrypted TLS 1.3

Security

🛡️

Threat Engine

AI-Powered Detection

🔍

Rule Processor

Sigma / YARA / Custom

⚡

Response Engine

Auto-Remediation

📊

Analytics Core

Correlation & Scoring

⬇️ Internal gRPC

Infrastructure

🗄️

TimescaleDB

Event Telemetry

⚡

Redis Cluster

Caching & Sessions

📨

Kafka

Event Streaming

📦

MinIO / S3

Artifact Storage

Component	Min CPU	Min Memory	Storage	Notes
`cve-threat-engine`	4 cores	16 GB	100 GB SSD	AI model inference — GPU optional
`cve-rule-processor`	2 cores	8 GB	50 GB SSD	Scales horizontally with event rate
`cve-response-engine`	2 cores	8 GB	20 GB SSD	Requires network policy permissions
`cve-agents`	0.5 core/agent	512 MB/agent	10 GB	Deployed as DaemonSet
`timescaledb`	4 cores	16 GB	200 GB NVMe	High IOPS recommended
`redis-cluster`	2 cores	8 GB	20 GB SSD	3-node cluster minimum
`kafka`	4 cores	16 GB	200 GB SSD	3 broker cluster recommended

📦 Installation Steps

Follow these steps in order to deploy CyberVault on your Kubernetes cluster. Each step builds on the previous one.

💡

Tip

We recommend using our cve-deploy CLI tool which automates these steps. See the Quick Start Guide for a faster deployment using the CLI.

1

Initialize the Deployment

Create a new Kubernetes namespace and initialize the CyberVault Helm chart with your license key.

bash

# Create dedicated namespace
kubectl create namespace cybervault

# Add the CyberVault Helm repository
helm repo add cybervault https://charts.cybervault.io
helm repo update

# Initialize deployment with your license
helm install cybervault cybervault/platform \
  --namespace cybervault \
  --set license.key="cv-prod-xxxx-xxxx-xxxx-xxxx" \
  --set cluster.name="production-east-1" \
  --set cluster.region="us-east-1" \
  --set externalUrl="https://security.yourcompany.com" \
  --wait --timeout 15m

2

Configure Environment Variables

Customize the deployment using a values override file. This controls network policies, resource limits, and integration endpoints.

yaml — values.yaml

# values.yaml — Custom deployment configuration

license:
  key: "cv-prod-xxxx-xxxx-xxxx-xxxx"
  tier: "enterprise"

cluster:
  name: "production-east-1"
  region: "us-east-1"
  environment: "production"

threatEngine:
  replicas: 3
  gpuEnabled: true
  models:
    behavioralAI: "v4.2-latest"
    networkAnomaly: "v4.1-stable"

database:
  timescale:
    storage: "500Gi"
    storageClass: "gp3-encrypted"
  redis:
    replicas: 3
    memoryLimit: "16Gi"

networking:
  externalUrl: "https://security.yourcompany.com"
  ingressClass: "nginx"
  tls:
    enabled: true
    certManager: true

integrations:
  siem:
    splunk:
      enabled: true
      endpoint: "https://siem.yourcompany.com:8088"
      token: ${SPLUNK_HEC_TOKEN}
  ticketing:
    jira:
      enabled: true
      baseUrl: "https://jira.yourcompany.com"
  messaging:
    slack:
      enabled: true
      webhook: ${SLACK_WEBHOOK_URL}      channel: "#security-alerts"

3

Deploy the Platform

Apply your custom values and deploy the full CyberVault platform. The Helm chart will provision all required resources.

bash

# Deploy with custom values file
helm install cybervault cybervault/platform \
  --namespace cybervault \
  --values values.yaml \
  --set-file integrations.siem.splunk.token=./splunk-token.txt \
  --wait --timeout 30m

# Verify deployment status
kubectl get pods -n cybervault -w

# Expected output — all pods should reach Running state
# NAME                                    READY   STATUS    RESTARTS
# cve-threat-engine-0                    3/3     Running   0
# cve-threat-engine-1                    3/3     Running   0
# cve-threat-engine-2                    3/3     Running   0
# cve-rule-processor-6d4f8b9c7-x2k9p    2/2     Running   0
# cve-response-engine-5c8d7f4a6-m3n8q   2/2     Running   0
# cve-agent-ds-7x4kp                     1/1     Running   0
# cve-agent-ds-9m2nq                     1/1     Running   0
# timescaledb-0                          1/1     Running   0
# redis-cluster-0                        1/1     Running   0
# redis-cluster-1                        1/1     Running   0
# redis-cluster-2                        1/1     Running   0
# kafka-0                                3/3     Running   0
# kafka-1                                3/3     Running   0
# kafka-2                                3/3     Running   0

4

Install Endpoint Agents

Deploy the CVE agent DaemonSet to collect telemetry from all nodes and workloads. The agent operates with minimal overhead (< 2% CPU, < 128 MB RAM).

bash

# Deploy CVE agent as DaemonSet across all namespaces
helm install cve-agent cybervault/agent \
  --namespace cybervault \
  --set collector.endpoint="cve-ingress.cybervault.svc:8443" \
  --set collection.mode="full" \
  --set collection.processes=true \
  --set collection.network=true \
  --set collection.filesystem=true \
  --set collection.containerEvents=true \
  --set collection.kubernetesAudit=true \
  --set collection.ebpfEnabled=true

# Verify agents are running on all nodes
kubectl get daemonset cve-agent -n cybervault

# Expected: DESIRED = CURRENT = READY
# NAME        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE
# cve-agent   12        12        12      12           12

💡

eBPF Collection Mode

When ebpfEnabled: true, the agent uses eBPF for zero-overhead system call tracing. This requires Linux kernel 5.4+ and the sysctl setting kernel.unprivileged_bpf_disabled=0. For systems where eBPF is unavailable, the agent falls back to standard procfs collection.

5

Verify & Validate Deployment

Run the built-in validation suite to confirm all components are healthy and communicating.

bash

# Run the deployment validator
kubectl exec -it cve-threat-engine-0 -n cybervault -- \
  cve-cli validate --full

# Validation Results:
#
# ✅ Threat Engine — All 3 replicas healthy
# ✅ Rule Processor — 847 rules loaded
# ✅ Response Engine — Playbooks loaded (24 active)
# ✅ TimescaleDB — Connected, replication lag: 2ms
# ✅ Redis Cluster — 3/3 nodes, 0 failovers
# ✅ Kafka — 3/3 brokers, topic lag: 0
# ✅ CVE Agents — 12/12 reporting telemetry
# ✅ Ingress — TLS certificate valid (expires: 2025-12-01)
# ✅ License — Enterprise tier, valid until 2026-06-15
# ✅ SIEM Integration — Splunk HEC connected
# ✅ Slack Webhook — Deliverability confirmed
#
# 🎉 Deployment validation PASSED (11/11 checks)

⚙️ Post-Deployment Configuration

After the core platform is running, configure the following to tailor CyberVault to your environment.

Access the Web Console

The CyberVault management console is available at your configured externalUrl. Log in with the initial admin credentials:

bash

# Retrieve initial admin password
kubectl get secret cve-admin-creds -n cybervault -o jsonpath="{.data.password}" | base64 -d

# Initial login:
# URL: https://security.yourcompany.com
# Username: admin
# Password: <retrieved from secret>

🔴

Security: Change Default Credentials

You must change the default admin password on first login. You will also be prompted to enable multi-factor authentication (MFA). Failure to do so within 24 hours will lock the admin account.

Configure Detection Rules

CyberVault ships with 847 pre-configured detection rules covering MITRE ATT&CK techniques. Customize and add your own:

yaml — custom-rule.yaml

# Custom Sigma-style detection rule
rule:
  id: "cv-custom-001"
  name: "Suspicious Kubernetes RBAC Escalation"
  description: "Detects attempts to modify cluster-role-bindings"
  severity: "high"
  mitre:
    tactic: "privilege-escalation"
    technique: "T1098.003"
  conditions:
    event.type: "k8s.audit"
    event.verb: "create"
    event.resource: "clusterrolebindings"
    event.user.role: "!cluster-admin"
  response:
    playbook: "auto-quarantine-user"
    notify:
      - slack
      - jira
      - pagerduty

bash

# Deploy custom rule via CLI
cve-cli rules upload ./custom-rule.yaml \
  --namespace cybervault \
  --enable

# Verify rule is active
cve-cli rules list --filter "id:cv-custom-001"

# Output:
# ID: cv-custom-001
# Name: Suspicious Kubernetes RBAC Escalation
# Status: ✅ ACTIVE
# Severity: HIGH
# Last Triggered: Never

Set Up Network Policies

Restrict network traffic to and from CyberVault components using Kubernetes NetworkPolicy:

yaml — network-policy.yaml

# Restrict ingress to only the Ingress Controller
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: cve-ingress-only
  namespace: cybervault
spec:
  podSelector:
    matchLabels:
      app: cve-ingress
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: ingress-nginx
      ports:
        - protocol: TCP
          port: 8443

✅ Verification & Health Checks

Confirm your deployment is functioning correctly with these verification steps.

API Health Endpoint

bash

# Check overall system health
curl -s https://security.yourcompany.com/api/v1/health | jq .

# Expected response:
# {
#   "status": "healthy",
#   "components": {
#     "threatEngine": { "status": "healthy", "uptime": "14d 6h 23m" },
#     "ruleProcessor": { "status": "healthy", "rulesLoaded": 847 },
#     "responseEngine": { "status": "healthy", "playbooks": 24 },
#     "database": { "status": "healthy", "connections": 142 },
#     "messageBus": { "status": "healthy", "lag": "0ms" }
#   },
#   "agents": { "online": 12, "offline": 0 },
#   "events": { "processed": 2847291, "blocked": 12043 }
# }

Generate a Test Event

Create a safe test event to verify the full detection pipeline:

bash

# Generate a synthetic test alert (safe, won't trigger real response)
cve-cli test alert generate \
  --type "simulated-malware" \
  --severity "high" \
  --source "192.168.1.100"

# Expected: Alert created → Rules evaluated → Slack notification sent
# ✅ Test alert processed successfully in 42ms
# ✅ 2 rules matched: cv-base-012, cv-custom-005
# ✅ Notification sent to: #security-alerts
# ✅ Jira ticket created: SEC-1847

🎉

Deployment Complete!

If all health checks pass and your test alert was processed correctly, your CyberVault deployment is operational. Navigate to the web console to explore your security posture dashboard.

🐛 Troubleshooting

Common issues and their solutions.

Pods stuck in `ContainerCreating`

bash

# Diagnose with describe
kubectl describe pod <pod-name> -n cybervault | grep -A 5 "Events:"

# Common fix: Image pull failure — verify image registry access
kubectl create secret docker-registry regcred \
  --namespace cybervault \
  --docker-server=registry.cybervault.io \
  --docker-username=${REGISTRY_USER} \
  --docker-password=${REGISTRY_PASS}

Agent telemetry not reaching the platform

bash

# Check agent logs for connection errors
kubectl logs -n cybervault -l app=cve-agent --tail 50

# Verify DNS resolution inside the agent pod
kubectl exec -it cve-agent-ds-xxxxx -n cybervault -- \
  nslookup cve-ingress.cybervault.svc

# Verify connectivity to the ingress endpoint
kubectl exec -it cve-agent-ds-xxxxx -n cybervault -- \
  curl -k https://cve-ingress.cybervault.svc:8443/health

License validation fails

🔴

License Check Failed

Ensure your cluster has outbound HTTPS access to api.cybervault.io on port 443. The platform performs online license validation on startup and every 24 hours. If offline validation is needed, contact your CyberVault account manager to configure an offline license file.

↩️ Rollback Procedures

If you need to rollback or uninstall CyberVault, follow these procedures carefully.

Rollback to Previous Version

bash

# View release history
helm history cybervault -n cybervault

# Rollback to previous revision
helm rollback cybervault 2 -n cybervault --wait --timeout 15m

# Verify rollback
kubectl get pods -n cybervault -w

Full Uninstall

⚠️

Destructive Action

This will remove all CyberVault resources and permanently delete all telemetry data. Ensure you have exported any critical alerts and reports before proceeding.

bash

# Export data before uninstall (recommended)
cve-cli data export --format "json" --output ./export-$(date +%Y%m%d).json

# Uninstall platform and agent
helm uninstall cve-agent -n cybervault
helm uninstall cybervault -n cybervault

# Remove PersistentVolumeClaims (manual — data will be lost)
kubectl delete pvc -n cybervault -l release=cybervault

# Remove namespace
kubectl delete namespace cybervault

🚀 Deployment Guide

📋 Prerequisites & System Requirements

Kubernetes Cluster

Resources

Container Runtime

CyberVault License

Network Access

CLI Tools

🏗️ System Architecture Overview

CyberVault Deployment Architecture

📦 Installation Steps

Initialize the Deployment

Configure Environment Variables

Deploy the Platform

Install Endpoint Agents

Verify & Validate Deployment

⚙️ Post-Deployment Configuration

Access the Web Console

Configure Detection Rules

Set Up Network Policies

✅ Verification & Health Checks

API Health Endpoint

Generate a Test Event

🐛 Troubleshooting

Pods stuck in ContainerCreating

Agent telemetry not reaching the platform

License validation fails

↩️ Rollback Procedures

Rollback to Previous Version

Full Uninstall

Pods stuck in `ContainerCreating`