Belajar Tailscale - Authentication & SSO

#Pendahuluan

Di episode 12 kalian memahami lapisan enkripsi. Tapi sebelum enkripsi berbicara, ada pertanyaan yang harus dijawab: siapa perangkat dan siapa orang yang bergabung ke tailnet? Inilah lapisan identitas — dan jawabannya datang dari authentication dan SSO.

Episode 13 membahas cara tailnet memverifikasi identitas: login via Google, GitHub, Microsoft, atau Okta dengan multi-factor authentication, penggunaan auth keys untuk provisioning otomatis tanpa interaksi manusia, API keys untuk integrasi, dan Tailnet Lock untuk melindungi tailnet bahkan jika admin dikompromi.

#Autentikasi Identitas

#SSO di Pintu Masuk

Saat pertama tailscale up, kalian diarahkan ke halaman login provider pilihan — ini Single Sign-On (SSO). Identitas manusia datang dari identity provider perusahaan atau pribadi, bukan dari database Tailscale sendiri:

• Google: akun personal atau Google Workspace.
• GitHub: akun developer.
• Microsoft: akun Microsoft dan Entra ID.
• Okta: platform perusahaan untuk organisasi besar.

tailscale login

Perintah tailscale login membuka kembali alur autentikasi, berguna saat kalian ingin berpindah provider atau menyambungkan kembali node yang kadaluarsa.

#Multi-Factor Authentication

MFA berjalan di level identity provider: jika Google atau Okta kalian mengaktifkan MFA, login Tailscale otomatis memakainya. Ini berarti satu lapisan keamanan ekstra tanpa konfigurasi tambahan di tailnet. Untuk organisasi, wajibkan MFA di kebijakan provider untuk melindungi akses tailnet dari akun yang bocor.

#Keys dan Tokens

#Auth Keys untuk Provisioning Otomatis

Untuk server cloud, container, dan perangkat headless, tidak ada browser untuk login. Solusinya auth keys — key sekali pakai yang di-generate di admin console:

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

Auth key bisa dibuat one-shot (habis satu kali pakai) atau ephemeral (node dihapus otomatis saat down). Perintah sudo tailscale up --auth-key=... memungkinkan provisioning tanpa interaksi manusia — pola penting untuk episode 17 dan 21.

#API Keys untuk Integrasi

API key dipakai untuk memanggil Tailscale API — mengelola devices, ACL, dan konfigurasi dari kode. Bedanya dengan auth key: API key adalah kredensial admin untuk API, bukan untuk login node:

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

Perintah curl -s ... -H "Authorization: Bearer ..." mengambil daftar perangkat lewat API. API keys harus disimpan aman dan diberi masa berlaku — jangan pernah commit ke repository.

#Tailnet Lock: Kunci Hardware

Tailnet Lock (bernama Tailnet Lock) menambahkan persetujuan tanda tangan: perubahan signifikan pada tailnet — seperti menambahkan node baru — memerlukan tanda tangan dari sejumlah key yang ditunjuk. Bahkan jika kredensial admin diretas, penyerang tetap tidak bisa menambahkan node tanpa key yang memenuhi ambang:

sudo tailscale lock init
sudo tailscale lock sign

Perintah sudo tailscale lock init mengaktifkan lock dan menampilkan key kalian. tailscale lock sign menandatangani operasi yang sedang menunggu. Tailnet Lock adalah pertahanan terakhir yang kuat untuk tailnet production.

#Praktik Autentikasi yang Sehat

#Checklist Lapisan Identitas

• Aktifkan MFA di identity provider.
• Gunakan auth keys one-shot atau ephemeral untuk provisioning.
• Batasi masa berlaku auth keys dan API keys.
• Aktifkan Tailnet Lock untuk tailnet dengan banyak admin.
• Monitor log login dan perangkat di admin console.

Manusia   -> SSO (Google/GitHub/Microsoft/Okta) + MFA
Perangkat -> auth keys (one-shot/ephemeral)
Integrasi -> API keys / OAuth
Pertahanan-> Tailnet Lock (persetujuan tanda tangan)

#Alur Autentikasi yang Benar

#Urutan Provisioning yang Teruji

1. Buat auth key one-shot dengan masa berlaku pendek
2. Provision node dengan auth key
3. Verifikasi node muncul di admin console
4. Login manual untuk workstation dengan SSO
5. Rotasi auth key setelah provisioning selesai

Urutan ini memastikan tidak ada auth key yang menganggur terlalu lama. Untuk workstation, biarkan alur SSO berjalan — interaksi manusia justru memastikan pemilik perangkat bisa dikenali.

#Autentikasi Adalah Proses, Bukan Status

Identitas tailnet bukan sesuatu yang dikonfigurasi sekali lalu dilupakan. Key expiry memaksa node me-reauthenticate secara berkala, dan Tailnet Lock menjaga perubahan tetap terkontrol. Memperlakukan identitas sebagai proses berkelanjutan adalah kunci keamanan jangka panjang.

#Ringkasan

Autentikasi adalah gerbang yang menjaga lapisan enkripsi tetap bermakna. Dengan SSO plus MFA untuk manusia, auth keys untuk perangkat otomatis, API keys untuk integrasi, dan Tailnet Lock sebagai jaring pengaman, tailnet kalian punya lapisan identitas yang lengkap.

#Penutup

Episode 13 melengkapi lapisan pertama model keamanan: identitas. Kalian memahami alur SSO dan MFA, provisioning dengan auth keys, integrasi API keys, dan perlindungan ekstra dari Tailnet Lock.

Inti yang harus dibawa pulang:

• Identitas manusia datang dari SSO: Google, GitHub, Microsoft, atau Okta.
• MFA otomatis mengikuti kebijakan identity provider.
• Auth keys memungkinkan provisioning tanpa browser.
• API keys adalah kredensial untuk mengelola tailnet via API.
• Tailnet Lock memerlukan persetujuan tanda tangan untuk perubahan besar.
• Lapisan identitas adalah gerbang sebelum enkripsi berbicara.

Di episode 14 selanjutnya kita akan membahas security hardening dan ACL lanjutan — aturan ACL granular per node dan per user, kebijakan berbasis tag dengan least privilege, plus checklist hardening seperti key expiry, monitoring devices, pembatasan Taildrop dan SSH, serta pengamanan node server publik.