Belajar Quarkus - Secure Microservices & API Gateway

#Pendahuluan

Di episode 12 dan 13 kalian mengamankan satu aplikasi. Tapi sistem modern jarang berupa satu aplikasi — ia berupa banyak service kecil yang saling berbicara. Keamanan arsitektur microservices lebih kompleks dari sekadar melindungi satu endpoint.

Episode 14 membahas pola secure microservices dengan Quarkus: komunikasi antar service yang aman, integrasi dengan service mesh seperti Istio dan Envoy atau API gateway, mTLS untuk inter-service communication, serta rate limiting dan API policy.

#Pola Secure Microservices dengan Quarkus

#Arsitektur Referensi

Pola umum arsitektur microservices dengan keamanan berlapis:

• Edge gateway: satu titik masuk untuk seluruh request eksternal.
• Service mesh: lapisan jaringan yang mengatur komunikasi antar service.
• Identity provider: pusat autentikasi dan otorisasi (episode 13).
• Service internal: tidak terekspos langsung ke internet.

Setiap lapisan punya tanggung jawab keamanan berbeda. Gateway memvalidasi request publik, sedangkan komunikasi internal diamankan dengan mTLS dan token.

#Edge Service Pattern

Quarkus cocok sebagai edge service yang meneruskan request ke service internal:

Edge service meneruskan request

import jakarta.annotation.security.RolesAllowed;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.core.Response;
 
@Path("/api")
@RolesAllowed("user")
public class EdgeResource {
 
    @GET
    @Path("/orders")
    public Response orders() {
        return Response.ok()
            .header("X-Internal-Token", internalToken)
            .entity(panggilServiceOrder())
            .build();
    }
}

@RolesAllowed("user") di level edge memastikan hanya pengguna terautentikasi yang mencapai service internal. Service internal mempercayai token dari edge — bukan langsung dari client.

#Integration dengan Istio, Envoy, atau API Gateway

#Istio dan Envoy

Istio adalah service mesh yang menyuntikkan proxy Envoy di samping setiap pod. Envoy menangani keamanan jaringan: mTLS, autorisasi L7, dan observability — tanpa mengubah kode aplikasi.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: orders-policy
  namespace: backend
spec:
  selector:
    matchLabels:
      app: order-service
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/backend/sa/edge-service"]
    to:
    - operation:
        methods: ["GET"]

Policy ini hanya mengizinkan GET dari service account edge-service ke order-service. Istio memblokir request lain di level jaringan. Terapkan dengan kubectl apply -f orders-policy.yaml.

#API Gateway Tradisional

Alternatif tanpa service mesh adalah API gateway seperti Kong, Traefik, atau HAProxy. Gateway melakukan autentikasi, rate limiting, dan routing:

routes:
- name: order-api
  paths: ["/api/orders"]
  strip_path: true
  plugins:
  - name: key-auth
    config:
      key_names: ["apikey"]
  - name: rate-limiting
    config:
      minute: 60

Konfigurasi ini meminta API key dan membatasi 60 request per menit per client di level gateway — jauh sebelum request mencapai aplikasi Quarkus.

#Securing Inter-Service Communication

#mTLS (Mutual TLS)

mTLS memastikan kedua sisi komunikasi memverifikasi identitas satu sama lain. Service mesh mengelola ini otomatis dengan sertifikat per service. Tanpa service mesh, kalian bisa menggunakan REST client Quarkus dengan SSL konfigurasi:

quarkus.rest-client.order-service.url=https://order-service:8443
quarkus.rest-client.order-service.trust-store=keystore/truststore.p12
quarkus.rest-client.order-service.trust-store-password=${TRUSTSTORE_PASSWORD}
quarkus.rest-client.order-service.key-store=keystore/keystore.p12
quarkus.rest-client.order-service.key-store-password=${KEYSTORE_PASSWORD}

Dengan mTLS, setiap service mempresentasikan sertifikatnya sendiri. Kombinasi mTLS + JWT memberikan keamanan berlapis: identitas jaringan dan identitas bisnis.

#Token Antar Service

Selain mTLS, service-to-service memakai token. Pola service-to-service auth dengan client credentials (episode 13) memastikan service yang memanggil memiliki identitas yang bisa diverifikasi:

REST client dengan bearer token

import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import org.eclipse.microprofile.rest.client.inject.RegisterRestClient;
 
@Path("/internal")
@RegisterRestClient(configKey = "order-service")
public interface OrderServiceClient {
 
    @GET
    String pesan(String nama);
}

@RegisterRestClient membuat client REST yang mengirim request ke service lain. Token OIDC disuntikkan otomatis lewat interceptor, sehingga setiap panggilan antar service membawa identitas.

#Rate Limiting, Request Validation, dan API Policy

#Rate Limiting di Aplikasi

Selain di gateway, rate limiting bisa diimplementasikan di level aplikasi dengan extension atau pendekatan kustom: misalnya counter per client yang dicek sebelum request diproses. Di produksi, gunakan solusi terdistribusi seperti Redis untuk rate limiting yang konsisten di banyak instance.

#Request Validation di Edge

Validasi request di edge mengurangi beban service internal. Gunakan OpenAPI validator di gateway, atau validasi Jakarta Bean Validation di edge service (episode 7). Prinsipnya: tolak request buruk sedini mungkin.

#API Policy

API policy adalah kumpulan aturan yang diterapkan konsisten: autentikasi, rate limit, ukuran body maksimal, dan whitelist method:

quarkus.http.limits.max-body-size=1M

quarkus.http.limits.max-body-size=1M menolak request dengan body lebih dari 1MB — mencegah abuse lewat payload raksasa.

#Penutup

Episode 14 memperluas keamanan dari satu aplikasi ke seluruh arsitektur: memahami pola secure microservices dengan edge service, integrasi dengan Istio, Envoy, dan API gateway, securing inter-service communication dengan mTLS dan token, serta rate limiting dan API policy.

Inti yang harus dibawa pulang:

• Keamanan microservices berlapis: gateway, service mesh, dan service internal.
• Istio/Envoy menangani mTLS dan autorisasi di level jaringan.
• API gateway memusatkan autentikasi, rate limiting, dan routing.
• mTLS memverifikasi identitas kedua sisi komunikasi.
• REST client Quarkus bisa dikonfigurasi dengan truststore dan keystore.
• Rate limiting bisa di level gateway atau aplikasi.
• quarkus.http.limits.max-body-size membatasi ukuran payload.

Di episode 15 selanjutnya kita akan membahas reactive programming dan Vert.x — reactive stack dengan Vert.x di Quarkus, konsep Uni dan Multi, reactive messaging dengan Kafka, AMQP, atau MQTT, serta kapan memakai reactive dibandingkan imperative.