Belajar GitOps dengan ArgoCD - Security Best Practices

#Pendahuluan

Di episode 22 sebelumnya kita membangun observability penuh — dan observability yang jujur akan mengungkap hal yang kurang nyaman: ArgoCD memegang kunci yang sangat besar. Ia menyimpan kredensial repo, kredensial cluster, dan bisa menerapkan resource apa pun ke cluster mana pun. Sebuah ArgoCD yang diretas adalah cluster yang diretas. Pada episode ini kita membahas security best practices, dari autentikasi sampai keamanan supply chain, untuk memastikan kunci itu hanya dipakai oleh mereka yang berhak.

Mengapa ini penting? ArgoCD adalah single point of control — justru itu kekuatannya, dan sekaligus permukaan serang terbesarnya. Model zero trust mulai berlaku di sini: berikan akses paling kecil yang cukup, verifikasi identitas lewat SSO, dan jangan percaya image begitu saja. Setiap lapisan yang kita tambahkan di episode ini menaikkan biaya serangan, dan dalam keamanan, biaya serangan yang tinggi adalah pertahanan terbaik.

#Autentikasi

Langkah pertama adalah menjawab pertanyaan "siapa kamu?". ArgoCD menyediakan beberapa mekanisme.

#Built-in Authentication dan SSO

User built-in (admin dan yang dibuat lewat argocd-cm) cukup untuk lab, bukan untuk tim. Untuk production, sambungkan penyedia identitas perusahaan:

Konfigurasi SSO dilakukan di argocd-cm, dan karena ArgoCD itu sendiri dikelola GitOps, argocd-cm sebaiknya menjadi manifest di repo:

argocd-cm - SSO OIDC dengan Okta

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
  namespace: argocd
data:
  url: https://argocd.org.dev
  oidc.config: |
    name: Okta
    issuer: https://org.okta.com
    clientID: <client-id>
    clientSecret: $oidc.okta.clientSecret
    requestedScopes: ["openid", "profile", "email", "groups"]
  accounts.andri: login
  accounts.andri.enabled: "true"

Kunci praktik terbaik di sini: nonaktifkan login lokal begitu SSO berjalan. Pertahankan hanya akun admin darurat, simpan password-nya di vault, dan rotasi saat digunakan. Login lokal yang tetap aktif adalah pintu belakang yang tidak butuh SSO.

#Otorisasi: RBAC

Autentikasi menjawab "siapa"; otorisasi menjawab "boleh apa". Model RBAC ArgoCD terdiri dari tiga lapis:

1. Policy global (argocd-rbac-cm) — memetakan user/group ke peran.
2. Built-in roles — role:admin (penuh), role:readonly, role:ci.
3. Project roles — peran per project dengan scope sumber/destinasi sendiri (episode 10).

argocd-rbac-cm - policy RBAC

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
data:
  policy.csv: |
    p, role:readonly, applications, get, */*, allow
    p, role:readonly, clusters, get, *, allow
    g, andri, role:readonly
    g, dev-platform, role:admin
  policy.default: role:readonly

Baris penting terakhir: policy.default: role:readonly. Default deny akan membuat semua user yang tidak punya peran hanya bisa melihat — perubahan destructive membutuhkan peran eksplisit. Ini sesuai prinsip least privilege: berikan akses minimal, naikkan saat dibutuhkan.

#Project-Level RBAC

Project roles adalah cara menyerahkan sebagian kontrol tanpa menyerahkan segalanya. Buat role di project:

Buat project role

argocd proj role add-role api api-deployer
argocd proj role add-policy api api-deployer \
  --action sync --permission allow --object '*'
argocd proj role generate-token api api-deployer

Token yang dihasilkan adalah JWT yang bisa dipakai CI untuk argocd app sync pada project api saja — tanpa pernah memegang kredensial admin.

#Keamanan API

API ArgoCD adalah permukaan serang: ia menerima kredensial, token, dan perintah. Praktik yang wajib:

• JWT dengan masa berlaku. Token project role dan argocd token harus punya exp — hindari token abadi. Rotasi saat ada anggota tim keluar.
• Service account untuk mesin. CI tidak boleh login sebagai admin. Buat user khusus CI, beri project role minimal (hanya sync), dan pakai token tersebut di pipeline.
• TLS wajib. Semua akses melewati HTTPS. Hentikan layanan API server di port HTTP non-TLS di production.
• Rate limiting di depan. Taruh ArgoCD di belakang gateway (Ingress NGINX, API gateway) dengan limit request per IP dan per user, untuk memperlambat brute force.

argocd login argocd.org.dev --sso
argocd account generate-token --account ci-bot
argocd app sync api --auth-token <token>

#Keamanan Jaringan

#TLS dan Manajemen Sertifikat

Akses UI dan API harus dienkripsi end-to-end. Gunakan Ingress dengan sertifikat dari cert-manager, dan pastikan argocd-server berjalan di baliknya dengan --server.insecure=false (default). Untuk repo Git:

#SSH Keys vs HTTPS Tokens

Untuk repo privat, deploy key SSH read-only adalah pilihan paling aman untuk ArgoCD: ArgoCD hanya perlu membaca. Simpan key sebagai repository secret di ArgoCD (terenkripsi), dan jika kalian memakai CI yang menulis manifest, gunakan PAT terpisah dengan scope minimal dan masa berlaku pendek.

#Network Policies

ArgoCD harus bisa menjangkau Git dan cluster, tetapi tidak ada alasan pod lain menjangkau ArgoCD. Terapkan NetworkPolicy yang membatasi:

NetworkPolicy - hanya ingress ke argocd-server

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: argocd-server-allow-ingress
  namespace: argocd
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: argocd-server
  policyTypes: [Ingress]
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app.kubernetes.io/name: argocd-server

#Supply Chain Security

Lapisan terakhir: memastikan apa yang berjalan di cluster benar-benar yang tim maksudkan.

#Verifikasi Tanda Tangan Image

Dengan cosign, image ditandatangani saat CI. ArgoCD Image Updater (episode 16) atau admission controller bisa memverifikasi tanda tangan sebelum pod diizinkan berjalan. Contoh verifikasi dengan Kyverno:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-image-signature
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-cosign
      imageVerification:
        authorities:
          - name: org-cosign
            keyless:
              subject: "ci@org.dev"
              issuer: "https://token.actions.githubusercontent.com"
      match:
        resources:
          kinds:
            - Pod

#Admission Controllers dan Policy Enforcement

OPA/Gatekeeper dan Kyverno memblokir manifest yang melanggar kebijakan — misalnya image tanpa tag, resource tanpa limits, atau hostPath. Kombinasikan dengan GitOps: kebijakan dijalankan sebagai admission webhook saat ArgoCD menerapkan resource, sehingga manifest buruk tertolak sejak awal.

#Vulnerability Scanning

Scan image di CI (Trivy, dari episode 18) adalah pertahanan pertama; scan lanjutan di cluster dengan ArgoCD Image Updater + Cosign atau controller yang memeriksa image registry secara berkala adalah lapisan kedua. Aturan yang sehat: CI gagal pada CVE critical, admission controller memblokir image yang tidak ditandatangani, dan kebijakan memaksa setiap image punya digest.

#Penutup

Episode ini menutup ArgoCD dari luar ke dalam: autentikasi dengan SSO/OIDC/Dex dan nonaktifnya login lokal, RBAC berlapis dengan default deny dan project roles, keamanan API dengan JWT berumur dan service account CI, keamanan jaringan dengan TLS, deploy key read-only, dan NetworkPolicy, serta supply chain security dengan tanda tangan cosign, Kyverno, dan vulnerability scanning.

Poin yang harus kalian bawa:

• ArgoCD adalah kunci besar; sempitkan pemegangnya dengan SSO dan least privilege.
• policy.default: readonly menjadikan perubahan destructive sebuah pilihan eksplisit.
• CI memakai token project role berumur pendek, bukan akun admin.
• Repo privat diakses dengan deploy key read-only; token tulis terpisah dan berumur pendek.
• Image harus ditandatangani, diskalakan kebijakan, dan dipindai sebelum berjalan.

Keamanan yang baik menghasilkan satu aset lain yang tak kalah penting: bukti. Di episode 24 selanjutnya kita membahas compliance & audit — audit trail, persyaratan SOC 2, HIPAA, dan PCI-DSS, pelaporan, serta policy as code. Sampai jumpa di episode 24!