OIDC Workload Identity Federation: Akses Cloud Tanpa Kunci Permanen

Pipeline CI/CD sering perlu mengakses layanan cloud untuk mengunggah artefak, memperbarui infrastruktur, atau merilis aplikasi. Cara lama yang umum dipakai adalah menyimpan access key jangka panjang sebagai secret di repositori atau sistem CI. Walaupun lebih baik daripada menulis kunci langsung di kode, pendekatan itu tetap menambah pekerjaan rotasi dan risiko kebocoran.

Workload Identity Federation memungkinkan sebuah workload membuktikan identitasnya kepada penyedia cloud melalui identitas tepercaya, misalnya token OpenID Connect (OIDC), lalu menukarnya dengan kredensial berumur pendek. Hasilnya bukan akses tanpa aturan, melainkan akses yang lebih terukur tanpa harus menyimpan kunci permanen di pipeline.

Apa itu OIDC dan Workload Identity Federation?

OpenID Connect adalah lapisan identitas di atas OAuth 2.0. Dalam pipeline, penyedia CI dapat menerbitkan token bertanda tangan yang menyatakan konteks eksekusi, seperti repositori, branch, environment, atau workflow. Token tersebut bukan otomatis kunci cloud; penyedia cloud harus memvalidasi penerbit, tanda tangan, masa berlaku, audience, serta klaim yang menjadi syarat kepercayaan.

Workload Identity Federation adalah mekanisme yang menghubungkan identitas eksternal itu dengan izin di cloud. Setelah token lolos pemeriksaan, layanan identitas cloud dapat memberikan token akses sementara atau mengizinkan workload bertindak sebagai identitas layanan dengan hak terbatas. Implementasinya berbeda antarpenyedia, jadi konfigurasi AWS, Google Cloud, dan platform lain tidak bisa dipertukarkan begitu saja.

Alur kerjanya dalam pipeline CI/CD

1. Workflow dimulai. Sistem CI menjalankan job yang sudah diizinkan meminta token identitas.
2. Token OIDC diterbitkan. Token memuat klaim seperti issuer (iss), audience (aud), subject (sub), dan informasi konteks lain yang disediakan platform.
3. Cloud memvalidasi token. Konfigurasi trust memeriksa penerbit dan klaim yang diperbolehkan. Token dari repositori atau branch yang tidak sesuai harus ditolak.
4. Kredensial sementara diberikan. Workload menukar token atau menggunakan mekanisme federasi yang disediakan cloud untuk memperoleh akses dengan masa berlaku terbatas.
5. Job menjalankan tugas. Izin yang melekat pada identitas menentukan sumber daya mana yang boleh dibaca atau diubah.

Karena kredensial sementara tetap memiliki masa berlaku dan cakupan izin, kompromi satu job tidak semestinya memberi akses permanen. Namun, jika kebijakan trust terlalu luas, penyerang masih dapat menjalankan workflow yang sah secara teknis tetapi tidak semestinya dipercaya.

Contoh penggunaan pada GitHub Actions

Di GitHub Actions, workflow perlu diberi izin untuk meminta token OIDC. Contoh minimum berikut hanya menunjukkan izin pada tingkat job; ini belum cukup untuk mengonfigurasi trust di sisi cloud.

permissions:
  contents: read
  id-token: write

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Autentikasi ke cloud
        run: echo "Letakkan langkah autentikasi resmi penyedia cloud di sini"

Izin id-token: write memungkinkan job meminta token OIDC, tetapi tidak dengan sendirinya memberikan hak untuk mengubah resource cloud. Hak tersebut berasal dari kebijakan IAM atau konfigurasi otorisasi penyedia cloud. Untuk penerapan nyata, ikuti action atau pustaka resmi dari penyedia yang digunakan dan pin action pihak ketiga ke versi atau commit yang ditinjau.

Atur trust policy secara ketat

Kesalahan paling berbahaya adalah mempercayai semua repositori dari sebuah organisasi atau menerima klaim subject tanpa pembatasan. Jika memungkinkan, batasi trust pada kombinasi issuer, audience, repositori, branch atau tag, dan environment yang memang dibutuhkan. Gunakan environment dengan approval untuk deployment produksi bila alur kerja organisasi mendukungnya.

Periksa juga bagaimana penyedia CI membentuk klaim sub. Perubahan nama repositori, pola subject, atau konfigurasi klaim dapat membuat autentikasi gagal; sebaliknya, pola wildcard yang terlalu longgar dapat memperluas pihak yang dipercaya. Uji kebijakan di lingkungan nonproduksi dan pastikan log audit menunjukkan identitas yang benar.

Praktik aman yang perlu diterapkan

• Hak minimum: berikan hanya izin yang diperlukan untuk tugas tertentu, bukan peran administrator penuh.
• Pisahkan lingkungan: gunakan identitas dan trust policy berbeda untuk pengujian dan produksi.
• Batasi durasi: gunakan kredensial sementara dan masa berlaku sesingkat yang masuk akal.
• Jaga workflow: tinjau perubahan file pipeline, batasi siapa yang dapat menjalankan deployment, dan lindungi branch utama.
• Audit: pantau penerbitan token, kegagalan autentikasi, perubahan IAM, serta akses resource yang tidak biasa.
• Hindari output sensitif: jangan mencetak token OIDC, access token, atau berkas kredensial ke log job.

Federasi juga bukan alasan untuk menghapus semua kontrol secret sekaligus. Aplikasi yang tidak mendukung federasi mungkin masih memerlukan secret, dan beberapa integrasi membutuhkan konfigurasi tambahan. Inventarisasi penggunaan kunci lama, migrasikan satu alur pada satu waktu, lalu cabut kunci permanen setelah log membuktikan alur baru bekerja.

Kapan pendekatan ini paling bermanfaat?

Workload Identity Federation sangat berguna untuk pipeline build dan deployment, otomasi infrastruktur, workload lintas-cloud, serta proses yang berjalan di luar lingkungan cloud tujuan. Manfaatnya paling terasa ketika banyak repositori atau job sebelumnya memakai kunci jangka panjang yang perlu disimpan, dibagikan, dirotasi, dan dicabut.

Untuk aplikasi yang berjalan terus-menerus di dalam cloud, identitas bawaan seperti instance role atau workload identity platform bisa lebih sederhana. Pilih mekanisme berdasarkan lingkungan eksekusi, dukungan penyedia, kebutuhan audit, dan kemampuan membatasi hak akses—bukan sekadar karena istilah “keyless” terdengar lebih aman.

Kesimpulan

OIDC Workload Identity Federation mengganti ketergantungan pada kunci cloud jangka panjang dengan proses pembuktian identitas dan kredensial sementara. Keamanan akhirnya bergantung pada ketatnya trust policy, cakupan IAM, perlindungan workflow, serta pemantauan aktivitas. Mulailah dari satu pipeline berisiko rendah, batasi identitas yang dipercaya, verifikasi log audit, lalu perluas penerapan secara bertahap.

Dokumentasi resmi: OpenID Connect di GitHub Actions, Workload Identity Federation Google Cloud, dan OIDC Federation di AWS IAM.

Bacaan terkait: SCIM 2.0.