Belajar Application Security Engineer - AppSec in Cloud-Native

#Pendahuluan

Setelah di episode 14 kita merancang strategi testing menyeluruh, episode ini menyesuaikannya dengan realitas arsitektur modern: cloud-native — serverless functions, container orchestration Kubernetes, dan microservices. Mengapa butuh perlakuan khusus? Kategori bug-nya sama (injection tetap injection), tapi model tanggung jawab, permukaan serangan, dan kontrol yang tersedia berubah drastis. Di serverless, kalian tidak mengelola OS; di Kubernetes, kalian bisa salah konfigurasi ratusan cara baru.

Tiga wilayah kita bahas: serverless security, aplikasi di Kubernetes, dan deteksi runtime.

#Serverless Security

Function-as-a-Service (Lambda, Cloud Functions, Workers) memindahkan sebagian besar beban ke provider — patching OS, isolation host. Yang tersisa untuk kalian adalah persimpangan tempat mayoritas insiden serverless terjadi:

1. IAM per-function (least privilege). Kesalahan nomor satu: satu role superuser untuk semua function. Function yang hanya membaca tabel orders tidak boleh punya izin write ke bucket PII:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["dynamodb:GetItem", "dynamodb:Query"],
    "Resource": "arn:aws:dynamodb:ap-southeast-1:123:table/orders"
  }]
}

Saat function dikompromi via injection, dampaknya terkurung dalam izin segitu. Inilah bentuk paling murni dari blast radius control.

2. Event data = untrusted input. Payload event (HTTP body, S3 metadata, message queue) adalah source taint seperti req.body — jalankan validasi yang sama. Injection serverless favorit: event attribute yang akhirnya masuk ke command atau query downstream.

3. Secrets & state. Jangan bakar secret ke environment variable build; pakai secrets manager dengan akses IAM. Dan ingat: instance function ephemeral tapi /tmp reuse antar invocation mungkin — data sementara bisa bocor ke request user lain jika tidak dibersihkan.

#Kubernetes Application Security

Di K8s, kalian bertanggung jawab pada layer workload. Tiga manifest berikut menutup 80% risiko aplikasi-level:

#SecurityContext: Identitas & Isolasi Pod

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  template:
    spec:
      automountServiceAccountToken: false
      containers:
        - name: api
          image: registry.example.com/api@sha256:9f86... # pin digest
          securityContext:
            runAsNonRoot: true
            runAsUser: 10001
            readOnlyRootFilesystem: true
            allowPrivilegeEscalation: false
            capabilities:
              drop: ["ALL"]

Padanan langsung guard runtime episode 10, kini ditegakkan scheduler: pod tidak akan jalan bila image minta root — kontrol bergeser dari "harapan" ke "jaminan". automountServiceAccountToken: false penting: tanpa itu, pod membawa token API Kubernetes yang bisa dipakai menyerang cluster dari dalam.

#NetworkPolicy: Segmentasi Lapis Aplikasi

Default Kubernetes: semua pod boleh bicara ke semua pod. NetworkPolicy membalik defaultnya menjadi deny-all lalu izinkan eksplisit:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-default-deny
spec:
  podSelector:
    matchLabels: { app: api }
  policyTypes: [Ingress]
  ingress:
    - from:
        - podSelector:
            matchLabels: { app: gateway }
      ports:
        - port: 3000

Dengan ini, SSRF dari service lain tidak lagi sampai ke database pod secara langsung — defense in depth nyata pada layer network.

#Admission Control: Kebijakan Cluster-Wide

Daripada mengandalkan tiap tim menulis securityContext benar, tegakkan lewat admission controller (Kyverno/Gatekeeper):

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-root
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-runasnonroot
      match:
        resources: { kinds: [Pod] }
      validate:
        pattern:
          spec:
            containers:
              - securityContext:
                  runAsNonRoot: true

Ini pola policy-as-code: kebijakan sekali tulis, ditegakkan di seluruh namespace, dan audit report otomatis untuk yang mode Audit.

#Runtime Detection: Saat Pencegahan Gagal

Semua kontrol di atas adalah pencegahan. Runtime detection adalah asumsi bahwa sesuatu tetap lolos — dan saat itu terjadi, kalian harus tahu dalam menit:

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco \
  --set driver.kind=modern_ebpf -n falco --create-namespace

Falco mendeteksi syscall abnormal berdasarkan aturan — contoh temuan klasik yang langsung relevan bagi AppSec:

Shell spawned in container           → webshell/RCE indicator
Write below /etc in container        → tampering attempt
Outbound connection to unusual IP    → exfiltration/C2
Read sensitive file after unexpected exec → post-exploit behavior

Alur operasinya: alert Falco → routing ke SIEM/chat → triase AppSec/SRE → response (isolasi pod, rotasi secret). Tanpa alur ini, detection hanyalah log mahal. Untuk aplikasi kalian sendiri, tambahkan rule custom berbasis perilaku normal: "container api tidak pernah spawn process lain selain node" — deviasi dari baseline itu sinyal kompromi berkualitas tinggi.

#Common Pitfalls

• Shared cluster tanpa namespace isolation: tim A bisa membaca secret tim B via RBAC longgar; gunakan namespace + RBAC per tim, atau cluster terpisah untuk trust level berbeda.
• Secrets di etcd plaintext: base64 bukan enkripsi — aktifkan encryption at rest untuk Secret objects, idealnya dengan KMS.
• Serverless VPC open egress: function yang bisa call internet bebas membuat SSRF tetap eksploitable; batasi egress via NAT + allowlist.
• Detection tanpa playbook: alert tanpa langkah respons tertulis akan di-ignore setelah minggu ketiga false alarm.

#Penutup

Inti yang harus dibawa pulang:

• Serverless memindahkan beban ke provider tapi IAM per-function dan event-as-untrusted tetap milik kalian.
• Kubernetes: securityContext + NetworkPolicy + admission policy = jaminan cluster-wide, bukan harapan per-tim.
• Pin image digest dan matikan service account token mount — detail kecil, dampak besar.
• Runtime detection (Falco) menutup premis bahwa pencegahan bisa gagal; pasang alert + playbook, bukan sekadar tool.

Di episode 16 kita kembali ke kode dengan sudut pandang berbeda: Secure Frameworks & Libraries — bagaimana memeras maksimal fitur keamanan bawaan framework (CSRF protection, ORM binding, auto-escaping, security headers) dan kenapa mematikannya adalah kesalahan paling mahal yang mudah dihindari. Sampai jumpa di episode 16!