Bali, Indonesia
Insights

Hardening Perimeter Egress dan Identitas Ephemeral pada Kluster MicroVM Firecracker Bare-Metal

October 14, 2026
0:00
Menjalankan komputasi multi-tenant di atas infrastruktur bare-metal hybrid menuntut isolasi yang jauh lebih ketat daripada sekadar namespace Linux standar. Ketika mengeksekusi kode pihak ketiga yang tidak tepercaya (untrusted code execution) menggunakan Firecracker microVM atau container LXC tanpa hak akses (unprivileged), lapisan pertahanan perimeter sering kali rapuh pada dua titik kritis: pergerakan lateral melalui jalur egress jaringan dan pengelolaan identitas berbasis kredensial statis (SSH keys atau token API jangka panjang). Pada arsitektur hybrid modern di tahun 2026, perimeter bukan lagi sekadar firewall berbasis IP statis di edge router. Perimeter telah bergeser ke interface TAP virtual di level host, hook eBPF kernel, dan otentikasi identitas jangka pendek (ephemeral workload identity). Artikel ini mengupas tuntas arsitektur pengamanan egress perimeter dan unifikasi identitas Linux berbasis SPIFFE/SPIRE untuk kluster komputasi mikro-virtualisasi bare-metal.
Dalam infrastruktur hybrid yang menghubungkan bare-metal on-premise ke VPC cloud publik (misalnya AWS atau GCP via DirectConnect/Interconnect), microVM yang terkompromi biasanya mencoba tiga langkah eksploitasi:
  1. Cloud Metadata Extraction: Mengakses endpoint link-local 169.254.169.254 untuk mencuri IAM role bare-metal instance atau gateway proxy.
  2. Lateral Network Scanning: Mengirimkan paket probe TCP SYN/ARP spoofing ke subnet internal host lain melalui jembatan bridge Linux lokal.
  3. C2 Beaconing via Egress Tersembunyi: Membangun tunnel terenkripsi ke command-and-control server menggunakan port umum seperti UDP/443 (QUIC) atau TCP/80.
Berikut adalah arsitektur isolasi lalu lintas network dan penerbitan identitas berbasis kernel yang diterapkan langsung pada host Linux:
TEXT
+--------------------------------------------------------------------------+
| BARE-METAL HOST (Linux Kernel 6.8+ / cgroup v2)                          |
|                                                                          |
|  +---------------------------+       +--------------------------------+  |
|  | Firecracker microVM (VM1) |       | Unprivileged LXC (Tenant B)   |  |
|  | UID Mapping: 100000       |       | UID Mapping: 200000            |  |
|  |   +-------------------+   |       |   +------------------------+   |  |
|  |   | App + SPIRE Agent |   |       |   | App + Spiffe Helper    |   |  |
|  |   +---------+---------+   |       |   +-----------+------------+   |  |
|  +-------------|-------------+       +---------------|----------------+  |
|                | /tmp/agent.sock (UDS bind-mount)    |                   |
|                v                                     v                   |
|  +---------------------------+       +--------------------------------+  |
|  | SPIRE Server Node Agent   |       | Kernel tc-bpf / nftables       |  |
|  | Attestation: PID + cgroup |       | Strict Egress Drop Rules       |  |
|  +-------------+-------------+       +---------------+----------------+  |
|                |                                     |                   |
|                v                                     v                   |
|          tap-vm1 (veth)                         tap-lxc (veth)           |
|                +------------------+------------------+                   |
|                                   v                                      |
|                 br-isolated (Bridge tanpa ARP/DHCP)                      |
|                                   |                                      |
|                                   v                                      |
|                 [ eBPF Redirection & Egress Gateway ]                    |
+-----------------------------------|--------------------------------------+
                                    v
                         Internet / Public APIs
Setiap Firecracker microVM berkomunikasi dengan host melalui interface TAP berpasangan. Mengizinkan bridge Linux bertindak sebagai switch layer-2 tanpa filter adalah kesalahan fatal. Kita harus mengunci interface TAP ini menggunakan aturan nftables atomik begitu microVM diinisialisasi. Berikut konfigurasi /etc/nftables/microvm-egress.nft yang membatasi egress hanya ke resolver DNS internal terpercaya dan memblokir seluruh akses ke subnet privat internal serta endpoint metadata cloud:
TEXT
table inet microvm_filter {
    set allowed_dns {
        type ipv4_addr
        elements = { 10.0.0.53, 1.1.1.1 }
    }

    chain vm_egress {
        type filter hook prerouting priority mangle; policy drop;

        # Blokir keras Cloud Metadata Service (AWS/GCP/Azure link-local)
        ip daddr 169.254.169.254 drop

        # Izinkan paket established/related (jawaban dari koneksi sah)
        ct state established,related accept

        # Izinkan DNS hanya ke IP resolver resmi
        ip daddr @allowed_dns udp dport 53 accept
        ip daddr @allowed_dns tcp dport 53 accept

        # Blokir akses ke subnet internal hybrid (RFC 1918) kecuali gateway
        ip daddr { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 } drop

        # Izinkan egress HTTPS ke internet publik via TLS (Port 443)
        tcp dport 443 ct state new accept

        # Drop dan log seluruh paket mencurigakan lainnya
        log prefix '[NFT-EGRESS-BLOCKED]: ' flags all counter drop
    }
}
Muat ruleset tersebut ke kernel menggunakan perintah:
BASH
nft -f /etc/nftables/microvm-egress.nft
Mengirimkan API key, AWS secret access key, atau private SSH key ke dalam microVM melalui cloud-init atau inject disk image membuka risiko pencurian data jika memori VM di-dump. Solusi standar industri saat ini adalah SPIFFE (Secure Production Identity Framework for Everyone) yang diimplementasikan melalui SPIRE. Host bertindak sebagai SPIRE Server atau Agent lokal. MicroVM tidak memiliki kredensial statis. Saat aplikasi di dalam microVM membutuhkan akses ke basis data atau layanan cloud hybrid, aplikasi meminta X.509 SVID (SPIFFE Verifiable Identity Document) ke SPIRE Agent melalui Unix Domain Socket yang di-proxy oleh host. Konfigurasi node attestation SPIRE agent /etc/spire/agent.conf pada host bare-metal:
TEXT
agent {
    data_dir = '/var/lib/spire/data'
    log_level = 'INFO'
    server_address = 'spire-server.internal.infra'
    server_port = 8443
    socket_path = '/run/spire/sockets/agent.sock'
    trust_bundle_path = '/etc/spire/bundle.crt'
    trust_domain = 'infra.internal'
}

plugins {
    NodeAttestor 'join_token' {}

    KeyManager 'disk' {
        plugin_data {
            directory = '/var/lib/spire/data'
        }
    }

    WorkloadAttestor 'unix' {
        plugin_data {
            discover_workload_path = true
        }
    }

    WorkloadAttestor 'cgroup' {
        plugin_data {
            cgroup_root = '/sys/fs/cgroup'
        }
    }
}
SPIRE agent memverifikasi kredensial proses pemanggil berdasarkan ID cgroup v2 Linux dan ID namespace proses (pid dan mnt), memvalidasi bahwa proses tersebut memang benar berjalan di dalam cgroup microVM milik tenant terkait sebelum menyerahkan token X.509 berumur pendek (TTL 15 menit).
Selain konfigurasi firewall, parameter kernel host bare-metal wajib disesuaikan untuk menghentikan serangan routing, ARP table poisoning, dan mitigasi resource exhaustion. Jalankan penyesuaian sysctl berikut di /etc/sysctl.d/99-microvm-security.conf:
TEXT
# Matikan source routing IP demi mencegah paket spoofing
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0

# Aktifkan Strict Reverse Path Filtering (Strict Mode: 1)
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Matikan ICMP Redirect acceptance & sending
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

# Batasi unprivileged eBPF untuk mencegah kernel memory probe dari host container
kernel.unprivileged_bpf_disabled = 1
net.core.bpf_jit_harden = 2

# Tingkatkan kapasitas koneksi bridge dan antrean network packet
net.core.netdev_max_backlog = 16384
net.core.somaxconn = 8192
Terapkan perubahan kernel tanpa reboot:
BASH
sysctl -p /etc/sysctl.d/99-microvm-security.conf
Memilih kombinasi teknologi antara isolasi jaringan dan pengelolaan identitas melibatkan trade-off langsung antara keamanan, latensi overhead, dan kompleksitas operasional:
Metode Kontrol Identitas & EgressOverhead Latensi JaringanKonsumsi Memori HostVektor Keamanan SisaKompleksitas Operasional
Static SSH Keys + Open NAT BridgeNegligible (< 0.05 ms)~2 MB per VMLateral pivot, MITM, key theftSangat Rendah
OpenVPN/WireGuard Sidecar + PAM LDAPTinggi (1.8 - 4.2 ms)~64 MB per VMLong-lived certs, LDAP bottleneckSedang
HashiCorp Vault Agent (Dynamic Secret)Rendah (0.2 - 0.5 ms)~32 MB per VMDisk token leak, secret pollingTinggi
SPIFFE/SPIRE (mTLS) + Kernel eBPF/nftSangat Rendah (< 0.1 ms)~8 MB per Host AgentTidak ada kredensial disk, zero-trustMenengah-Tinggi
Untuk menyatukan keamanan perimeter ini, script deployment wrapper Firecracker harus menyiapkan interface TAP, menetapkannya ke cgroup spesifik, dan memuat security profile sebelum proses Firecracker dieksekusi. Berikut implementasi script orchestrator ringkas dalam Bash (launch-tenant-microvm.sh):
BASH
#!/usr/bin/env bash
set -euo pipefail

TENANT_ID='tenant-402'
TAP_DEV="tap-$&#123;TENANT_ID&#125;"
CGROUP_PATH="/sys/fs/cgroup/microvms/$&#123;TENANT_ID&#125;"
FIRECRACKER_SOCKET="/tmp/firecracker-$&#123;TENANT_ID&#125;.socket"

echo '[*] Membuat namespace cgroup v2...'
mkdir -p "$&#123;CGROUP_PATH&#125;"
echo '+memory +pids +cpu' > /sys/fs/cgroup/microvms/cgroup.subtree_control
echo '1024M' > "$&#123;CGROUP_PATH&#125;/memory.max"
echo '100' > "$&#123;CGROUP_PATH