Belajar Tailscale - Production-Ready Deployment

#Pendahuluan

Hingga episode 20, kalian menyambungkan perangkat satu per satu. Di production, pendekatan itu tidak akan bertahan: ada puluhan node baru, ratusan user, dan tidak ada waktu untuk login manual.

Episode 21 membahas production-ready deployment: provisioning massal dengan auth keys dan OAuth, manajemen fleet lewat MDM, monitoring devices, kebijakan update terpusat, plus checklist production seperti ACL ketat, Tailnet Lock, audit log, backup konfigurasi, dan runbook.

Tujuan akhirnya satu: tailnet yang bisa dirawat oleh tim kecil tanpa drama.

#Provisioning Massal

#Auth Keys One-Shot dan Ephemeral

Auth keys adalah cara termudah untuk menambahkan banyak node tanpa interaksi manusia:

sudo tailscale up --auth-key=tskey-auth-kEYmPLdExample

Key yang di-generate di admin console bisa dibuat one-shot atau ephemeral. Node ephemeral dihapus otomatis dari tailnet saat tailscale down — ideal untuk CI runner dan container yang lahir dan mati terus-menerus. Pastikan key punya masa berlaku, dan jangan pernah menaruhnya di repository.

#OAuth untuk Provisioning Aman

Auth key statis adalah risiko bocor. Alternatif yang lebih aman adalah OAuth client: client id dan secret dipakai untuk menukar token yang pendek umurnya:

sudo tailscale up \
  --auth-key="$(curl -s -X POST \
    https://api.tailscale.com/api/v2/oauth/token \
    -d client_id=oauthexample -d client_secret=secret)"

Skema lengkapnya kalian pelajari di episode 17. Intinya, token ditukar pada saat provisioning, bukan di-commit ke konfigurasi — sehingga kebocoran di satu tempat tidak membuka seluruh fleet.

#Manajemen Fleet

#MDM untuk macOS dan Windows

Untuk perangkat kerja, distribusikan konfigurasi Tailscale lewat MDM: di macOS memakai Configuration Profile, di Windows memakai ADMX dan registry. Dengan cara ini, package terinstall dan kebijakan dasar diterapkan sebelum user login.

Kombinasi OAuth device provisioning dengan MDM menghasilkan pengalaman yang mulus: perangkat baru terdaftar ke tailnet tanpa meminta user memasukkan auth key secara manual.

#Monitoring Devices

Pantau kesehatan fleet dari satu tempat:

curl -s https://api.tailscale.com/api/v2/tailnet/example.com/devices \
  -H "Authorization: Bearer tskey-api-xxxxx"

Data dari tailscale status --json di tiap node atau endpoint API di atas bisa dipakai untuk menampilkan status online dan offline, versi client, dan route yang diiklankan di dashboard tim.

#Kebijakan Update Terpusat

Daripada menyetel auto-update di tiap node, paksakan lewat ACL:

{
  "tagOwners": {
    "tag:prod": ["group:platform"]
  },
  "nodeAttrs": [
    {
      "target": ["tag:prod"],
      "attr": ["auto-update"]
    }
  ],
  "acls": [
    {
      "action": "accept",
      "src": ["group:engineering"],
      "dst": ["tag:prod:*"]
    }
  ]
}

Atribut auto-update di nodeAttrs membuat semua node bertag tag:prod memperbarui diri ke rilis stabil terbaru secara otomatis — kebijakan yang hidup di satu tempat, berlaku untuk seluruh fleet.

#Checklist Production

#ACL yang Ketat

Mulai dari deny-by-default. Setiap akses harus eksplisit: user hanya boleh menjangkau node dan port yang dibutuhkan. Gunakan tag untuk memisahkan environment dev, staging, dan prod, lalu batasi siapa yang boleh me-own tag tersebut lewat tagOwners.

#Tailnet Lock dan Audit Log

Aktifkan Tailnet Lock (episode 13) agar perubahan besar memerlukan persetujuan tanda tangan, dan manfaatkan audit log untuk mencatat siapa melakukan apa. Di admin console, biasakan meninjau audit log secara berkala — bukan saat insiden terjadi.

#Backup Konfigurasi

Konfigurasi tailnet — terutama file ACL — harus masuk version control. Gunakan Terraform Provider atau Tailscale API untuk menarik dan mendorong konfigurasi secara declarative:

resource "tailscale_acl" "tailnet" {
  acl = file("acl.json")
}

Blok Terraform di atas menjadikan acl.json sebagai sumber kebenaran. Perubahan ACL hanya lewat pull request, dan selalu ada riwayat yang bisa di-revert.

#Runbook Pemecahan Masalah

Dokumentasikan langkah-langkah untuk skenario yang paling sering terjadi: node tidak bisa direct connection, DNS tidak resolve, perangkat tidak muncul di admin console, dan key expiry. Sertakan perintah diagnostik dari episode 18. Runbook yang bagus membuat on-call tidak bergantung pada satu orang.

#Penutup

Episode 21 mengubah tailnet dari kumpulan perangkat menjadi sistem yang terkelola: provisioning otomatis, kebijakan terpusat, dan checklist yang siap diaudit.

Inti yang harus dibawa pulang:

• Auth keys one-shot dan ephemeral untuk provisioning massal.
• OAuth lebih aman daripada auth key statis.
• MDM mendistribusikan kebijakan sebelum user login.
• Kebijakan auto-update bisa dipaksakan lewat nodeAttrs.
• ACL yang ketat dengan tag dan tagOwners adalah fondasi.
• Terraform atau API menjaga konfigurasi tetap ter-backup.

Di episode 22, episode terakhir series, kita akan membahas ekosistem alternatif dan refleksi akhir — perbandingan jujur antara Tailscale, ZeroTier, Nebula, Netmaker, dan WireGuard manual, rekap perjalanan dari episode 0 hingga 21, serta checklist arsitektur tailnet production-grade untuk masa depan secure networking.