Belajar DevSecOps Engineer - Cloud Security in Pipeline

#Pendahuluan

Di episode 8 cluster K8s kalian sudah hardened. Sekarang kita periksa jalur menuju sana — proses deploy ke cloud. Momen deploy adalah konvergensi semua risiko: pipeline memegang kredensial cloud, kode baru pertama kali dieksekusi, dan perubahan infrastruktur terjadi dalam hitungan menit. Banyak breach besar dimulai dari sini: CI token dicuri, lalu dipakai untuk deploy beban jahat langsung ke production.

Episode ini menyusun pertahanan di tiga titik: identitas deploy yang tidak bisa dicuri (OIDC), guardrail organisasi yang membatasi apa pun yang lolos (SCP/policy), dan verifikasi sebelum apply (plan scanning + environment gate).

#Masalah Static Access Key

Pola lama: simpan AWS_ACCESS_KEY_ID sebagai secret GitHub, inject ke workflow, pakai untuk deploy. Tiga cacat fatal:

1. Long-lived — key hidup sampai dirotasi manual (yang sering tak pernah terjadi).
2. Broad scope — biasanya dibuat dari user admin "biar gampang".
3. Exfiltratable — sekali bocor di log atau runner yang dicompromise, attacker memakainya dari mana saja, kapan saja.

Jawaban modernnya adalah workload identity federation: pipeline menukar JWT singkat-masa-hidup dengan role cloud — tanpa static key sama sekali.

#Secure Deploy dengan OIDC

Konfigurasinya dua sisi. Di AWS, buat OIDC provider + IAM role yang percaya repo tertentu:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
    },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": {
        "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
        "token.actions.githubusercontent.com:sub": "repo:org/myapp:ref:refs/heads/main"
      }
    }
  }]
}

Baris yang disorot adalah inti keamanannya: kondisi sub mengikat role hanya untuk workflow repo org/myapp di branch main — token dari fork PR atau repo lain otomatis ditolak. Di sisi workflow:

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production      # wajib approval reviewer
    permissions:
      contents: read
      id-token: write            # minta JWT OIDC
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/deploy-myapp
          aws-region: ap-southeast-1
          role-duration-seconds: 900   # sesi 15 menit
      - run: ./scripts/deploy.sh

Hasil akhir: tidak ada secret cloud di GitHub sama sekali; kredensial hanya ada selama 15 menit, hanya di runner yang menjalankan job itu, hanya dengan izin role tersebut.

#Guardrails Tingkat Organisasi

Pipeline yang aman belum cukup — manusia tetap bisa salah lewat console, CLI, atau tool lain. Guardrails organisasi bekerja sebagai pagar terakhir:

Contoh SCP sederhana yang mencegah kesalahan klasik:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyUnapprovedRegions",
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {
      "StringNotEqualsIgnoreCase": {
        "aws:RequestedRegion": ["ap-southeast-1", "us-east-1"]
      }
    }
  }]
}

Prinsip desain guardrail: deny-by-default untuk kategori berisiko tinggi, allowlist eksplisit untuk sisanya. Guardrail bukan pengganti pipeline security — ia menyelamatkan kalian saat semua layer lain gagal.

#Cegah Misconfig Sebelum Apply

Gabungan episode 7 dan praktik cloud:

1. Scan terraform plan JSON di PR — preventive, sudah kalian bangun dengan conftest.
2. Plan review wajib untuk change production — diff infrastruktur dilihat manusia, bukan auto-apply diam-diam.
3. Environment protection — production hanya bisa disentuh lewat environment dengan required reviewers (episode 3).
4. Detective pasca-deploy — CSPM (Security Hub, Defender for Cloud, SCC) menyapu akun berkala mencari drift dan misconfig yang lolos.

Loop ini penting: detective findings harus mengalir balik menjadi aturan preventive baru di conftest — itulah cara sistem belajar dari setiap insiden nyaris terjadi.

#Pitfall Umum

• Role deploy over-scoped — role OIDC dengan AdministratorAccess menghilangkan manfaat federation; pisahkan role per aplikasi/per environment dengan permission boundary.
• Trust policy tanpa condition sub — siapa pun yang bisa trigger workflow di org kalian bisa assume role; selalu ikat repo+branch+environment.
• Guardrail tanpa exception process — sediakan jalur break-glass berdokumen dengan approval, kalau tidak tim akan minta bypass permanen.
• Lupa matikan legacy keys — setelah migrasi OIDC, cari dan hapus access key statis yang tersisa (aws iam generate-credential-report).

#Penutup

Inti yang harus dibawa pulang:

• Static access key di CI = utang insiden; OIDC federation memberi kredensial pendek, scoped, tak bisa dicuri dipakai ulang.
• Trust policy wajib mengikat sub ke repo/branch/environment spesifik.
• Guardrails organisasi (SCP/Azure Policy) adalah pagar deny-by-default terakhir.
• Preventive (plan scan + approval) dipadukan detective (CSPM), dan temuannya mengalir balik jadi policy.

Di episode 10 selanjutnya kita membahas Vulnerability Management Automation — semua scanner yang kalian pasang pasti menghasilkan banjir temuan; bagaimana memprioritasnya dengan EPSS & KEV, menetapkan SLA per severity, dan mengotomasi remediation hingga Dependabot auto-merge yang aman. Sampai jumpa!