GitHub Actions OIDC: Autentikasi Cloud Tanpa Kunci untuk CI/CD

Setiap kredensial cloud jangka panjang yang disimpan sebagai repository secret adalah bom waktu. Kredensial itu tidak kedaluwarsa sendiri, memberikan izin yang sama persis baik saat workflow benar-benar membutuhkannya maupun saat dependency yang disusupi sedang mencuri datanya, dan begitu bocor, seseorang harus menyadarinya, merotasinya, lalu berharap tidak ada kejadian buruk di antaranya. OpenID Connect, atau OIDC, menghilangkan seluruh kategori risiko ini dengan membiarkan workflow GitHub Actions meminta kredensial berumur pendek dan terbatas langsung dari AWS atau Google Cloud saat runtime, tanpa ada secret yang tersimpan sama sekali.

Tulisan ini membahas cara kerja federasi ini secara mendalam, cara menghubungkan AWS IAM dan GCP Workload Identity Federation dari awal, cara membaca dan membatasi subject claim yang disematkan GitHub pada setiap token, serta kesalahan konfigurasi spesifik yang diam-diam mengubah setup tanpa kunci menjadi lebih berbahaya daripada kunci statis yang digantikannya.

Masalah Kunci Cloud Jangka Panjang

Kebanyakan tim yang belum mengadopsi OIDC menyimpan pasangan access key AWS atau file JSON service account GCP sebagai secret terenkripsi di GitHub, lalu mereferensikannya di setiap workflow yang perlu mengakses cloud. Cara ini memang berfungsi, tetapi menumpuk risiko dengan cara yang mudah diremehkan sampai sebuah insiden memaksa masalah ini terungkap.

• Kunci tidak memiliki masa berlaku alami, sehingga kebocoran dari log build, artifact yang salah konfigurasi, atau action pihak ketiga yang disusupi tetap bisa dieksploitasi tanpa batas waktu sampai seseorang merotasinya secara manual.
• Rotasi adalah proses manual yang mengganggu, sehingga sering ditunda oleh tim, akibatnya kunci yang seharusnya hanya berlaku sembilan puluh hari sering bertahan bertahun-tahun.
• Satu kunci biasanya memberikan izin yang sama ke setiap workflow dan setiap branch, sehingga build dokumentasi berisiko rendah bisa memiliki dampak kerusakan yang sama besar dengan deployment produksi.
• Secret scanning bisa menangkap sebagian kebocoran setelah terjadi, tetapi tidak bisa mencegah jendela waktu antara kunci berakhir di tempat yang salah dan saat seseorang menyadarinya.

Cara Kerja Federasi OIDC GitHub Actions

Saat workflow memintanya, penyedia OIDC milik GitHub akan menerbitkan JSON Web Token yang ditandatangani dan menjelaskan secara persis siapa yang meminta: repository mana, branch atau tag mana, environment mana, event apa yang memicu run tersebut, dan jendela validitas singkat yang diukur dalam menit. Token ini bukan secret jangka panjang. Token ini dibuat baru untuk job spesifik tersebut dan kedaluwarsa hampir seketika setelahnya.

Penyedia cloud tidak pernah harus mempercayai GitHub secara membabi buta. Sebaliknya, Anda mengonfigurasi AWS atau GCP terlebih dahulu untuk mempercayai penerbit OIDC GitHub sebagai identity provider, lalu menulis trust policy atau attribute condition yang hanya menerima token dengan claim tertentu, terutama subject claim. Saat workflow berjalan, SDK atau action cloud akan menyerahkan token tersebut, penyedia memverifikasi tanda tangannya terhadap kunci publik yang dipublikasikan GitHub, memeriksa claim terhadap trust policy Anda, dan jika semuanya sesuai, mengembalikan kredensial sementara dan terbatas yang kedaluwarsa dalam satu jam atau kurang.

1. Workflow mendeklarasikan izin id-token write, yang memungkinkan job meminta token OIDC dari penyedia GitHub di token.actions.githubusercontent.com.
2. Sebuah action seperti configure-aws-credentials atau google-github-actions/auth meminta token tersebut dan mengirimkannya ke penyedia cloud beserta role atau service account yang ingin diasumsikan.
3. Penyedia cloud memverifikasi tanda tangan token terhadap JSON Web Key Set publik milik GitHub dan memeriksa claim audience, issuer, dan subject terhadap trust policy yang sudah Anda konfigurasikan sebelumnya.
4. Jika claim tersebut memenuhi kebijakan, penyedia menerbitkan kredensial sementara berumur pendek yang dibatasi pada role atau service account yang Anda tentukan, dan kredensial tersebut digunakan untuk sisa job tersebut.

Menghubungkan GitHub Actions dengan AWS

Menyiapkan AWS dimulai dengan mendaftarkan penerbit OIDC GitHub sebagai identity provider di IAM, menggunakan issuer URL dan thumbprint atau provider GitHub bawaan yang kini otomatis dikenali AWS. Setelah provider tersebut ada, Anda membuat IAM role yang mempercayainya, dan trust policy itulah tempat batas keamanan sesungguhnya berada.

Contoh di bawah membatasi role hanya untuk satu repository dan satu environment deployment bernama production, artinya build pull request dari fork, atau bahkan push ke feature branch di repository yang sama, tidak bisa mengasumsikan role ini. Kondisi audience juga memastikan token benar-benar diterbitkan untuk AWS dan bukan hasil replay dari token yang dibuat untuk provider lain.

{
  "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:my-org/my-repo:environment:production"
        }
      }
    }
  ]
}

Lampirkan trust policy ini ke sebuah IAM role, lalu referensikan ARN role tersebut sebagai role-to-assume pada langkah aws-actions/configure-aws-credentials di workflow Anda, bersama izin id-token write di level job atau workflow. Tidak ada access key, secret key, atau kredensial jangka panjang apa pun yang pernah menyentuh repository secrets Anda.

Menghubungkan GitHub Actions dengan Google Cloud

Google Cloud menggunakan Workload Identity Federation, yang secara konsep serupa tetapi terbagi menjadi tiga bagian: Workload Identity Pool yang berfungsi sebagai wadah untuk identitas eksternal, Workload Identity Provider di dalam pool tersebut yang dikonfigurasi dengan issuer GitHub dan attribute mapping, serta service account yang diizinkan untuk diimpersonasi oleh identitas terfederasi tersebut.

Langkah attribute mapping adalah tempat sebagian besar pekerjaan keamanan berlangsung. Penerbit OIDC GitHub dibagikan ke seluruh organisasi GitHub yang ada, sehingga Google Cloud mewajibkan attribute condition yang menyaring token masuk agar hanya berasal dari organisasi atau repository Anda, jika tidak, repository GitHub mana pun secara teoretis bisa mencoba melakukan federasi ke pool Anda. Kondisi umum memeriksa apakah atribut pemilik repository cocok tepat dengan nama organisasi Anda.

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: google-github-actions/auth@v2
        with:
          workload_identity_provider: projects/123456789/locations/global/workloadIdentityPools/gh-pool/providers/gh-provider
          service_account: deployer@my-project.iam.gserviceaccount.com

      - uses: google-github-actions/setup-gcloud@v2

      - run: gcloud run deploy my-service --region us-central1

Berikan service account role roles/iam.workloadIdentityUser yang dibatasi pada provider spesifik tersebut, lalu referensikan jalur resource provider lengkap dan alamat email service account pada langkah google-github-actions/auth seperti ditunjukkan di atas. Sama seperti AWS, ini menghilangkan kebutuhan untuk pernah membuat, menyimpan, atau merotasi file kunci service account.

Panduan Cepat Subject Claim

GitHub memformat subject claim secara berbeda tergantung apa yang memicu workflow tersebut, dan salah memformat ini adalah alasan paling umum sebuah trust policy diam-diam gagal cocok. Tabel di bawah mencakup format yang paling sering Anda pakai saat membatasi role atau provider pada jenis pemicu tertentu.

Kesalahan Konfigurasi yang Harus Dihindari

Federasi OIDC menghilangkan risiko kunci statis yang bocor, tetapi trust policy yang ceroboh bisa diam-diam menciptakan kembali dampak kerusakan yang sama, atau bahkan lebih buruk, dalam bentuk yang berbeda. Berikut kesalahan yang paling sering muncul dalam audit nyata.

• Menggunakan subject claim dengan wildcard, misalnya mencocokkan semua branch atau semua repository dalam sebuah organisasi, yang secara efektif membiarkan workflow apa pun di repository apa pun mengasumsikan role setingkat produksi.
• Melupakan kondisi audience sepenuhnya, yang berarti token yang dibuat untuk relying party yang sama sekali berbeda secara teoretis bisa direplay terhadap role atau provider Anda.
• Membatasi trust policy berdasarkan nama branch alih-alih environment GitHub yang terlindungi, karena nama branch bisa dibuat oleh siapa pun dengan akses write sementara environment bisa memaksakan reviewer wajib dan pembatasan branch deployment.
• Memberikan role terfederasi atau service account izin yang luas dan berlaku lama alih-alih minimum yang dibutuhkan untuk pipeline spesifik tersebut, yang mengubah batas identitas yang sempit menjadi luas begitu trust policy memiliki celah sedikit pun.
• Mengasumsikan pull request dari repository fork otomatis mendapatkan akses token OIDC yang sama seperti push ke repository dasar, padahal GitHub secara sengaja menahan izin token dan secrets dari sebagian besar run pull request yang berasal dari fork justru karena alasan ini.

Checklist Migrasi

Memindahkan pipeline yang sudah ada dari kunci statis ke OIDC adalah proses mekanis begitu identity provider dan trust policy sudah siap. Ikuti urutan ini untuk menghindari deployment yang gagal di tengah proses migrasi.

1. Buat identity provider OIDC di AWS IAM atau Workload Identity Pool dan Provider di Google Cloud, mengarah ke issuer URL milik GitHub.
2. Tulis trust policy atau attribute condition yang dibatasi secara ketat, hanya cocok dengan repository, branch, tag, atau environment yang benar-benar dibutuhkan pipeline tersebut.
3. Tambahkan izin id-token write ke file workflow dan ganti langkah pengaturan kredensial dengan configure-aws-credentials atau google-github-actions/auth yang dikonfigurasi untuk OIDC.
4. Jalankan workflow yang sudah diperbarui pada branch non-produksi terlebih dahulu dan pastikan penyedia cloud menerbitkan kredensial sementara sebelum menyentuh apa pun yang penting.
5. Setelah jalur OIDC terbukti berfungsi, hapus access key statis atau kunci service account dari penyedia cloud dan hapus secret terkait dari repository.

Autentikasi tanpa kunci bukan hanya peningkatan keamanan, tetapi juga mengurangi beban operasional dalam jangka panjang: tidak ada lagi pengingat rotasi kunci setiap kuartal, tidak ada lagi kebingungan tentang pipeline mana yang memiliki access key tertentu, dan trust policy yang mendokumentasikan secara jelas workflow mana saja yang diizinkan menyentuh resource cloud tertentu.