Belajar MicroCloud - Network Isolation & TLS

#Pendahuluan

Di episode 13 keamanan datang dari model snap. Sekarang kita mengamankan jaringan — lapisan yang menghubungkan cloud kalian ke dunia luar. Di episode 14 kita membahas isolasi network: memisahkan underlay storage/OVN dari akses client, VLAN dan firewall per segmen, lalu mengamankan akses admin lewat TLS dan certificate dengan lxc remote add.

Analogi: gedung cloud kalian (cluster) punya banyak pintu. Storage antar-node seperti koridor internal — hanya untuk karyawan (node cluster). Akses client seperti resepsionis publik — orang luar boleh masuk tapi dengan aturan. Akses admin seperti ruang server terkunci — hanya orang dengan kunci (certificate) yang boleh masuk. Episode ini memasang papan nama, pintu, dan kunci yang tepat.

#Memisahkan Underlay dari Akses Client

#Tiga Aliran Trafik di MicroCloud

Dalam cluster MicroCloud, ada tiga jenis trafik yang perlu dipahami:

Storage (Ceph): replikasi data antar node — paling sensitif terhadap latency, paling berat.
Overlay OVN: trafik instance antar node (tunnel Geneve).
Client/management: akses user ke instance, dan akses admin ke API LXD.

Mencampur ketiganya di satu segmen terbuka memudahkan penyadapan dan meningkatkan risiko. Desain yang baik memisahkannya.

#Desain Underlay yang Direkomendasikan

Untuk production, pisahkan dengan NIC atau VLAN:

Pemisahan segmen jaringan

NIC eth0  ──► VLAN 10  management + client access
NIC eth1  ──► VLAN 20  storage (Ceph replication)
NIC eth2  ──► VLAN 30  overlay OVN (tunnel antar-node)

Kalau NIC terbatas, minimal dua segmen:

eth0/VLAN management — termasuk akses client dan API admin.
eth1/VLAN storage+overlay — trafik cluster internal yang berat.

#Firewall Per Segmen

Dengan pemisahan segmen, terapkan firewall per antarmuka. Contoh aturan dengan ufw di tiap node:

Batasi akses API LXD ke segmen admin

sudo ufw allow from 192.168.10.0/24 to any port 8443 proto tcp
sudo ufw deny 8443

Batasi port OVN ke subnet cluster

sudo ufw allow from 192.168.20.0/24 to any port 6081 proto udp
sudo ufw deny 6081

Aturan di atas memperbolehkan segmen admin mengakses API LXD (8443) dan subnet cluster untuk tunnel OVN (6081), sambil menolak yang lain.

Warning

Jangan menutup port cluster antar-node (8443 LXD, 6789/6800-7300 Ceph, 6081 OVN) di antara sesama node — cluster butuh komunikasi penuh tersebut. Firewall diterapkan untuk memisahkan dunia luar dari segmen internal, bukan untuk memblokir antar member.

#Akses Admin via TLS

#LXD Remote dan Certificate

API LXD di-expose lewat HTTPS (default port 8443) dengan certificate untuk otentikasi. Admin mengakses cluster dari mesin mana pun via lxc remote add:

Tambah remote ke cluster MicroCloud

lxc remote add mycloud https://node-a:8443 --accept-certificate

Saat ditambah, kalian harus mempercayai certificate cluster (fingerprint ditampilkan) dan cluster harus menerima certificate client kalian:

Dari node cluster, tambah certificate client

lxc config trust add < client.crt

Verifikasi remote terhubung

lxc remote list
lxc remote switch mycloud
lxc cluster list

#Akses Admin Terenkripsi

Setelah remote terpasang, seluruh interaksi berjalan di atas TLS 1.3:

Identitas server diverifikasi dari certificate cluster.
Identitas client diverifikasi dari certificate yang ditrusted.
Trafik admin (membuat instance, membaca status) terenkripsi.

Alur TLS remote LXD

client ──(TLS 1.3)──► https://node-a:8443 ──► LXD cluster
  │                                          │
  └─ cert client (ditrust)  ◄────────── cert cluster (fingerprint)

#Opsi Otentikasi Lanjutan

Selain certificate, LXD mendukung Candid/SSO untuk otentikasi berbasis identitas, dan RBAC untuk kontrol akses per user. Untuk fleksibilitas tanpa membangun SSO, kalian bisa menambah beberapa certificate dengan scope berbeda.

#Best Practice Isolasi

API LXD hanya di segmen admin: jangan expose 8443 ke jaringan publik/klien.
Rotasi certificate: ketika admin keluar atau certificate bocor, hapus dari lxc config trust dan buat baru.
Akses instance via network OVN: biarkan user mengakses instance lewat IP OVN/NAT yang diatur, bukan langsung ke host.
Audit koneksi: gunakan lxc config trust list untuk mengetahui siapa saja yang punya akses admin.

Lihat certificate yang dipercaya

lxc config trust list

Hapus certificate yang tidak dipercaya lagi

lxc config trust remove <fingerprint>

#Pitfall Umum

Remote gagal karena certificate: ulangi --accept-certificate dan pastikan certificate client sudah ditrust di cluster.
Firewall memblokir antar node: gejala klasik — cluster "sehat" tapi intermiten; verifikasi port antar-node dulu sebelum menebak.
Expose 8443 ke publik: sangat berisiko; jika terpaksa, bungkus dengan VPN atau reverse proxy + RBAC.
Mencampur trafik tanpa segregasi: untuk lab boleh, untuk produksi jangan — investasi segmen kecil mencegah insiden besar.

#Penutup

Inti yang harus dibawa pulang:

Pisahkan trafik storage/overlay dari akses client — NIC atau VLAN terpisah.
Terapkan firewall per segmen; jangan blokir komunikasi antar node.
API LXD (8443) hanya boleh diakses dari segmen admin, via TLS.
lxc remote add + trust certificate memberi akses admin terenkripsi dari mana saja.
Rotasi dan review certificate secara berkala (lxc config trust list).

Di episode 15 selanjutnya kita akan membahas encryption & data protection — enkripsi disk Ceph saat init dengan LUKS, encryption at-rest data, proactive trust saat join sejak init 2.1, dan audit log untuk compliance. Data kalian akan aman diam dan bergerak!