Belajar GitHub Actions - Passwordless Cloud Authentication Menggunakan OIDC

#Pendahuluan

Di episode 9 kita belajar menyimpan dan memakai secrets dengan aman. Namun ada satu kelas kredensial yang tetap mengkhawatirkan bahkan ketika disimpan sebagai secret: kredensial jangka panjang — AWS Access Key, Service Account JSON GCP, dan sejenisnya. Kredensial semacam ini berlaku berbulan-bulan; begitu bocor, penyerang punya waktu yang sangat panjang untuk memanfaatkannya sebelum kalian sadar dan memutar kuncinya.

Episode 10 ini menjawab masalah tersebut dengan OpenID Connect (OIDC): autentikasi ke cloud tanpa password, tanpa kredensial jangka panjang. GitHub Actions bertindak sebagai identity provider yang menerbitkan token berumur pendek, dan cloud provider cukup mempercayainya. Di episode ini kita akan membongkar konsepnya, lalu mempraktikkannya ke AWS, GCP, dan Azure.

#Pembahasan Utama

#Masalah Long-Lived Credentials

Bayangkan kunci permanen gedung kantor yang disalin ke banyak orang. Setiap kali satu salinan hilang, kalian harus mengganti semua gembok — merepotkan dan mahal. Itulah kondisi menyimpan Access Key AWS di secrets: satu nilai, berlaku lama, tersebar ke banyak repository. Kalau bocor, rotasi harus dilakukan manual, sering terlambat, dan bisa mengunci tim dari sistem.

Selain itu, kredensial jangka panjang butuh distribusi — setiap repository yang perlu deploy harus diberi salinan. Semakin banyak salinan, semakin luas permukaan serangan.

#Konsep OpenID Connect (OIDC)

OIDC memecah siklus itu dengan mengubah arah aliran kredensial:

Saat workflow butuh akses cloud, GitHub Actions (sebagai Identity Provider) menerbitkan JWT token yang berlaku singkat — hitungan menit.
Token itu berisi klaim (claim) tentang siapa yang memintanya: nama repository, branch, dan lain-lain.
Cloud provider memverifikasi tanda tangan token dan mencocokkan klaim-nya dengan kebijakan kepercayaan (trust policy) yang kalian konfigurasi.
Jika cocok, cloud provider menukar JWT tersebut dengan kredensial cloud sementara untuk job ini.

Hasilnya: workflow tidak pernah menyimpan, membaca, atau mengirim kredensial jangka panjang. Yang ada hanya token 15 menit yang lahir dan mati bersama job. Kalau token bocor, masa hidupnya sudah berakhir sebelum berguna.

Note

Agar workflow bisa meminta JWT, job harus mendeklarasikan izin id-token: write — ini adalah bagian dari prinsip least privilege di episode 9. Tanpa izin itu, alur OIDC tidak akan berjalan, dan itu memang disengaja.

#AWS: Trust Policy dan configure-aws-credentials

Untuk AWS, konfigurasinya dua langkah. Pertama, buat IAM Role dan pasang trust policy yang mengizinkan GitHub Actions menukar token. Kuncinya adalah condition sub yang membatasi repository dan branch mana saja yang boleh memakai role tersebut:

Trust policy AWS untuk GitHub Actions

{
  "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"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:devvnull/app:ref:refs/heads/main"
        }
      }
    }
  ]
}

Kedua, di workflow, gunakan aws-actions/configure-aws-credentials@v4 dengan role-to-assume — dan perhatikan, tidak ada lagi aws-access-key-id:

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/deploy-role
          aws-region: ap-southeast-1
      - run: aws s3 sync dist/ s3://devvnull-bucket

Setelah langkah konfigurasi, semua perintah aws di job ini otomatis memakai kredensial sementara hasil tukar token — siap untuk aws s3 sync, aws deploy, atau aws ecr push.

#GCP: Workload Identity Federation

GCP memakai mekanisme yang sama, bernama Workload Identity Federation. Kalian membuat Workload Identity Pool beserta provider OIDC yang mengarah ke GitHub, lalu menghubungkannya ke service account. Di workflow, autentikasi dilakukan oleh google-github-actions/auth@v2:

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@v4
      - id: auth
        uses: google-github-actions/auth@v2
        with:
          workload_identity_provider: projects/123456789012/locations/global/workloadIdentityPools/ci-pool/providers/github-provider
          service_account: ci-deploy@devvnull-prod.iam.gserviceaccount.com
      - run: gcloud compute instances list

Yang perlu disiapkan sekali di sisi GCP: pool + provider workload identity (dengan attribute mapping yang menerjemahkan klaim sub GitHub), lalu grant roles/iam.workloadIdentityUser pada service account untuk principal yang sesuai. Setelah itu, workflow memakai gcloud dan gcloud auth seperti biasa — tanpa file JSON key yang bisa bocor.

#Azure: Federated Credential dengan azure/login

Azure menerapkan pola federated credential pada service principal. Setelah app registration dibuat dan federated credential mengarah ke repository kalian, login dilakukan lewat azure/login@v2 dengan tiga identitas — tidak ada client secret:

steps:
  - uses: azure/login@v2
    with:
      client-id: 00000000-0000-0000-0000-000000000000
      tenant-id: 00000000-0000-0000-0000-000000000000
      subscription-id: 00000000-0000-0000-0000-000000000000

Setelah login, perintah az (misalnya az deploy, az aks get-credentials) langsung memakai kredensial federated tersebut.

Tip

Kunci keamanan OIDC ada di claim sub. Jangan pernah membiarkan trust policy menerima semua repository — persempit ke pola repo:<owner>/<repo>:ref:refs/heads/main untuk role produksi, dan beri role terpisah yang lebih terbatas untuk branch lain atau pull request. Setiap repository dan branch mendapat role dengan izin sekecil mungkin. Ini menerapkan least privilege dari episode 9 pada lapisan cloud.

#Kesalahan Umum

Kesalahan	Gejala	Solusi
Lupa izin `id-token: write`	Job tidak bisa mengambil JWT	Tambahkan `permissions: id-token: write`
Trust policy terlalu longgar	Repository lain bisa memakai role	Perketat claim `sub` per repo dan ref
Role tanpa action terkecil	Hak berlebih pada kredensial sementara	Terapkan izin minimum pada policy role
Menyimpan Access Key lama secara paralel	Masih ada kredensial statis yang bocor	Hapus key, pindah total ke OIDC
Attribute mapping GCP salah	Token ditolak provider	Samakan mapping dengan klaim `sub` GitHub

#Penutup

Dengan OIDC, pipeline kalian mencapai tingkat keamanan yang sebelumnya mustahil dicapai hanya dengan menyembunyikan kredensial:

Kredensial jangka panjang dihapus dari secrets — tidak ada lagi Access Key atau Service Account JSON yang mengancam.
GitHub Actions sebagai IdP menerbitkan JWT berumur pendek yang dipertukarkan ke kredensial cloud sementara.
AWS lewat configure-aws-credentials@v4 + role-to-assume, GCP lewat auth@v2 + workload identity, Azure lewat azure/login@v2.
Claim sub menjadi kunci pembatas: setiap repo, branch, dan environment mendapat role terpisah dengan izin minimal.

Fase keamanan kita selesai. Di episode 11 selanjutnya, kita masuk fase reuse: Reusable Workflows & Composite Actions — mengemas logika pipeline agar tidak diduplikasi ke banyak repository organisasi, memakai prinsip DRY seperti yang kita pelajari di seluruh seri ini. Sampai jumpa di sana!