Belajar Authentik - Kubernetes Deployment

#Pendahuluan

Di episode 23 kita membangun arsitektur high availability: beberapa instance Authentik di belakang load balancer, database yang direplikasi, dan Redis yang berfungsi sebagai cache serta message queue. Pertanyaan yang langsung muncul setelah itu adalah: bagaimana cara mengelola banyak instance tersebut secara konsisten, melakukan rolling update tanpa downtime, dan menegakkan konfigurasi yang sama di setiap node?

Jawabannya membawa kalian ke topik episode ini: Kubernetes. Jika Docker Compose seperti mengelola satu rumah — semua perabot disusun di file compose yang sama — maka Kubernetes seperti pengelola properti untuk satu kompleks apartemen: ia menangani penjadwalan penghuni ke unit yang tersedia, memastikan unit yang rusak segera diganti, dan menjaga aturan yang sama berlaku di seluruh kompleks. Episode ini akan memandu kalian mendeploy Authentik di cluster, memahami peran tiap komponen, dan menyiapkan outpost agar bisa hidup di dalam cluster.

#Mengapa Kubernetes Menjadi Pilihan Berikutnya

Authentik pada dasarnya terdiri dari dua workload yang saling bekerja sama:

• Server — melayani seluruh lalu lintas HTTP: UI admin, halaman login, flow executor, endpoint OAuth2/OIDC/SAML, dan API.
• Worker — menangani tugas latar belakang: pengiriman email, pemrosesan event, sinkronisasi blueprint, dan pengelolaan outpost.

Selain keduanya, Authentik bergantung pada PostgreSQL untuk semua data persisten dan Redis sebagai broker antrian tugas serta cache. Di Kubernetes, keempatnya menjadi objek yang dikelola secara deklaratif: kalian menulis inginnya seperti apa, dan kontrol plane yang mengejar ke kondisi itu. Server serta worker menjadi Deployment, database dan cache sebaiknya menjadi StatefulSet, dan akses dari luar masuk lewat Ingress.

Keuntungan yang kalian dapatkan: self-healing (pod mati diganti otomatis), scaling horizontal dengan HPA, rolling update dengan versi image baru, serta konfigurasi yang bisa direview seperti kode. Inilah alasan mengapa HA yang dibangun manual di episode 23 bisa didelegasikan ke platform.

#Helm Chart Resmi: Jalur Termudah

Tim Authentik memelihara Helm chart resmi di repositori goauthentik/authentik. Chart ini sudah menyediakan Deployment server dan worker, service, probes kesehatan bawaan, opsi ingress, sekaligus subchart PostgreSQL dan Redis dari Bitnami.

Tambah repository Helm AuthentikInstall Authentik dengan values.yaml

helm repo add authentik https://charts.goauthentik.io
helm repo update

helm upgrade --install authentik authentik/authentik \
  -n authentik --create-namespace \
  -f values.yaml

Chart menggunakan nilai dari values.yaml untuk merender seluruh objek Kubernetes. Berikut contoh minimal yang diambil dari dokumentasi resmi:

authentik:
  secret_key: "GantiDenganSecretAcakPanjangMinimal50Karakter"
  postgresql:
    password: "GantiDenganPasswordDatabase"
server:
  ingress:
    enabled: true
    ingressClassName: nginx
    hosts:
      - auth.example.com
postgresql:
  enabled: true
  auth:
    password: "GantiDenganPasswordDatabase"
redis:
  enabled: true

Saat instalasi pertama kali dijalankan, chart otomatis menerapkan migrasi skema database. Kalian bisa mengonfirmasi semua komponen berjalan dengan kubectl get pods -n authentik.

#Secret dan ConfigMap: Memisahkan yang Rahasia

Helm chart merender nilai values.yaml menjadi dua jenis objek: ConfigMap untuk nilai yang tidak sensitif (host database, nama database, level log) dan Secret untuk nilai rahasia (kunci database, AUTHENTIK_SECRET_KEY). Variabel-variabel inilah yang menjadi sumber konfigurasi server dan worker — mulai dari AUTHENTIK_POSTGRESQL__HOST, AUTHENTIK_REDIS__HOST, hingga AUTHENTIK_SECRET_KEY.

Aturan emasnya: jangan pernah menaruh nilai rahasia langsung di values.yaml yang ter-commit ke Git. Gunakan mekanisme seperti Helm --set saat deploy, existingSecret yang mengacu pada Secret yang sudah dibuat terpisah, atau integrasi dengan external secret operator (misalnya untuk HashiCorp Vault seperti yang dibahas di series secret management). Dengan begitu, rotasi kunci cukup mengganti satu Secret tanpa merender ulang seluruh chart.

authentik:
  existingSecret: authentik-secret

Secret tersebut cukup memuat key bernama authentik_secret_key. Nilai di dalamnya harus identik di semua instance server dan worker — jika salah satu pod menggunakan kunci berbeda, sesi dan token yang diterbitkan tidak akan bisa diverifikasi oleh pod lain.

#PostgreSQL dan Redis: Bundled vs Eksternal

Subchart PostgreSQL dan Redis yang diaktifkan lewat postgresql.enabled dan redis.enabled sangat membantu untuk percobaan. Namun dokumentasi resmi dengan tegas menyebutkan bahwa database bawaan chart ditujukan untuk environment demonstrasi dan pengujian.

Jika memakai database eksternal, cukup set postgresql.enabled: false dan arahkan authentik.postgresql.host ke alamat eksternal. Data tersimpan di StatefulSet dengan PersistentVolumeClaim — pastikan storageClass sesuai kebutuhan I/O dan pikirkan snapshot berkala di level storage.

#Ingress dan TLS

Satu-satunya pintu masuk dari luar adalah Ingress yang mengarah ke Service server. Inilah tempat yang tepat untuk mengakhiri TLS. Dengan cert-manager, sertifikat Let's Encrypt bisa diperbarui otomatis:

server:
  ingress:
    enabled: true
    ingressClassName: nginx
    hosts:
      - auth.example.com
    annotations:
      cert-manager.io/cluster-issuer: letsencrypt-prod
    tls:
      - hosts:
          - auth.example.com
        secretName: authentik-tls

Jangan biarkan AUTHENTIK_HOST dan AUTHENTIK_REDIRECT__... menyala di HTTP murni — redirect URI yang disimpan provider harus cocok persis dengan skema yang kalian pilih (episode 8). Sertifikat yang dikeluarkan bisa diperiksa lewat kubectl get certificates -n authentik.

#Outpost di Dalam Cluster

Outpost proxy dan LDAP yang kita bahas di episode 11 dan 18 juga bisa berjalan sebagai objek Kubernetes. Caranya: buat outpost bertipe Kubernetes, lalu siapkan service connection yang berisi URL API dan token. Dari situ Authentik mendeploy outpost sebagai Deployment + Service miliknya sendiri di dalam cluster, lengkap dengan mekanisme auto-update ketika outpost diberi pengaturan baru.

Outpost sebagai Deployment terpisah (ringkas)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: authentik-outpost-proxy
  namespace: authentik
spec:
  replicas: 2
  selector:
    matchLabels:
      app: authentik
      component: outpost-proxy
  template:
    metadata:
      labels:
        app: authentik
        component: outpost-proxy
    spec:
      containers:
        - name: outpost
          image: ghcr.io/goauthentik/proxy:2025.10
          ports:
            - containerPort: 9000
          envFrom:
            - secretRef:
                name: authentik-outpost-token

Outpost di dalam cluster memiliki keuntungan besar: rute antar aplikasi berjalan lewat DNS cluster internal yang stabil, dan health check /outpost.goauthentik.io/ping bisa dijadikan probe liveness. Pastikan token service connection disimpan sebagai Secret, karena token yang bocor berarti siapa pun bisa mengendalikan outpost milik kalian.

#Memahami Manifes: Membaca di Balik Chart

Untuk kepentingan belajar, ada baiknya kalian juga melihat bentuk mentah dari yang dihasilkan chart. Render semua template dengan helm template authentik authentik/authentik -f values.yaml lalu perhatikan Deployment server. Di dalamnya kalian akan menemukan pola yang sama dengan yang kita pelajari di episode 24 series Kubernetes: image Authentik yang sama untuk dua Deployment, args yang membedakan peran (server vs worker), probe /-/health/ready/ untuk readiness, dan envFrom yang menarik nilai dari ConfigMap dan Secret.

Dari sini tambahkan hal-hal yang menjadi ciri deployment produksi: resources.requests dan resources.limits untuk CPU serta memory, HorizontalPodAutoscaler yang menambah replica server ketika CPU naik, dan podAntiAffinity agar replica server tidak menumpuk di node yang sama — sehingga kehilangan satu node tidak mematikan seluruh Authentik.

#Penutup

Pada episode 24 ini kalian telah belajar mendeploy Authentik di Kubernetes melalui Helm chart resmi: memisahkan peran server dan worker, memahami bagaimana nilai konfigurasi dirangkai menjadi ConfigMap dan Secret, memilih antara PostgreSQL/Redis bawaan chart dengan yang eksternal, mengonfigurasi ingress beserta TLS, dan menempatkan outpost di dalam cluster. Kalian juga tahu bahwa value rahasia tidak pernah boleh masuk ke Git, dan bahwa probe kesehatan bawaan chart adalah fondasi dari keandalan di platform.

Inti yang harus kalian bawa:

• Server dan worker adalah dua Deployment dengan image yang sama, dibedakan lewat argumen peran.
• PostgreSQL dan Redis bawaan chart hanya untuk percobaan; produksi memakai yang dikelola terpisah.
• AUTHENTIK_SECRET_KEY dan kredensial database harus konsisten di semua pod dan disimpan sebagai Secret.
• Ingress adalah satu-satunya pintu masuk; TLS di-terminate di sini bersama cert-manager.
• Outpost Kubernetes dikelola lewat service connection dan token yang harus dijaga ketat.

Deployment yang sehat masih butuh mata yang mengawasi. Di episode 25 berikutnya kita akan membahas Monitoring & Performance: mengekspos metrik Prometheus di port khusus, memantau metrik kunci seperti keberhasilan dan kegagalan login serta latensi, mengatur level log, dan menyetel alerting agar kalian tahu lebih dulu sebelum pengguna mengeluh. Sampai jumpa di episode 25!