Panduan OIDC untuk CI/CD SaaS 2026: Login ke Cloud Tanpa Secret Statis (GitHub Actions, AWS, GCP)

OpenID Connect (OIDC) di CI/CD adalah cara modern untuk mengakses cloud tanpa menyimpan secret statis. Alih-alih menaruh akses key di repo atau secrets manager, pipeline (misalnya GitHub Actions) meminta token sementara yang hanya berlaku untuk satu job. Praktik ini direkomendasikan untuk security hardening dan mengurangi risiko kebocoran kredensial.

Mengapa OIDC lebih aman daripada secret statis?

• Token singkat: kredensial berlaku sebentar dan otomatis kedaluwarsa.
• Tanpa duplikasi secret: tidak perlu menyalin akses key ke GitHub Secrets.
• Kontrol granular: cloud memverifikasi klaim (claim) token sehingga akses bisa dibatasi per repo, environment, atau branch.

GitHub menjelaskan bahwa OIDC memungkinkan workflow meminta token langsung dari cloud provider dengan short-lived access token yang terikat pada identitas job tertentu.

Bagaimana alur kerja OIDC di CI/CD?

1. Workflow meminta OIDC token dari GitHub OIDC Provider.
2. Cloud memverifikasi klaim token (misalnya sub, aud, dan repository).
3. Cloud menerbitkan temporary credentials untuk job tersebut.

Implementasi praktis untuk GitHub Actions

1) Siapkan trust policy di cloud

• AWS: buat IAM OIDC provider dan role yang mempercayai GitHub OIDC issuer (lihat dokumentasi IAM OIDC).
• GCP: gunakan Workload Identity Federation agar GitHub menjadi provider dan map claim ke principal.

2) Batasi claim dengan ketat

Contoh strategi pembatasan:

• Izinkan hanya repo tertentu: repo:org/nama-repo:ref:refs/heads/main.
• Gunakan environment protection untuk deployment production.
• Batasi audience (aud) sesuai cloud yang dituju.

3) Konfigurasi workflow

• Tambahkan permission id-token: write pada job.
• Gunakan action resmi cloud (AWS/GCP) yang mendukung OIDC.

Checklist keamanan sebelum produksi

• Minimal privilege: role hanya boleh akses resource yang dibutuhkan.
• Audit log: aktifkan logging untuk token exchange dan akses resource.
• Rotasi otomatis: pastikan pipeline tidak menggunakan key statis sama sekali.
• Branch protection: batasi siapa yang bisa trigger workflow produksi.

Masalah umum dan cara menghindarinya

Token ditolak karena klaim tidak cocok

Biasanya terjadi karena sub atau aud tidak sesuai. Pastikan policy cloud sama persis dengan klaim di token GitHub.

Scope akses terlalu luas

Role yang terlalu permisif berisiko disalahgunakan. Mulailah dari akses minimum dan tambah hanya saat diperlukan.

Kapan OIDC wajib diprioritaskan?

• Pipeline yang mengakses data sensitif (PII, data finansial).
• Deployment otomatis ke production.
• Organisasi yang sedang menerapkan Zero Trust dan audit kepatuhan.

Kesimpulan

OIDC menjadikan CI/CD lebih aman dan lebih mudah dikelola karena menghapus kebutuhan secret statis. Dengan konfigurasi trust yang tepat di AWS atau GCP, tim SaaS bisa memperkuat keamanan pipeline tanpa mengorbankan kecepatan delivery.

Referensi

• GitHub Actions OIDC — konsep dan manfaat OIDC untuk workflow.
• AWS IAM OIDC Identity Provider — pembuatan OIDC provider dan role trust di AWS.
• Google Cloud Workload Identity Federation — federasi identitas workload tanpa service account key.