LA NINA // BLOG
Kembali ke Indeks Catatan

Arsitektur Platform Engineering Modern: Crossplane Control Plane, Argo Rollouts Progressive Delivery, Istio Ambient Mesh HBONE, ARC dan SLSA Level 3

Paradigma Platform Engineering 2026: Menuju Otonomi & Deklaratif Penuh

Dalam lanskap komputasi cloud-native modern berskala enterprise, pendekatan tradisional dalam mengelola infrastruktur melalui eksekusi sekuensial skrip CI/CD dan Terraform CLI (Infrastructure as Code - IaC) telah membentur batas skalabilitas struktural. Pola push-based pipeline kerap menimbulkan state locking deadlocks, celah configuration drift yang tak terdeteksi (open-loop control), serta friksi kognitif yang membebani tim pengembang aplikasi (developer cognitive overload).

Untuk mengatasi tantangan tersebut, disiplin rekayasa sistem bertransformasi mengadopsi Platform Engineering dan penyediaan Internal Developer Platform (IDP) mandiri. Paradigma ini mengintegrasikan lima pilar teknologi kunci:

  1. Kubernetes-Native Control Plane (Crossplane): Mengubah API Kubernetes menjadi bidang kendali terpadu untuk mengabstraksikan dan merekonsiliasi seluruh sumber daya multi-cloud secara kontinu (closed-loop reconciliation).
  2. Progressive Delivery (Argo Rollouts): Menggantikan strategi rolling update primitif dengan rilis kanari terautomasi berbasis analisis metrik observabilitas mendalam dan integrasi L7 Gateway API.
  3. Sidecarless Service Mesh (Istio Ambient Mesh): Menghapus beban overhead resource ratusan sidecar container Envoy per Pod melalui arsitektur terdistribusi Zero Trust Tunnel (ztunnel) berbasis Rust dan enkapsulasi HTTP-Based Overlay Network Encapsulation (HBONE mTLS port 15008).
  4. Hardened Ephemeral CI/CD Infrastructure (Actions Runner Controller - ARC): Menyediakan runner eksekusi CI/CD dinamis yang terisolasi ketat di tingkat user-space kernel sandbox menggunakan Google gVisor (runsc).
  5. Cryptographic Software Supply Chain Security (SLSA Level 3 & in-toto Provenance): Memvalidasi integritas biner dan attestation build secara matematis sebelum artefak diizinkan berjalan di lingkungan produksi.

Artikel ini mengupas secara tuntas arsitektur internal, mekanika low-level, konfigurasi produksi nyata, skrip validasi operasional, serta Root Cause Analysis (RCA) kasus nyata dari insiden infrastruktur produksiβ€”seluruhnya disajikan menggunakan data sintetis RFC 5737 (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24).

TEXT
+---------------------------------------------------------------------------------------------------+
|                        INTERNAL DEVELOPER PLATFORM (IDP) KUBERNETES CONTROL PLANE                 |
+---------------------------------------------------------------------------------------------------+
|  Developer Claim (XRC: "PostgreSqlInstance")                                                      |
|         β”‚                                                                                         |
|         β–Ό                                                                                         |
|  [ CROSSPLANE COMPOSITION ENGINE ] ───────────────────────────────────────────────┐              |
|         β”‚                                                                         β”‚ (Creates Cloud)|
|         β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”                                      β–Ό               |
|         β–Ό                                  β–Ό                             [ Cloud Infrastructure ] |
|  [ Argo Rollout Canary ]        [ Istio Ambient Mesh ]                   (RDS, S3, IAM, VPC via   |
|         β”‚ (Progressive Delivery)           β”‚ (Sidecarless mTLS)           Provider-AWS/GCP K8s CRD)|
|         β–Ό                                  β–Ό                                                      |
|   Gateway API (HTTPRoute)          ztunnel (Node eBPF) ──[HBONE:15008]──> Waypoint Envoy (L7)     |
|         β”‚                                                                                         |
|         β–Ό                                                                                         |
|  [ CI Pipeline: GitHub Actions ARC ] ──(Build & Attest)──> [ SLSA Level 3 Cosign / Kyverno Gate ] |
+---------------------------------------------------------------------------------------------------+

1. Mekanika Low-Level & Arsitektur Internal

1.1 Crossplane vs Terraform: Continuous Actuation Control Loop

Arsitektur Terraform konvensional bersifat open-loop: state dievaluasi hanya ketika seorang insinyur melakukan trigger pada pipeline GitOps. Jika terjadi intervensi manual darurat di web konsol AWS atau modifikasi di luar kendali Git, drift tersebut akan bertahan hingga jadwal eksekusi berikutnya.

Sebaliknya, Crossplane menerapkan teori kendali umpan balik tertutup (closed-loop feedback control theory):

  • Custom Resource Definitions (XRD & XR): Insinyur platform menyusun abstraksi khusus organisasi (CompositeResourceDefinition) yang membatasi ribuan parameter cloud kompleks menjadi kontrak deklaratif ringkas bagi pengembang (misalnya: storageGB, tier, engineVersion).
  • Composition Pipeline: Engine Crossplane mengeksekusi fungsi gRPC (Go/KCL) untuk memetakan satu Composite Resource (XR) menjadi sekumpulan Managed Resources (MR) seperti SubnetGroup, DBSubnetGroup, SecurityGroup, dan RDSInstance.
  • Reconciliation Delta Actuation: Setiap Managed Resource dikawal oleh Reconciler independen yang melakukan perbandingan terus-menerus terhadap API penyedia cloud: $$\Delta = ext{DesiredState}{ ext{K8s Spec}} - ext{ObservedState}{ ext{Cloud Provider API}}$$ Apabila $\Delta eq \emptyset$, Reconciler secara asinkron memanggil mutasi REST API cloud provider untuk mengembalikan konfigurasi ke kondisi yang sah (self-healing infrastructure).

1.2 Argo Rollouts & Dynamic L7 Traffic Routing

Strategi bawaan Kubernetes RollingUpdate bekerja secara buta (blind rollout): selama kontainer lolos TCP socket check atau probe ke /healthz, Kubelet menganggap pod siap menerima traffic, lalu melanjutkan terminasi pod versi sebelumnya. Keterbatasan ini berbahaya ketika terjadi subtle runtime bugs seperti memory leak di bawah beban nyata, saturasi pool koneksi database, atau lonjakan latensi microservices.

Argo Rollouts memperkenalkan arsitektur decoupled ReplicaSet:

  1. Stable ReplicaSet: Mengoperasikan biner versi stabil yang melayani mayoritas beban kerja.
  2. Canary ReplicaSet: Menjalankan biner versi kandidat dengan alokasi trafik granular.
  3. Gateway API Traffic Shifting: Rollouts controller berinteraksi langsung dengan resource HTTPRoute (atau Envoy Gateway/Istio VirtualService). Bobot trafik Layer 7 dimutasi secara presisi tanpa bergantung pada rasio jumlah pod:
    YAML
    spec:
      rules:
        - backendRefs:
            - name: payment-engine-stable
              port: 8080
              weight: 80
            - name: payment-engine-canary
              port: 8080
              weight: 20
  4. Autonomous AnalysisRun: Di setiap tahapan eskalasi persentase (5% $ ightarrow$ 20% $ ightarrow$ 50% $ ightarrow$ 100%), controller menembakkan kueri evaluasi metrik ke Prometheus TSDB: $$ ext{ErrorRate} = rac{\sum ext{rate}( ext{http_requests_total}{ ext{status}=\sim"5.."} [2m])}{\sum ext{rate}( ext{http_requests_total} [2m])} imes 100%$$ Jika error rate melampaui ambang batas toleransi ($\le 0.5%$), sistem langsung membatalkan proses rilis (automated abort), memulihkan rute ke 100% stable dalam waktu kurang dari 15 detik, dan mengisolasi pod kanari untuk analisis forensik.

1.3 Istio Ambient Mesh: The Sidecarless Revolution (ztunnel, HBONE & Waypoint)

Pola klasik sidecar injection mengharuskan satu kontainer Envoy disuntikkan ke dalam setiap Pod aplikasi. Pada kluster berskala 10.000 pod, pendekatan ini memboroskan 500 GB hingga 1.5 TB memori hanya untuk membiayai proxy redundan, serta mewajibkan rolling restart seluruh aplikasi saat control plane mesh diperbarui.

Istio Ambient Mesh memisahkan lapisan fungsionalitas Service Mesh menjadi dua tingkatan terpisah:

  1. L4 Secure Transport (ztunnel):
    • Daemonset tunggal per node yang dikompilasi secara native menggunakan bahasa pemrograman Rust.
    • Menghindari overhead runtime garbage-collection dan mengonsumsi memori minimal (~50 MB per node).
    • Memanfaatkan program eBPF (sockops dan tc) di network namespace host untuk membelokkan paket TCP inbound dan outbound secara transparan tanpa mengubah PodSpec.
    • Mengenkapsulasi trafik antar-node melalui HBONE (HTTP-Based Overlay Network Encapsulation) di atas port TCP 15008 dengan enkripsi mutual TLS (mTLS) dan autentikasi identitas SPIFFE (spiffe://cluster.local/ns/.../sa/...).
  2. L7 Application Policy (Waypoint Proxy):
    • Apabila aplikasi memerlukan pemrosesan Layer 7 lanjutan (inspeksi header HTTP, verifikasi token JWT, rate limiting, atau routing berbasis path URL), sebuah instance Envoy khusus dideploy di luar pod aplikasiβ€”dikelola per Namespace atau per ServiceAccount.
    • ztunnel secara cerdas mengarahkan paket ke Waypoint sebelum dialirkan ke pod tujuan, memastikan pemisahan tugas (separation of concerns) yang aman.
TEXT
NODE 1 (192.0.2.11)                                     NODE 2 (192.0.2.12)
+------------------------------------+                  +------------------------------------+
| Pod A (Frontend / Client)          |                  | Pod B (Backend / Payment API)      |
|   β”‚ (Plain TCP via veth)           |                  |   β–² (Plain TCP)                    |
|   β–Ό                                |                  |   β”‚                                |
| Linux Network Stack (eBPF Redirect)|                  | Linux Network Stack                |
|   β”‚                                |                  |   β–²                                |
|   β–Ό                                |                  |   β”‚                                |
| ztunnel (Rust Node Daemon)         |                  | ztunnel (Rust Node Daemon)         |
|   β”‚ [HBONE: Port 15008 / mTLS]     |                  |   β–²                                |
+───┼────────────────────────────────+                  +───┼────────────────────────────────+
    β”‚                                                       β”‚
    └───────────────────────[ Underlay Network ]β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

1.4 Hardened Ephemeral CI/CD: Actions Runner Controller (ARC) & gVisor (runsc)

Eksekusi pengujian kode dan build kontainer dalam lingkungan CI/CD merupakan vektor serangan krusial. Memberikan hak akses root atau mounting socket Docker host (/var/run/docker.sock) memungkinkan serangan container breakout yang berakibat pada pengambilalihan kontrol node (node takeover).

Actions Runner Controller v0.9+ mengadopsi pola ephemeral runner pool:

  • AutoscalingRunnerSet: Menggunakan mekanisme long-polling HTTP outbound yang aman ke GitHub API, menghilangkan keharusan membuka port ingress ke dalam kluster.
  • Microkernel Isolation (gVisor runsc): Kontainer runner dijalankan di atas runtime runsc. Syscall Linux penting (clone, mount, execve, ptrace) diintersepsi dan diproses oleh kernel user-space (Sentry), sementara akses I/O ke file dialihkan via proxy terproteksi (Gofer).
  • RAM-Disk Ephemeral Storage: Direktori kerja build (/home/runner/_work) dialokasikan pada volume emptyDir dengan medium Memory. Seluruh jejak eksekusi, biner sementara, dan artefak build musnah seketika saat pod runner diterminasi setelah menyelesaikan satu job.

1.5 Supply Chain Security: SLSA Level 3 & in-toto Provenance

Membangun image container saja tidak cukup untuk memenuhi compliance industri Tier-1 (seperti OpenSSF dan regulasi FINTECH/Banking). Diperlukan bukti kriptografis bahwa image yang berjalan di production benar-benar dibangun oleh sistem CI/CD terpercaya dari commit git yang sah tanpa ada manipulasi di registry.

SLSA (Supply-chain Levels for Software Artifacts) Level 3 mewajibkan:

  1. Source Integrity: Kode bersumber dari Git yang ditandatangani secara kriptografis.
  2. Build Isolation & Ephemeral Environment: Build dieksekusi pada lingkungan terisolasi yang tidak dapat diakses atau diintervensi oleh pengguna umum.
  3. Non-Falsifiable Provenance: Bukti metadata build (identitas builder, source commit, digest dependensi) ditandatangani menggunakan kunci kriptografis yang dihasilkan oleh CA OIDC jangka pendek (Sigstore Fulcio) dan dicatat ke dalam Immutable Transparency Log (Sigstore Rekor).

2. Implementasi Konfigurasi Nyata & Production Hardening

2.1 Crossplane CompositeResourceDefinition (XRD) & Composition

Berikut adalah skema XRD untuk abstraksi basis data relasional enterprise berkeandalan tinggi:

YAML
# xrd-postgresql.yaml
apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
  name: xpostgresqlinstances.platform.lanina.io
spec:
  group: platform.lanina.io
  names:
    kind: XPostgreSqlInstance
    plural: xpostgresqlinstances
  claimNames:
    kind: PostgreSqlInstance
    plural: postgresqlinstances
  versions:
    - name: v1alpha1
      served: true
      referenceable: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              required:
                - storageGB
                - engineVersion
                - tier
              properties:
                storageGB:
                  type: integer
                  minimum: 20
                  maximum: 10000
                  description: "Alokasi disk storage dalam Gigabytes"
                engineVersion:
                  type: string
                  enum: ["15.6", "16.2", "16.4"]
                  description: "Versi engine PostgreSQL"
                tier:
                  type: string
                  enum: ["development", "staging", "production-ha"]
                  description: "Tier lingkungan deployment"
                backupRetentionDays:
                  type: integer
                  default: 7
                  minimum: 1
                  maximum: 35
            status:
              type: object
              properties:
                endpoint:
                  type: string
                port:
                  type: integer
                readyStatus:
                  type: string

Komposisi pipeline menggunakan Composition Function modern untuk menghasilkan instance AWS RDS yang terisolasi di subnet privat sintetis:

YAML
# composition-aws-rds.yaml
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: xpostgresqlinstances.aws.rds.production
  labels:
    provider: aws
    tier: production-ha
spec:
  compositeTypeRef:
    apiVersion: platform.lanina.io/v1alpha1
    kind: XPostgreSqlInstance
  mode: Pipeline
  pipeline:
    - step: patch-and-transform
      functionRef:
        name: function-patch-and-transform
      input:
        apiVersion: pt.fn.crossplane.io/v1beta1
        kind: Resources
        resources:
          - name: rds-subnet-group
            base:
              apiVersion: rds.aws.upbound.io/v1beta1
              kind: SubnetGroup
              spec:
                forProvider:
                  region: ap-southeast-1
                  description: "Subnet group managed by Crossplane Control Plane"
                  subnetIdSelector:
                    matchLabels:
                      type: database-private-subnet
            patches:
              - type: SetIdentifier
                transforms:
                  - type: string
                    string:
                      fmt: "%s-subnet-group"
          - name: rds-instance
            base:
              apiVersion: rds.aws.upbound.io/v1beta1
              kind: Instance
              spec:
                forProvider:
                  region: ap-southeast-1
                  autoGeneratePassword: true
                  dbSubnetGroupNameSelector:
                    matchControllerRef: true
                  engine: postgres
                  instanceClass: db.m6i.xlarge
                  multiAz: true
                  publiclyAccessible: false
                  storageEncrypted: true
                  kmsKeyIdSelector:
                    matchLabels:
                      role: rds-kms-key
                  skipFinalSnapshot: false
                  deletionProtection: true
                writeConnectionSecretToRef:
                  namespace: crossplane-system
            patches:
              - type: FromCompositeFieldPath
                fromFieldPath: spec.storageGB
                toFieldPath: spec.forProvider.allocatedStorage
              - type: FromCompositeFieldPath
                fromFieldPath: spec.engineVersion
                toFieldPath: spec.forProvider.engineVersion
              - type: FromCompositeFieldPath
                fromFieldPath: spec.backupRetentionDays
                toFieldPath: spec.forProvider.backupRetentionPeriod
              - type: SetIdentifier
                transforms:
                  - type: string
                    string:
                      fmt: "%s-rds-pg"
              - type: ToCompositeFieldPath
                fromFieldPath: status.atProvider.address
                toFieldPath: status.endpoint
              - type: ToCompositeFieldPath
                fromFieldPath: status.atProvider.port
                toFieldPath: status.port
              - type: ToCompositeFieldPath
                fromFieldPath: status.conditions[0].status
                toFieldPath: status.readyStatus

2.2 Argo Rollouts Progressive Delivery dengan Gateway API & Prometheus Analysis

Manifest rilis kanari bertahap terhubung langsung dengan HTTPRoute Gateway API:

YAML
# rollout-canary-gateway-api.yaml
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: payment-engine
  namespace: core-banking
  labels:
    app: payment-engine
    tier: api
spec:
  replicas: 10
  revisionHistoryLimit: 5
  selector:
    matchLabels:
      app: payment-engine
  strategy:
    canary:
      canaryService: payment-engine-canary
      stableService: payment-engine-stable
      trafficRouting:
        gatewayAPI:
          httpRoute: payment-engine-route
          namespace: core-banking
      steps:
        - setWeight: 5
        - pause: { duration: 10m }
        - setWeight: 20
        - pause: { duration: 15m }
        - setWeight: 50
        - pause: { duration: 20m }
        - setWeight: 80
        - pause: { duration: 10m }
      analysis:
        templates:
          - templateName: payment-engine-success-rate-p99
        args:
          - name: service-name
            value: payment-engine
  template:
    metadata:
      labels:
        app: payment-engine
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "8080"
    spec:
      containers:
        - name: payment-engine
          image: ghcr.io/lanina-corp/banking/payment-engine:v2.4.1
          imagePullPolicy: IfNotPresent
          ports:
            - name: http
              containerPort: 8080
          resources:
            requests:
              cpu: "1000m"
              memory: "2Gi"
            limits:
              cpu: "2000m"
              memory: "4Gi"
          readinessProbe:
            httpGet:
              path: /healthz/ready
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /healthz/live
              port: 8080
            initialDelaySeconds: 15
            periodSeconds: 10

Template analisis observabilitas yang memantau SLA Error Rate dan Latensi p99 secara real-time:

YAML
# analysistemplate-prometheus.yaml
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: payment-engine-success-rate-p99
  namespace: core-banking
spec:
  args:
    - name: service-name
  metrics:
    - name: error-rate-percentage
      interval: 1m
      successCondition: result[0] <= 0.5
      failureLimit: 2
      provider:
        prometheus:
          address: http://prometheus-k8s.monitoring.svc.cluster.local:9090
          query: |
            (
              sum(rate(http_requests_total{job="payment-engine-canary", status=~"5.."}[2m]))
              /
              clamp_min(sum(rate(http_requests_total{job="payment-engine-canary"}[2m])), 1)
            ) * 100
    - name: p99-latency-milliseconds
      interval: 1m
      successCondition: result[0] <= 150
      failureLimit: 3
      provider:
        prometheus:
          address: http://prometheus-k8s.monitoring.svc.cluster.local:9090
          query: |
            histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket{job="payment-engine-canary"}[2m])) by (le)) * 1000

2.3 Istio Ambient Mesh CNI, Waypoint Gateway & SPIFFE AuthorizationPolicy

Penyebaran Istio CNI dengan redirection mode native eBPF:

YAML
# ambient-helm-values.yaml
cni:
  ambient:
    enabled: true
    configDir: "/etc/cni/net.d"
    cniBinDir: "/opt/cni/bin"
    redirectMode: "ebpf"

ztunnel:
  enabled: true
  resources:
    requests:
      cpu: "200m"
      memory: "128Mi"
    limits:
      cpu: "1000m"
      memory: "512Mi"
  env:
    LOG_LEVEL: "info"
    ZTUNNEL_ENABLE_PROFILING: "false"
    TERMINATION_DRAIN_DURATION: "5s"

Aktivasi Ambient data-plane dan penerapan L7 Waypoint Gateway beserta AuthorizationPolicy berbasis identitas kriptografis SPIFFE:

BASH
# Tandai namespace untuk bergabung ke data-plane Ambient
kubectl label namespace core-banking istio.io/dataplane-mode=ambient --overwrite
YAML
# waypoint-gateway.yaml
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: banking-waypoint
  namespace: core-banking
  labels:
    istio.io/waypoint-for: all
spec:
  gatewayClassName: istio-waypoint
  listeners:
    - name: mesh
      port: 15008
      protocol: HBONE
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: require-authenticated-spiffe
  namespace: core-banking
spec:
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: banking-waypoint
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/frontend/sa/web-gateway-sa"]
      to:
        - operation:
            methods: ["POST", "GET"]
            paths: ["/api/v1/payments/*"]

2.4 Actions Runner Controller (ARC) dengan Isolasi Sandbox gVisor

Manifest AutoscalingRunnerSet untuk eksekusi CI yang sepenuhnya terisolasi dan rootless:

YAML
# arc-runner-set-gvisor.yaml
apiVersion: actions.github.com/v1alpha1
kind: AutoscalingRunnerSet
metadata:
  name: hardened-prod-runners
  namespace: arc-runners
spec:
  githubConfigUrl: "https://github.com/lanina-corp"
  githubConfigSecret: github-arc-app-credentials
  minRunners: 2
  maxRunners: 50
  template:
    spec:
      runtimeClassName: runsc # Mewajibkan user-space kernel gVisor sandbox
      securityContext:
        runAsNonRoot: true
        runAsUser: 1001
        runAsGroup: 1001
        fsGroup: 1001
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: runner
          image: ghcr.io/actions/actions-runner:latest
          command: ["/home/runner/run.sh"]
          resources:
            requests:
              cpu: "2000m"
              memory: "4Gi"
            limits:
              cpu: "4000m"
              memory: "8Gi"
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop: ["ALL"]
          volumeMounts:
            - name: runner-work-ephemeral
              mountPath: /home/runner/_work
            - name: runner-tmp
              mountPath: /tmp
      volumes:
        - name: runner-work-ephemeral
          emptyDir:
            medium: Memory # Volume RAM-disk berkecepatan tinggi yang musnah seketika
            sizeLimit: 4Gi
        - name: runner-tmp
          emptyDir:
            sizeLimit: 1Gi

2.5 Kebijakan Validasi Kriptografis Kyverno untuk SLSA Level 3

Memblokir eksekusi sembarang pod di kluster jika kontainer tidak mengantongi provenance attestation SLSA Level 3 dari pipeline builder resmi:

YAML
# kyverno-slsa-verification.yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-slsa3-provenance-and-cosign
  annotations:
    policies.kyverno.io/title: "Verify SLSA Level 3 Provenance & Cosign Signature"
    policies.kyverno.io/category: "Software Supply Chain Security"
    policies.kyverno.io/severity: "critical"
spec:
  validationFailureAction: Enforce
  webhookTimeoutSeconds: 30
  rules:
    - name: verify-cosign-signature-and-attestation
      match:
        any:
          - resources:
              kinds: ["Pod"]
              namespaces: ["core-banking", "production"]
      verifyImages:
        - imageReferences:
            - "ghcr.io/lanina-corp/*"
          attestors:
            - entries:
                - keyless:
                    issuer: "https://token.actions.githubusercontent.com"
                    subject: "https://github.com/lanina-corp/banking-workflows/.github/workflows/release.yaml@refs/heads/main"
                    rekor:
                      url: "https://rekor.sigstore.dev"
          attestations:
            - predicateType: "https://slsa.dev/provenance/v1"
              conditions:
                - all:
                    - key: "{{ builder.id }}"
                      operator: Equals
                      value: "https://github.com/actions/runner"
                    - key: "{{ buildDefinition.buildType }}"
                      operator: Equals
                      value: "https://actions.github.com/workflow/v1"

3. Skrip Otomatisasi, Audit, dan Validasi Lapangan

3.1 Skrip 1: validate-crossplane-xrd.sh (Health & Drift Auditor)

Skrip inspeksi menyeluruh untuk memverifikasi konsistensi status CRD, XRD, Managed Resources, serta deteksi kegagalan rekonsiliasi controller:

BASH
#!/usr/bin/env bash
# ==============================================================================
# Script: validate-crossplane-xrd.sh
# Deskripsi: Validasi & Audit Mendalam Arsitektur Crossplane Control Plane:
#            XRDs, Compositions, Managed Resources (MRs), serta Cloud Reconcilers.
# Author: La Nina 🌊 | Data Sintetis: RFC 5737
# ==============================================================================

set -euo pipefail

RED=''
GREEN=''
YELLOW=''
BLUE=''
CYAN=''
BOLD=''
NC=''

log_info() { echo -e "${BLUE}[INFO]${NC} $(date '+%Y-%m-%d %H:%M:%S') - $1"; }
log_ok()   { echo -e "${GREEN}[OK]${NC}   $(date '+%Y-%m-%d %H:%M:%S') - $1"; }
log_warn() { echo -e "${YELLOW}[WARN]${NC} $(date '+%Y-%m-%d %H:%M:%S') - $1"; }
log_err()  { echo -e "${RED}[ERR]${NC}  $(date '+%Y-%m-%d %H:%M:%S') - $1"; }

echo -e "${BOLD}${CYAN}========================================================================${NC}"
echo -e "${BOLD}${CYAN}   CROSSPLANE CONTROL PLANE HEALTH & DRIFT AUDITOR - 2026 EDITION       ${NC}"
echo -e "${BOLD}${CYAN}========================================================================${NC}"

# 1. Verifikasi Status Pod Provider
log_info "Memeriksa ketersediaan Pod Provider Crossplane..."
kubectl get pods -n crossplane-system -l "pkg.crossplane.io/provider" --no-headers | while read -r line; do
    POD_NAME=$(echo "$line" | awk '{print $1}')
    POD_STATUS=$(echo "$line" | awk '{print $3}')
    if [[ "$POD_STATUS" == "Running" ]]; then
        log_ok "Provider Pod: $POD_NAME [STATUS: $POD_STATUS]"
    else
        log_err "Provider Pod Tidak Sehat: $POD_NAME [STATUS: $POD_STATUS]"
    fi
done

# 2. Audit CompositeResourceDefinitions (XRD)
log_info "Memeriksa status Established & Offered pada seluruh XRD..."
kubectl get xrd -o jsonpath='{range .items[*]}{.metadata.name}{"	"}{range .status.conditions[*]}{.type}={.status}{" "}{end}{"
"}{end}' | while read -r line; do
    XRD_NAME=$(echo "$line" | awk '{print $1}')
    CONDITIONS=$(echo "$line" | cut -f2-)
    if [[ "$CONDITIONS" =~ "Established=True" ]] && [[ "$CONDITIONS" =~ "Offered=True" ]]; then
        log_ok "XRD: $XRD_NAME [ESTABLISHED & OFFERED]"
    else
        log_warn "XRD Anomali: $XRD_NAME [CONDITIONS: $CONDITIONS]"
    fi
done

# 3. Audit Managed Resources (MR) Sinkronisasi & Drift
log_info "Memeriksa sinkronisasi status SYNCED & READY pada Managed Resources..."
kubectl get managed -o jsonpath='{range .items[*]}{.kind}{"/"}{.metadata.name}{"	"}{.status.conditions[?(@.type=="Synced")].status}{"	"}{.status.conditions[?(@.type=="Ready")].status}{"
"}{end}' | while read -r line; do
    MR_NAME=$(echo "$line" | awk '{print $1}')
    SYNCED=$(echo "$line" | awk '{print $2}')
    READY=$(echo "$line" | awk '{print $3}')

    if [[ "$SYNCED" == "True" ]] && [[ "$READY" == "True" ]]; then
        log_ok "Resource: $MR_NAME [SYNCED: True, READY: True]"
    else
        log_err "Resource Drift/Error: $MR_NAME [SYNCED: $SYNCED, READY: $READY]"
    fi
done

3.2 Skrip 2: benchmark-rollouts-canary.sh (Rollout & Rollback Stress-Tester)

Skrip pengujian otomatis untuk memverifikasi SLA automated rollback ketika terjadi anomali beban trafik sintetis:

BASH
#!/usr/bin/env bash
# ==============================================================================
# Script: benchmark-rollouts-canary.sh
# Deskripsi: Injeksi beban trafik sintetis dan validasi SLA Automated Rollback
# Author: La Nina 🌊 | Target IP: 198.51.100.25 (RFC 5737 Synthetic Gateway)
# ==============================================================================

set -euo pipefail

TARGET_GATEWAY_URL="http://198.51.100.25/api/v1/payments/checkout"
ROLLOUT_NAME="payment-engine"
NAMESPACE="core-banking"

echo "[TEST] Memulai verifikasi Progressive Delivery Canary..."
INITIAL_STEP=$(kubectl argo rollouts get rollout "${ROLLOUT_NAME}" -n "${NAMESPACE}" -o json | jq -r '.status.currentStepIndex')
echo "[INFO] Step awal kanari terdeteksi pada indeks: ${INITIAL_STEP}"

echo "[STRESS] Menginjeksi 1.000 request dengan 15% kegagalan HTTP 500 sintetis..."
for i in $(seq 1 1000); do
    if (( i % 7 == 0 )); then
        # Injeksi header trigger error simulasi
        curl -s -o /dev/null -H "X-Synthetic-Fault: error500" "${TARGET_GATEWAY_URL}" || true
    else
        curl -s -o /dev/null "${TARGET_GATEWAY_URL}" || true
    fi
done

echo "[AUDIT] Mengamati reaksi Argo Rollouts AnalysisRun..."
START_TIME=$(date +%s)
while true; do
    PHASE=$(kubectl argo rollouts get rollout "${ROLLOUT_NAME}" -n "${NAMESPACE}" -o json | jq -r '.status.phase')
    if [[ "${PHASE}" == "Degraded" ]] || [[ "${PHASE}" == "Aborted" ]]; then
        END_TIME=$(date +%s)
        ELAPSED=$((END_TIME - START_TIME))
        echo "================================================================="
        echo "βœ… SUCCESS: Automated Rollback terpicu dalam ${ELAPSED} detik!"
        echo "Status Rollout beralih ke: ${PHASE}"
        echo "Bobot trafik canary berhasil dipangkas kembali ke 0%."
        echo "================================================================="
        break
    fi
    sleep 2
done

3.3 Skrip 3: audit-ambient-mesh-traffic.sh (HBONE Data-Path Inspector)

Skrip inspeksi soket kernel dan frame HBONE port 15008 pada seluruh node pengantar trafik:

BASH
#!/usr/bin/env bash
# ==============================================================================
# Script: audit-ambient-mesh-traffic.sh
# Deskripsi: Audit data-plane Istio Ambient, soket ztunnel, dan HBONE handshake
# Author: La Nina 🌊 | Port Terproteksi: 15008 (mTLS HBONE), 15006 (Inbound Plain)
# ==============================================================================

set -euo pipefail

echo "=== MEMERIKSA STATUS LISTENER ZTUNNEL PADA HOST LOCAL ==="
ss -tulpn | grep -E "15008|15006" || {
    echo "❌ ERROR: Listener ztunnel tidak aktif di port 15008 / 15006!"
    exit 1
}
echo "βœ… OK: ztunnel Rust Daemon aktif mendengarkan koneksi HBONE (Port 15008)."

echo "=== AUDIT KONEKSI AKTIF OVERLAY ENKAPSULASI HBONE ==="
ss -tnp '( dport = :15008 or sport = :15008 )'

echo "=== VALIDASI IDENTITAS SPIFFE PADA ZTUNNEL CERTIFICATE CACHE ==="
ZTUNNEL_POD=$(kubectl get pods -n istio-system -l app=ztunnel -o jsonpath='{.items[0].metadata.name}')
kubectl exec -n istio-system "${ZTUNNEL_POD}" -c ztunnel --     curl -s http://localhost:15000/config_dump | jq '.certificates[] | {subject: .subject, valid_to: .valid_to}'

4. Root Cause Analysis (RCA) Kasus Nyata di Lapangan

Berikut adalah analisis investigasi forensik dari empat insiden arsitektur nyata di lingkungan produksi skala enterprise:

4.1 Kasus 1: Infinite Reconcile Loop Crossplane & Saturasi Quota API Cloud Provider

Gejala Insiden:

Setelah mengadopsi Crossplane untuk mengelola 450 database PostgreSQL AWS RDS di region ap-southeast-1, konsol manajemen cloud tiba-tiba mengembalikan error RateExceeded: Request limit exceeded. Seluruh pipeline provisioning lumpuh selama 6 jam, dan biaya panggilan API membengkak ribuan dolar.

Investigasi Forensik (RCA):

Analisis mendalam pada log pod provider-aws-rds mengungkap adanya infinite actuation loop:

JSON
{"level":"info","ts":"2026-09-17T14:22:01.102Z","msg":"Reconciling external resource","diff":"- spec.forProvider.allocatedStorage: 100
+ status.atProvider.allocatedStorage: 120"}
  1. Mesin database RDS dikonfigurasi dengan fitur bawaan cloud Storage Autoscaling yang secara otomatis menaikkan kapasitas disk fisik dari 100 GB ke 120 GB saat utilisasi mencapai 90%.
  2. Kontroler Crossplane membandingkan Desired State di manifest K8s (allocatedStorage: 100) dengan Observed State hasil kueri API cloud (allocatedStorage: 120).
  3. Mendeteksi adanya perbedaan (drift), Crossplane secara agresif mengirimkan perintah mutasi ModifyDBInstance ke AWS RDS untuk mengembalikan ukuran disk ke 100 GB.
  4. AWS RDS secara arsitektural menolak penurunan ukuran storage (downscaling storage is strictly disallowed), lalu melempar pesan error.
  5. Crossplane menganggap kegagalan ini sebagai status rekonsiliasi yang harus dicoba ulang seketika (immediate requeue). Dengan 450 database yang mengalami kondisi serupa berulang kali setiap detik, kuota API AWS RDS seketika tercekik total.

Solusi & Mitigasi Definitif:

  • Mengonfigurasi managementPolicies dan memanfaatkan field initProvider agar parameter dinamis hanya ditetapkan saat pembuatan awal:
    YAML
    spec:
      managementPolicies: ["Observe", "Create", "Update"]
      initProvider:
        allocatedStorage: 100
      forProvider:
        maxAllocatedStorage: 500 # Serahkan kontrol perluasan disk ke cloud autoscaler
  • Menetapkan parameter limitasi konkurensi pada deployment provider: --poll-interval=10m dan --max-reconcile-rate=10.

4.2 Kasus 2: Canary Flapping Akibat Sampling Window Terlalu Sempit pada Jitter Jaringan

Gejala Insiden:

Saat merilis pembaruan layanan pembayaran (payment engine) dari versi v2.4.0 ke v2.4.1, terjadi fluktuasi rute kanari (flapping) sebanyak 8 kali dalam 1 jam. Rollout berulang kali dibatalkan secara otomatis, namun segera dipicu kembali oleh rekonsiliasi GitOps.

Investigasi Forensik (RCA):

  1. Parameter PromQL pada resource AnalysisTemplate menggunakan jendela evaluasi metrik 1 menit:
    PROMQL
    sum(rate(http_requests_total{status=~"5.."}[1m])) / sum(rate(http_requests_total[1m])) * 100
  2. Pada jam sepi pengunjung (low-traffic hours), volume request kanari 5% hanya berjumlah ~50 request per menit.
  3. Terjadi micro-spike latensi jaringan sporadis selama 10 detik yang memicu 2 request mengalami TCP reset / timeout (HTTP 504).
  4. Dua request gagal dari total 50 request langsung menghasilkan persentase error sebesar 4.0%, melampaui ambang batas toleransi 0.5%.
  5. Ketiadaan parameter failureLimit atau consecutiveErrorLimit menyebabkan satu kegagalan evaluasi langsung memicu pembatalan rollout (zero fault tolerance).

Solusi & Mitigasi Definitif:

  • Memperlebar rentang observasi menjadi 5 menit (moving average) dan menggunakan fungsi clamp_min untuk mencegah pembagian dengan nol:
    PROMQL
    (
      sum(rate(http_requests_total{job="canary", status=~"5.."}[5m]))
      /
      clamp_min(sum(rate(http_requests_total{job="canary"}[5m])), 10)
    ) * 100
  • Menambahkan parameter ketahanan dan toleransi kegagalan:
    YAML
    metrics:
      - name: error-rate
        interval: 2m
        failureLimit: 3           # Wajib 3 kali kegagalan berturut-turut sebelum abort
        consecutiveErrorLimit: 2  # Mentoleransi kegagalan temporer kueri TSDB
        initialDelay: 3m          # Waktu pemanasan runtime aplikasi (JIT warmup)

4.3 Kasus 3: Packet Drop HBONE & 503 Upstream Connection Termination Akibat MTU Blackhole

Gejala Insiden:

Setelah mengaktifkan mode Istio Ambient di kluster Kubernetes multi-node (bare-metal dengan Calico VXLAN), pemanggilan endpoint POST dengan muatan payload besar (> 1.5 KB) antar-node mengalami error berkala HTTP 503 UC (Upstream Connection Termination), sementara request GET berukuran kecil (< 500 byte) berjalan 100% lancar.

Investigasi Forensik (RCA):

  1. Log ztunnel pada node pengirim mencatat:
    TEXT
    ztunnel::proxy::hbone: connection failed: broken pipe (os error 32)
  2. Analisis paket tcpdump -ni any port 15008 mengungkap bahwa protokol HBONE menambahkan overhead header framing HTTP/2 dan envelope TLS sebesar 74 byte.
  3. CNI underlay telah menggunakan enkapsulasi VXLAN bawaan (overhead 50 byte) di atas MTU interface fisik 1500 byte: $$ ext{MTU Efektif Pod} = 1500 - 50 ( ext{VXLAN}) = 1450 ext{ byte}$$
  4. Saat pod aplikasi mengirimkan paket TCP berukuran 1450 byte dengan flag Don't Fragment (DF) aktif, ztunnel menambahkan 74 byte header HBONE sehingga ukuran paket fisik membengkak menjadi 1524 byte.
  5. Switch jaringan fisik membuang (drop) frame tersebut karena melampaui MTU 1500 byte tanpa mengirimkan sinyal ICMP Type 3 Code 4 (Fragmentation Needed), menciptakan kondisi PMTUD Blackhole.

Solusi & Mitigasi Definitif:

  • Mengaktifkan Jumbo Frames (MTU 9000) pada seluruh switch fisik dan NIC server node host:
    BASH
    ip link set dev eth0 mtu 9000
  • Jika switch fisik dibatasi pada MTU standar 1500 byte, sesuaikan konfigurasi MTU veth pada CNI menjadi maksimal 1376 byte (1500 - 50 VXLAN - 74 HBONE):
    YAML
    apiVersion: crd.projectcalico.org/v1
    kind: FelixConfiguration
    metadata:
      name: default
    spec:
      vethMTU: 1376
  • Menerapkan rule iptables TCP MSS Clamping pada node:
    BASH
    iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

4.4 Kasus 4: Kontainer Escape pada Ephemeral Runner CI & Eksploitasi cgroup v1

Gejala Insiden:

Sebuah pipeline pengujian pull-request open-source mengeksekusi skrip kompilasi kode. Beberapa menit kemudian, salah satu worker node Kubernetes mengalami Kernel Soft Lockup, Kubelet berhenti merespons, dan proses cryptomining terdeteksi berjalan langsung pada kernel host Linux.

Investigasi Forensik (RCA):

  1. Pod runner lama dikonfigurasi secara ceroboh dengan hak akses istimewa (privileged):
    YAML
    securityContext:
      privileged: true # VULNERABILITAS TINGKAT KRITIS!
    Hal ini awalnya dilakukan agar runner dapat menjalankan Docker-in-Docker (DinD).
  2. Kode uji di dalam PR menyisipkan skrip eksploitasi pelepasan cgroup (release_agent escape):
    BASH
    mkdir /tmp/cgrp && mount -t cgroup -o memory cgroup /tmp/cgrp
    mkdir /tmp/cgrp/x
    echo 1 > /tmp/cgrp/x/notify_on_release
    host_path=$(sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab)
    echo "$host_path/exploit" > /tmp/cgrp/release_agent
  3. Karena kontainer berstatus privileged dan memiliki kapabilitas CAP_SYS_ADMIN, penyerang berhasil membobol batas kontainer (container escape) langsung ke root namespace node host.

Solusi & Mitigasi Definitif:

  • Mengganti runtime runner menjadi gVisor (runtimeClassName: runsc): Seluruh syscall mount dan manipulasi namespace ditangani oleh kernel tiruan di user-space, sehingga interaksi langsung ke host cgroup secara arsitektural mustahil terjadi.
  • Melarang mutlak penggunaan Docker socket host dan beralih ke builder kontainer unprivileged murni seperti Kaniko atau Buildah (Rootless mode).
  • Menegakkan standar Pod Security Standard tingkat restricted di seluruh namespace eksekusi CI/CD:
    BASH
    kubectl label namespace arc-runners pod-security.kubernetes.io/enforce=restricted --overwrite

5. Matriks Komparasi & Rekomendasi Arsitektur 2026

Berikut adalah ringkasan evaluasi arsitektur tradisional versus standar modern Platform Engineering:

Dimensi RekayasaArsitektur TradisionalStandar Platform Engineering 2026Nilai Tambah Utama
Control PlaneTerraform CLI di CI/CDCrossplane v1.16+ CompositionsKontrol deklaratif tertutup, mitigasi drift aktif dan otomatis.
Strategi RilisKubernetes RollingUpdateArgo Rollouts + Gateway APIRilis kanari terautomasi dengan observabilitas SLA metrik p99.
Service MeshEnvoy Sidecar per PodIstio Ambient Mesh (HBONE mTLS)Penghematan memori hingga 80%, zero cold-start delay, no pod restart.
Lingkungan CIVM Runner Statis / DinDARC Ephemeral + gVisor (runsc)Isolasi microkernel user-space, zero persistent storage footprint.
Supply ChainPemindaian CVE dasarSLSA Level 3 + Sigstore CosignIntegritas build kriptografis yang diverifikasi sebelum admission.

Kesimpulan

Transformasi menuju Platform Engineering bukan sekadar pergantian perkakas, melainkan evolusi mendasar dalam cara organisasi mengelola kompleksitas komputasi awan. Dengan memadukan kontrol deklaratif tertutup Crossplane, orkestrasi rilis berkeselamatan tinggi Argo Rollouts, efisiensi data-plane mutakhir Istio Ambient Mesh, ketahanan eksekusi ARC berisolasi gVisor, serta jaminan kriptografis SLSA Level 3, organisasi dapat menyajikan lingkungan komputasi yang lincah bagi pengembang (developer velocity) tanpa sedikit pun mengorbankan stabilitas dan keamanan tingkat tinggi.

Kembali ke Atas ↑