Hardening container auth bukan hanya soal menambah middleware keamanan atau menutup port. Untuk layanan autentikasi, ukuran image, jumlah paket yang terpasang, cara secret diberikan ke container, dan privilege saat proses berjalan langsung memengaruhi attack surface. Semakin banyak komponen yang ikut masuk ke image, semakin besar peluang ada paket rentan, tool yang bisa disalahgunakan, atau file sensitif yang tertinggal di layer build.

Pendekatan yang praktis adalah memakai image minimal, membatasi hak akses proses, dan memastikan secret bersifat ephemeral—disuntikkan saat runtime, bukan dibakar ke image atau tersimpan permanen di repositori. Ini sejalan dengan prinsip yang juga terlihat pada upaya optimasi ukuran sistem seperti NixOS ISO: komponen yang tidak dibutuhkan sebaiknya tidak ikut dibawa. Di konteks auth service, dampaknya bukan hanya ukuran image lebih kecil, tetapi juga permukaan serangan yang lebih sempit dan proses audit yang lebih sederhana.

Mengapa image minimal relevan untuk layanan auth

Layanan auth biasanya memegang aset paling sensitif di sistem: kredensial, token signing key, session state, recovery flow, dan kadang koneksi ke identity provider. Jika sebuah container auth dikompromikan, dampaknya bisa meluas ke seluruh platform. Karena itu, mengurangi komponen di image adalah kontrol keamanan yang masuk akal dan murah secara operasional.

Hubungan ukuran image, komponen terpasang, dan risiko keamanan

  • Lebih banyak paket = lebih banyak CVE potensial. Package manager, shell interaktif, compiler, curl, wget, git, dan utilitas debug sering tidak dibutuhkan di runtime tetapi memperluas permukaan serangan.
  • Lebih banyak file = lebih sulit diaudit. Sulit memastikan tidak ada sertifikat uji coba, file konfigurasi lama, atau credential yang tertinggal di layer.
  • Lebih banyak tool = lebih mudah untuk post-exploitation. Penyerang yang berhasil mengeksekusi perintah akan terbantu jika image menyediakan shell, downloader, atau utilitas jaringan.
  • Image besar memperlambat distribusi patch. Pull lebih lama, rollout patch lebih berat, dan tim cenderung menunda rebuild.

Namun image minimal bukan tujuan akhir. Jika aplikasi tetap berjalan sebagai root, filesystem bisa ditulis, secret ada di environment yang bocor ke log, dan endpoint login tidak dirate limit, maka image kecil saja tidak cukup. Hardening harus dilihat sebagai kombinasi kontrol build-time dan runtime.

Prinsip hardening untuk container auth

1. Gunakan base image minimal

Pilih base image yang hanya berisi runtime yang benar-benar diperlukan. Untuk aplikasi statically linked, pendekatan distroless atau scratch sering ideal. Untuk runtime yang masih butuh library sistem, gunakan image dasar yang ramping dan hindari varian penuh yang membawa banyak utilitas tambahan.

Kapan memilih apa?

  • Distroless/scratch: cocok bila aplikasi bisa berjalan tanpa shell dan tanpa kebutuhan debug di container.
  • Base image minimal umum: cocok bila Anda masih membutuhkan CA bundle, timezone data, atau dynamic library tertentu.

Trade-off: image yang terlalu minimal membuat debugging ad-hoc lebih sulit. Solusinya bukan menggemukkan image production, tetapi memakai ephemeral debug container atau observability yang baik dari luar container.

2. Terapkan multi-stage build

Jangan bawa compiler, dependency manager, dan file source yang tidak perlu ke runtime image. Build artifact di stage terpisah, lalu salin hanya binary atau hasil build final ke image runtime.

3. Jalankan proses sebagai non-root

Root di dalam container tetap berbahaya, terutama jika ada salah konfigurasi kernel capability, mount host, atau bug runtime. User non-root membatasi dampak ketika proses berhasil dieksploitasi.

4. Aktifkan read-only filesystem

Banyak layanan auth tidak perlu menulis ke disk lokal selain direktori sementara. Filesystem read-only membantu mencegah penulisan payload, web shell, atau perubahan file runtime yang tidak sah. Jika aplikasi butuh temp file, mount tmpfs untuk path tertentu seperti /tmp.

5. Drop Linux capabilities

Secara default, container bisa memiliki capability yang tidak dibutuhkan aplikasi auth. Hapus semuanya dan tambahkan hanya jika benar-benar perlu. Layanan HTTP biasa umumnya tidak perlu capability istimewa.

6. Jangan menyimpan secret di image

Secret yang dimasukkan lewat ENV di Dockerfile, file .env yang tercopy ke image, atau argumen build yang bocor ke layer adalah kesalahan umum. Secret harus diberikan saat runtime dari secret manager, orchestration secret, atau file mount sementara.

7. Validasi input dan batasi abuse

Auth service adalah target utama brute force, credential stuffing, abuse pada endpoint reset password, dan upload berbahaya bila ada fitur avatar atau dokumen verifikasi. Hardening container harus dibarengi kontrol di level aplikasi dan API gateway.

Contoh Dockerfile: multi-stage, non-root, runtime minimal

Contoh berikut bersifat generik untuk service auth yang menghasilkan binary tunggal. Polanya tetap relevan walau tool build Anda berbeda.

FROM golang:1.22 AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o /out/auth-service ./cmd/auth

FROM gcr.io/distroless/static-debian12
WORKDIR /app
COPY --from=build /out/auth-service /app/auth-service
USER 10001:10001
EXPOSE 8080
ENTRYPOINT ["/app/auth-service"]

Kenapa pola ini lebih aman?

  • Tool build seperti compiler dan dependency cache tidak ikut ke image final.
  • Tidak ada shell atau package manager di runtime image, sehingga peluang penyalahgunaan menurun.
  • Proses berjalan sebagai user non-root.

Jika aplikasi Anda membutuhkan sertifikat CA atau file statis tertentu, salin hanya file yang memang diperlukan dari stage build atau base image lain. Hindari menyalin direktori sistem secara membabi buta.

Paket dan komponen yang umumnya wajib dihapus dari runtime

  • Compiler dan build toolchain
  • Package manager dan cache paket
  • Shell interaktif jika tidak dibutuhkan
  • curl, wget, git, ssh client di image production
  • Editor teks, tool diagnostik, dan utility jaringan yang tidak diperlukan
  • Source code, file test, fixture, dan dokumentasi internal
  • File .env, private key lokal, credential cloud, atau token CI

Kesalahan umum adalah menghapus file sensitif di langkah build terakhir. Di Docker, file yang pernah masuk ke layer sebelumnya tetap bisa tertinggal dalam histori layer. Lebih aman mencegah file itu masuk sejak awal dengan .dockerignore dan multi-stage build.

Contoh runtime hardening di Docker Compose dan Kubernetes

Docker Compose

services:
  auth:
    image: registry.example.com/auth-service:latest
    ports:
      - "8080:8080"
    user: "10001:10001"
    read_only: true
    tmpfs:
      - /tmp:size=16m,noexec,nosuid
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    environment:
      - SESSION_STORE_URL=redis://redis:6379/0
      - SECRET_FILE=/run/secrets/jwt_signing_key
    secrets:
      - jwt_signing_key
    depends_on:
      - redis

secrets:
  jwt_signing_key:
    file: ./secrets/jwt_signing_key.txt

Catatan penting:

  • Untuk production, file secret lokal seperti di atas sebaiknya diganti dengan integrasi secret manager atau fitur secret bawaan platform.
  • SECRET_FILE lebih baik daripada menaruh nilai secret langsung di environment variable, karena environment lebih mudah terekspos lewat dump proses, tooling, atau salah log.

Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: auth-service
spec:
  replicas: 2
  selector:
    matchLabels:
      app: auth-service
  template:
    metadata:
      labels:
        app: auth-service
    spec:
      containers:
        - name: auth
          image: registry.example.com/auth-service:latest
          ports:
            - containerPort: 8080
          securityContext:
            runAsNonRoot: true
            runAsUser: 10001
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop: ["ALL"]
          env:
            - name: SECRET_FILE
              value: /var/run/secrets/auth/jwt_signing_key
          volumeMounts:
            - name: auth-secret
              mountPath: /var/run/secrets/auth
              readOnly: true
            - name: tmp
              mountPath: /tmp
      volumes:
        - name: auth-secret
          secret:
            secretName: auth-service-secret
        - name: tmp
          emptyDir:
            medium: Memory

Jika platform mendukung, pertimbangkan integrasi dengan external secret manager agar rotasi secret tidak bergantung pada commit manifest baru.

Secret ephemeral: pola yang lebih aman untuk layanan auth

Secret ephemeral berarti secret tidak dipermanenkan di image dan idealnya tidak hidup lebih lama dari yang dibutuhkan proses. Praktiknya bisa berupa:

  • Secret di-mount sebagai file sementara saat container start.
  • Secret diambil dari secret manager dengan identitas workload.
  • Token akses ke secret manager memiliki masa hidup pendek.
  • Rotasi dilakukan tanpa rebuild image.

Mengapa ini bekerja

  • Jika image bocor, secret tidak ikut bocor.
  • Jika registry disusupi, penyerang tidak otomatis mendapat credential runtime.
  • Rotasi lebih mudah karena tidak perlu membangun ulang image hanya untuk mengganti key.

Pola implementasi yang disarankan

  1. Jangan commit secret ke repositori. Tambahkan file sensitif ke .gitignore dan .dockerignore.
  2. Jangan pakai build args untuk secret runtime. Build args bisa terekspos di metadata build atau cache.
  3. Prefer file mount atau secret manager. Banyak library dapat membaca secret dari path file.
  4. Dukung reload atau rollout terkontrol saat rotasi. Untuk signing key atau encryption key, definisikan mekanisme pergantian yang mendukung masa transisi.

Rotasi secret untuk JWT, session, dan kredensial backend

  • JWT signing key: dukung minimal dua key aktif selama masa transisi—satu untuk sign baru, satu atau lebih untuk verifikasi token lama sampai habis TTL-nya.
  • Session store credential: siapkan prosedur rotasi password Redis atau database dengan deployment bertahap dan health check ketat.
  • API key ke provider eksternal: gunakan key dengan scope sempit dan masa aktif pendek bila provider mendukung.

Kesalahan umum: mengganti signing key secara mendadak tanpa fase verifikasi ganda, lalu seluruh session atau token aktif menjadi invalid sekaligus.

Checklist implementasi hardening container auth

Checklist build dan image

  • Gunakan base image minimal.
  • Terapkan multi-stage build.
  • Gunakan .dockerignore untuk mencegah file sensitif ikut ke context build.
  • Jangan masukkan shell, compiler, package manager, atau utility download ke runtime jika tidak perlu.
  • Pin dependency aplikasi secara konsisten agar rebuild dapat direproduksi.
  • Scan image di CI sebelum publish.

Checklist runtime container

  • Jalankan sebagai non-root.
  • Aktifkan readOnlyRootFilesystem atau padanannya.
  • cap_drop: ALL dan cegah privilege escalation.
  • Mount /tmp sebagai tmpfs bila perlu.
  • Batasi network egress bila arsitektur memungkinkan.
  • Pastikan log tidak mencetak secret, token, atau header sensitif.

Checklist aplikasi auth

  • Validasi semua input secara ketat, termasuk email, password reset token, redirect URL, dan header.
  • Terapkan rate limiting pada login, OTP, password reset, dan endpoint verifikasi.
  • Gunakan lockout atau backoff yang tidak mudah disalahgunakan untuk denial-of-service.
  • Audit upload jika ada fitur avatar, dokumen KYC, atau import file.
  • Pastikan session store punya TTL, enkripsi bila perlu, dan mekanisme invalidasi yang jelas.
  • Catat event keamanan penting: login gagal beruntun, reset password, rotasi key, dan anomali session.

Checklist secret dan session

  • Secret disuntikkan saat runtime, bukan dibangun ke image.
  • Gunakan secret manager atau mount file secret read-only.
  • Terapkan rotasi periodik dengan prosedur rollback.
  • Audit siapa yang dapat mengakses secret, dari workload mana, dan lewat policy apa.
  • Periksa session store untuk session orphan, TTL yang salah, dan data yang terlalu sensitif di payload.

Proteksi penting di level aplikasi auth

Validasi input

Container yang hardened tidak mencegah bug logika. Untuk auth service, validasi input harus mencegah:

  • Format email atau username yang tidak wajar
  • Password reset token yang terlalu panjang atau karakter anomali
  • Redirect URL berbahaya pada login flow
  • Payload JSON besar untuk memicu memory pressure
  • Header yang bisa memanipulasi proxy trust atau IP parsing

Prinsipnya: tolak input sedini mungkin, batasi ukuran body, dan gunakan parser yang ketat.

Rate limiting login dan endpoint sensitif

Rate limit sebaiknya tidak hanya berdasarkan IP. Di banyak sistem, brute force datang dari banyak IP dengan satu username, atau satu IP menyerang banyak akun. Kombinasikan beberapa dimensi:

  • IP address
  • Username/email
  • Device fingerprint atau client identifier bila relevan
  • Endpoint sensitif seperti login, refresh token, OTP verify, password reset

Tambahkan observasi terhadap pola credential stuffing: banyak akun gagal dari sumber berbeda dalam waktu singkat. Ini biasanya butuh agregasi di level gateway, WAF, atau sistem deteksi terpisah.

Proteksi upload bila ada

Jika auth service menangani upload avatar, dokumen identitas, atau lampiran verifikasi, perlakukan upload sebagai jalur risiko tinggi:

  • Batasi ukuran file dan tipe MIME.
  • Verifikasi konten file, jangan percaya nama file atau header klien.
  • Simpan di object storage, bukan filesystem container.
  • Jangan pernah mengeksekusi atau mengekspose file langsung dari path upload mentah.
  • Pertimbangkan scanning malware di pipeline terpisah bila use case menuntut.

Audit session store

Session store sering luput diaudit karena dianggap sekadar cache. Padahal untuk auth, isi session bisa menentukan identitas user, CSRF state, refresh token reference, atau status MFA.

Periksa hal berikut:

  • Apakah session memiliki TTL yang sesuai?
  • Apakah session lama dibersihkan?
  • Apakah payload session memuat data sensitif berlebihan?
  • Apakah logout benar-benar menginvalidasi session atau refresh token?
  • Apakah ada proteksi terhadap session fixation dan replay?

Verifikasi: scanning image dan pengujian abuse

Scanning image

Setelah image dibuat, lakukan scanning kerentanan sebagai bagian dari CI/CD. Banyak tool scanner dapat memeriksa package OS, dependency aplikasi, dan konfigurasi image. Apa yang perlu diperhatikan:

  • Temuan kritis yang benar-benar diekspos di runtime. Prioritaskan paket yang ada di image final, bukan hanya di stage build.
  • Komponen tak terpakai. Jika scanner menemukan paket yang tidak diperlukan, itu sinyal image masih terlalu gemuk.
  • Base image usang. Rebuild berkala penting bahkan saat kode aplikasi tidak berubah.

Selain scanner kerentanan, periksa juga isi image secara manual: file apa yang ada, user apa yang dipakai, apakah shell tersedia, dan apakah secret tak sengaja ikut terbawa.

Pengujian abuse yang relevan untuk auth

Hardening baru bermakna jika perilakunya diuji. Lakukan pengujian berikut di lingkungan staging:

  1. Brute force login: kirim percobaan login gagal bertubi-tubi dan pastikan rate limit bekerja tanpa merusak user sah.
  2. Password reset abuse: uji enumerasi akun melalui perbedaan respons atau timing.
  3. Body size abuse: kirim payload besar ke endpoint login atau verifikasi untuk memastikan limit request aktif.
  4. Header spoofing: uji header proxy seperti X-Forwarded-For bila aplikasi berada di belakang reverse proxy.
  5. Upload abuse: jika ada upload, uji file dengan ekstensi menipu, MIME tidak cocok, atau ukuran berlebih.
  6. Secret handling: pastikan secret tidak muncul di log startup, endpoint debug, atau stack trace.

Debugging tip saat hardening menyebabkan aplikasi gagal jalan

  • Jika container crash setelah mengaktifkan read-only filesystem, cek apakah aplikasi mencoba menulis file pid, cache, atau temp file ke path root.
  • Jika non-root gagal bind port rendah, pindahkan aplikasi ke port tinggi seperti 8080 dan biarkan proxy atau service mesh yang mengekspos port standar.
  • Jika secret file tidak terbaca, cek owner, permission, dan path mount sebenarnya di runtime.
  • Jika rate limit terasa memblokir trafik sah, audit dimensi key yang dipakai dan periksa integrasi dengan proxy agar IP klien terbaca benar.

Urutan implementasi yang realistis untuk tim backend

Jika ingin menerapkannya tanpa mengganggu delivery terlalu besar, lakukan bertahap:

  1. Mulai dari multi-stage build dan base image minimal.
  2. Aktifkan non-root user, drop capabilities, dan no-new-privileges.
  3. Ubah secret menjadi runtime injection lewat file mount atau secret manager.
  4. Terapkan read-only filesystem dan rapikan kebutuhan path tulis ke /tmp atau volume khusus.
  5. Tambahkan scan image di CI serta policy gagal build untuk temuan tertentu.
  6. Perkuat rate limiting, validasi input, dan audit session store.
  7. Lakukan abuse test berkala pada endpoint auth yang paling sensitif.

Dengan urutan ini, tim backend bisa memperoleh peningkatan keamanan nyata tanpa harus menunggu redesign besar. Intinya sederhana: untuk layanan autentikasi berbasis container, bawa komponen sesedikit mungkin, beri hak akses seminimal mungkin, dan perlakukan secret sebagai data runtime yang sementara. Itulah fondasi hardening container auth yang praktis dan bisa diaudit.