Belajar GitOps dengan ArgoCD - Projects & Multi-Tenancy

#Pendahuluan

Di episode 9 sebelumnya kita mendaftarkan banyak cluster ke satu ArgoCD dan menempatkan aplikasi ke destination manapun. Itu hebat, tapi ada satu pertanyaan besar yang belum terjawab: siapa yang boleh deploy ke mana? Jika semua orang dengan akses ArgoCD bisa men-deploy ke cluster production, satu kesalahan ketik bisa menjatuhkan layanan. Pada episode ini kita membahas ArgoCD Projects — mekanisme isolasi dan kontrol akses yang mengubah ArgoCD dari tool pribadi menjadi platform multi-tenancy yang aman.

Mengapa ini penting? Di perusahaan sungguhan, ArgoCD dipakai bersama banyak tim. Tim A tidak boleh mengubah konfigurasi tim B; tim frontend tidak boleh deploy ke cluster data center; dan developer baru tidak boleh menyentuh production. Projects adalah tembok pemisah itu — sekaligus fondasi dari pola operasional yang akan kita pakai di semua episode selanjutnya, termasuk ApplicationSet di episode 11.

#Apa itu ArgoCD Project?

Project (AppProject) adalah pengelompokan logis Application dengan batasan (restriction) dan siapa yang boleh mengoperasikannya. Setiap Application wajib berada di dalam satu project — jika tidak ditentukan, ia masuk ke project bawaan bernama default.

#Project Default

Project default sudah ada sejak instalasi dan dipakai semua Application yang tidak menyebutkan project. Batasannya minimal: ia mengizinkan semua source repository dan semua destination. Ini tidak aman untuk tenancy — best practice di lingkungan produksi adalah membiarkan default kosong dan mewajibkan tiap Application menyebutkan project yang jelas.

#Membuat Project Sendiri

Ada dua cara: deklaratif (manifest YAML di Git — paling cocok untuk GitOps) atau CLI:

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: team-billing
  namespace: argocd
spec:
  sourceRepos:
    - "https://github.com/devnull/billing-repo.git"
  destinations:
    - server: "https://kubernetes.default.svc"
      namespace: "billing-*"
    - server: "https://eks-prod.example.com"
      namespace: "billing-*"
  clusterResourceWhitelist:
    - group: ""
      kind: Namespace

argocd proj create team-billing \
  --src https://github.com/devnull/billing-repo.git \
  --dest https://kubernetes.default.svc,billing-prod \
  --description "Project milik tim billing"

Cara deklaratif lebih disukai dalam GitOps karena project-nya sendiri ikut versioned di Git — konsisten dengan prinsip "semuanya dari Git".

#Pembatasan Project

Inti dari Project adalah restriction. Ada lima jenis pembatasan utama:

#Whitelist Source Repository

sourceRepos menentukan Git repository mana yang boleh dipakai Application di dalam project. Kosongkan untuk menolak semua source (project "kosong"), atau daftarkan URL yang diizinkan. Wildcard didukung, tapi gunakan dengan hati-hati.

#Whitelist Destination Cluster & Namespace

destinations membatasi kombinasi cluster dan namespace tujuan. Perhatikan pola billing-* di contoh tadi — ArgoCD mendukung wildcard pada namespace, sehingga project ini bisa men-deploy ke namespace billing-dev, billing-staging, billing-prod, tapi tidak ke namespace tim lain.

#Whitelist / Blacklist Resource Types

• clusterResourceWhitelist — resource level cluster yang boleh dikelola (misal hanya Namespace).
• clusterResourceBlacklist — resource level cluster yang dilarang (misal ClusterRole, PersistentVolume).
• namespaceResourceBlacklist — resource dalam namespace yang dilarang (misal ServiceAccount yang terlalu kuat).

Ini garis pertahanan kedua: meski sumber manifest di Git "aman", resource yang berbahaya tetap dicegat oleh project.

#Pola Multi-Tenancy

Cara memodelkan project bergantung pada kebutuhan organisasi. Tiga pola umum:

Team-based paling umum: tiap tim punya project dengan repository dan destination miliknya sendiri. Environment-based membantu memisahkan permission production dari development — misalnya hanya lead yang punya akses ke project *-prod. Kombinasi juga sah: project team-billing-prod dan team-billing-dev memberi granularity dua sumbu sekaligus.

#Project Roles & JWT

Project juga bisa memiliki roles dengan kebijakan RBAC sendiri — cara yang tepat memberi akses CLI tanpa membagikan kredensial admin.

#Membuat Role dan Policy

argocd proj role create team-billing deployer
argocd proj role add-policy team-billing deployer \
  --action get --permission allow --object "*"
argocd proj role add-policy team-billing deployer \
  --action sync --permission allow --object "*"

Policy menggunakan format RBAC ArgoCD: p, <role>, <resource>, <action>, <object>. Dengan dua baris di atas, role deployer bisa melihat dan me-sync semua Application milik project team-billing.

#Token JWT untuk Akses CLI

Setiap role bisa menerbitkan JWT token yang dipakai untuk login CLI dengan hak terbatas pada project itu saja:

argocd proj role create-token team-billing deployer
argocd login argocd.example.com --auth-token <TOKEN>
argocd app list

Dengan token ini, argocd app list hanya menampilkan Application di project team-billing — bukan seluruh cluster. Ini pola yang tepat untuk mengintegrasikan ArgoCD ke CI/CD pipeline: tiap pipeline memakai token project miliknya, bukan admin.

#Resource Quotas

Project ArgoCD tidak punya mekanisme quota bawaan — quota resource sebenarnya dijalankan oleh Kubernetes ResourceQuota di namespace tujuan:

resourcequota.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: billing-quota
  namespace: billing-prod
spec:
  hard:
    requests.cpu: "8"
    requests.memory: 16Gi
    limits.cpu: "16"
    limits.memory: 32Gi
    persistentvolumeclaims: "4"

Kombinasi yang benar: Project membatasi apa yang boleh di-deploy (repository, destination, resource kinds), sedangkan ResourceQuota membatasi berapa besar resource yang boleh dipakai. Keduanya saling melengkapi — ResourceQuota juga mencegah satu tim menghabiskan seluruh kapasitas cluster.

#Kesalahan Umum (Common Pitfalls)

1. Mengandalkan project default. Project bawaan longgar dan terbuka; di produksi, kosongkan dan wajibkan project eksplisit.
2. Wildcard terlalu lebar. sourceRepos: ["*"] atau namespace * menghancurkan tujuan isolasi. Selalu daftarkan yang spesifik.
3. Role dengan akses *. Policy --object "*" memberi akses penuh ke semua Application dalam project. Bila perlu, batasi object dengan pola nama.
4. Token tanpa masa berlaku. JWT yang tidak pernah kedaluwarsa adalah risiko keamanan. Selalu pasang --expires-in.
5. Lupa blacklist resource berbahaya. Tanpa clusterResourceBlacklist, manifest yang dikelola bisa memuat ClusterRole dengan hak tinggi. Definisikan blacklist untuk resource yang berisiko.

#Penutup

Episode ini menjadikan ArgoCD platform yang bisa dipakai banyak tim: konsep Project dan project default, pembatasan source repository, destination cluster/namespace, whitelist/blacklist resource, pola tenancy team/environment/application-based, project roles dengan token JWT untuk akses CLI, serta kolaborasi dengan ResourceQuota Kubernetes.

Poin yang harus kalian bawa:

• Project adalah unit isolasi logis yang mewajibkan setiap Application berada di dalamnya.
• sourceRepos dan destinations adalah dua pembatas terpenting — whitelist selalu lebih baik daripada membiarkan terbuka.
• Roles + JWT token memungkinkan akses CLI terbatas per project, ideal untuk CI/CD.
• Project membatasi apa yang boleh di-deploy; ResourceQuota membatasi berapa besar resource-nya.
• Project deklaratif di Git membuat kebijakan tenancy ikut versioned.

Mengelola project dan Application secara manual masih melelahkan jika jumlahnya puluhan. Di episode 11 selanjutnya kita membahas ApplicationSets - Advanced Application Management: cara mendefinisikan templat Application yang digenerasi otomatis dari list, cluster, Git, dan Pull Request — otomasi yang mengubah 100 Application menjadi satu file. Sampai jumpa di episode 11!