Belajar Envoy Proxy - Secure Service-to-Service Communication

#Pendahuluan

Setelah mengamankan jalur transport di episode 6, kini saatnya mengamankan siapa yang boleh bicara. Episode 12 membahas secure service-to-service communication: Envoy sebagai gateway tepercaya bagi microservices, TLS context dan certificate validation, serta filter RBAC Envoy untuk kebijakan otorisasi. Di akhir episode ini, kalian punya pola keamanan dasar: enkripsi di lapisan transport, identitas terverifikasi, dan otorisasi berbasis role yang bisa diperluas.

#Envoy sebagai Gateway Aman Microservices

#Pola Gateway per Service

Dalam arsitektur service mesh, setiap service berkomunikasi lewat Envoy di depannya. Envoy bertindak sebagai gateway aman: semua traffic masuk dan keluar harus melewatinya, sehingga kebijakan keamanan diterapkan di satu titik.

Pola sidecar Envoy untuk satu service

listeners:
  - name: sidecar_inbound
    address:
      socket_address:
        address: 0.0.0.0
        port_value: 15006
    filter_chains:
      - transport_socket:
          name: envoy.transport_sockets.tls
          typed_config:
            "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
            require_client_certificate: true
            common_tls_context:
              tls_certificates:
                - certificate_chain:
                    filename: /etc/envoy/certs/service.pem
                  private_key:
                    filename: /etc/envoy/certs/service-key.pem
              validation_context:
                trusted_ca:
                  filename: /etc/envoy/certs/ca.pem
        filters:
          - name: envoy.filters.network.http_connection_manager
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
              stat_prefix: service_ingress
              route_config:
                name: service_routes
                virtual_hosts:
                  - name: service_vh
                    domains:
                      - "*"
                    routes:
                      - match:
                          prefix: "/"
                        route:
                          cluster: local_service
              http_filters:
                - name: envoy.filters.http.router
                  typed_config:
                    "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router

Konfigurasi require_client_certificate: true memaksa setiap klien menunjukkan sertifikat saat berbicara dengan service ini. Traffic tanpa sertifikat yang valid ditolak sebelum mencapai aplikasi.

Dengan pola ini, keamanan tidak bergantung pada disiplin setiap developer. Kebijakan di satu config Envoy berlaku untuk semua traffic — alasan utama service mesh menempelkan sidecar ke setiap pod.

#TLS Context dan Certificate Validation

#Memverifikasi Identitas Upstream

Saat Envoy berbicara ke service lain, dia memverifikasi sertifikat lawan:

Transport socket dengan verifikasi SAN

clusters:
  - name: orders_service
    connect_timeout: 0.25s
    type: STRICT_DNS
    lb_policy: ROUND_ROBIN
    transport_socket:
      name: envoy.transport_sockets.tls
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
        common_tls_context:
          validation_context:
            trusted_ca:
              filename: /etc/envoy/certs/ca.pem
            match_subject_alt_names:
              - exact: orders.internal
            match_typed_subject_alt_names:
              - san_type: URI
                matcher:
                  exact: spiffe://example.org/ns/prod/sa/orders
    load_assignment:
      cluster_name: orders_service
      endpoints:
        - lb_endpoints:
            - endpoint:
                address:
                  socket_address:
                    address: orders.internal
                    port_value: 8443

Bagian match_typed_subject_alt_names memperlihatkan pola SPIFFE — URI identitas standar di dunia service mesh. Verifikasi ini memastikan Envoy hanya berbicara dengan service orders di namespace prod.

#Certificate Validation sebagai Identitas

Pola terkuat memakai identitas dari SAN, bukan hanya memeriksa chain sertifikat. Dengan SPIFFE, identitas service ada di sertifikat itu sendiri, sehingga verifikasi TLS sekaligus menjadi verifikasi identitas.

#Authorization Policies dengan RBAC

#Filter RBAC di Envoy

RBAC (Role-Based Access Control) memungkinkan Envoy menegakkan kebijakan akses berbasis atribut:

Filter RBAC untuk service

http_filters:
  - name: envoy.filters.http.rbac
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBAC
      rules:
        action: ALLOW
        policies:
          admin_policy:
            permissions:
              - header:
                  name: ":method"
                  string_match:
                    exact: GET
            principals:
              - authenticated:
                  principal_name:
                    exact: spiffe://example.org/ns/prod/sa/admin
  - name: envoy.filters.http.router
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router

Filter rbac dengan action ALLOW menolak semua request yang tidak cocok. Policy admin_policy mengizinkan hanya request GET dari principal SPIFFE admin; sisanya otomatis menerima 403.

#RBAC di Level Network

Untuk proteksi di lapisan koneksi sebelum HTTP diproses:

RBAC pada filter network

filters:
  - name: envoy.filters.network.rbac
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.filters.network.rbac.v3.RBAC
      rules:
        action: ALLOW
        policies:
          internal_only:
            permissions:
              - destination_port: 8443
            principals:
              - authenticated:
                  principal_name:
                    exact: spiffe://example.org/ns/prod/sa/*

Konfigurasi network.rbac menolak koneksi TCP dari principal yang tidak dikenal bahkan sebelum request HTTP terbentuk. Ini lapisan pertahanan pertama yang murah.

#Menguji Kebijakan Otorisasi

Uji akses dengan dan tanpa sertifikat

curl -s -o /dev/null -w "%{http_code}\n" \
  --cert ~/envoy-lab/certs/client.pem --key ~/envoy-lab/certs/client-key.pem \
  --cacert ~/envoy-lab/certs/ca.pem https://localhost:10443/orders
curl -s -o /dev/null -w "%{http_code}\n" \
  --cacert ~/envoy-lab/certs/ca.pem https://localhost:10443/orders

Request tanpa sertifikat klien seharusnya gagal di lapisan TLS, sementara request pertama dievaluasi filter RBAC. Perintah curl -w "%{http_code}" menampilkan hanya kode status — cara bersih menguji kebijakan.

#Memantau Keputusan Otorisasi

#Statistik RBAC

Envoy mencatat keputusan RBAC dalam metric:

Lihat counter RBAC

curl -s localhost:9901/stats | grep "rbac"

Statistik rbac menunjukkan berapa request diizinkan dan ditolak per listener. Jika penolakan naik mendadak, kemungkinan ada service yang identitasnya tidak cocok — periksa principal di match_typed_subject_alt_names.

Saat menyusun policy baru, aktifkan logging keputusan lebih dulu. Envoy mendukung shadow_rules yang mencatat keputusan tanpa benar-benar menolak request — sempurna menguji policy di production tanpa risiko.

#Penutup

Episode 12 menyusun lapisan keamanan service-to-service: Envoy sebagai gerbang tepercaya tiap service, TLS context dengan verifikasi SAN dan SPIFFE, serta filter RBAC yang menegakkan kebijakan akses.

Inti yang harus dibawa pulang:

Setiap service bisa dibungkus Envoy yang menjadi gerbang aman traffic.
require_client_certificate memaksa klien membuktikan identitas.
Verifikasi SAN, terutama pola SPIFFE, menjadikan TLS sebagai verifikasi identitas.
Filter RBAC dengan action ALLOW menolak semua yang tidak cocok policy.
RBAC bisa diterapkan di level HTTP maupun network.
Uji dengan curl memakai dan tanpa sertifikat klien untuk melihat perbedaan.

Di episode 13 selanjutnya kita akan membahas API gateway patterns dan edge proxy — Envoy sebagai edge proxy dan API gateway, virtual host dan rate limiting, autentikasi dan CORS, serta kapan memakai gateway dibanding sidecar internal.