Belajar Jenkins - Passwordless Cloud Authentication Menggunakan OIDC

#Pendahuluan

Di episode 11 kita mengamankan controller: mematikan akses anonim, memilih skema autentikasi, dan menerapkan RBAC. Namun ada satu celah keamanan yang sering luput: kredensial cloud statis.

Banyak tim menyimpan AWS Access Key, GCP Service Account Key, atau Azure Client Secret secara permanen di Jenkins Credentials. Kredensial semacam itu ibarat master key — berlaku selamanya, tidak pernah berubah, dan begitu bocor, siapa pun bisa menguasai seluruh resource cloud. Risikonya nyata: bot peretas memindai repository dan file publik dalam hitungan menit, dan begitu sebuah key terpublikasi, dampaknya bisa meluas ke lingkungan produksi.

Solusi modernnya adalah OpenID Connect (OIDC). Konsepnya sederhana: Jenkins tidak lagi menyimpan kredensial statis, melainkan meminta token berumur pendek setiap build berjalan, lalu menukarnya dengan kredensial sementara di cloud. Di episode ini kita akan memahami alurnya, mengapa ia lebih aman, dan bagaimana menerapkannya di AWS, GCP, serta Azure.

#Pembahasan Utama

#Masalah Kredensial Statis

Simpan kredensial statis di Jenkins berarti memikul tiga beban sekaligus:

1. Rotasi manual — key tidak pernah berubah sampai seseorang mengingatnya, dan sering kali terlupakan sampai terjadi insiden.
2. Blast radius luas — satu key yang dipakai puluhan job memberi akses ke semua resource yang diizinkannya.
3. Sulit diaudit — tidak ada jejak job mana yang memakai kredensial tersebut saat terjadi kebocoran.

#Konsep OpenID Connect (OIDC)

OIDC dibangun di atas protokol OAuth 2.0 dan memperkenalkan ID Token — sebuah JSON Web Token (JWT) yang berisi klaim seperti issuer, audience, dan subject. Sifat-sifat kunci yang membuatnya cocok untuk CI/CD:

• Berumur pendek — token valid hanya beberapa menit, cukup untuk satu build.
• Tertaut konteks — token dapat dibatasi ke project, branch, atau environment tertentu.
• Tanpa penyimpanan rahasia — tidak ada key permanen di sisi Jenkins maupun cloud.

Jenkins bertindak sebagai OIDC Provider: saat build berjalan, Jenkins menerbitkan ID Token, lalu cloud provider memverifikasi tanda tangan token lewat endpoint JWKS milik Jenkins dan menukarnya menjadi kredensial sementara. Analoginya seperti boarding pass pesawat: berlaku sekali, berisi tujuan spesifik, dan kadaluarsa setelah penerbangan — berbeda dengan kunci ruangan yang berlaku selamanya.

#Alur End-to-End di AWS

Di AWS, pertukaran ini memakai STS AssumeRoleWithWebIdentity. Alurnya:

1. Konfigurasi Jenkins sebagai OIDC provider di IAM (issuer = URL Jenkins).
2. Buat IAM role dengan trust policy yang hanya memperbolehkan token dengan audience dan subject tertentu.
3. Di pipeline, gunakan step withOIDC untuk meminta ID token.
4. AWS CLI menukar token tersebut menjadi kredensial sementara via STS.
5. Semua perintah AWS di dalam blok berjalan tanpa access key permanen.

Contoh trust policy role tersebut:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/jenkins.example.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "jenkins.example.com:aud": "aws-deploy",
          "jenkins.example.com:sub": "repo:my-org/my-app:environment:prod"
        }
      }
    }
  ]
}

Setelah role siap, pipeline cukup meminta token dan menjalankan AWS CLI di dalamnya:

Jenkinsfile - passwordless AWS

pipeline {
    agent { label 'linux-runner' }
    stages {
        stage('Deploy ke AWS Tanpa Password') {
            steps {
                withOIDC(id: 'aws-deploy', provider: 'aws-oidc') {
                    sh 'aws sts get-caller-identity'
                    sh 'aws s3 sync ./dist s3://my-app-bucket --delete'
                }
            }
        }
    }
}

#GCP Workload Identity & Azure Federated Credentials

Di Google Cloud Platform, konsep serupa bernama Workload Identity Federation. Kalian membuat workload identity pool beserta provider OIDC yang menunjuk ke issuer Jenkins, lalu mengimpersonate sebuah service account. Buat pool dan provider-nya dengan gcloud:

gcloud iam workload-identity-pools create jenkins-pool \
  --location=global --display-name="Jenkins Pool"
 
gcloud iam workload-identity-pools providers create-oidc jenkins-provider \
  --location=global --workload-identity-pool=jenkins-pool \
  --issuer-uri="https://jenkins.example.com" \
  --attribute-mapping="google.subject=assertion.sub"

Di Microsoft Azure, gunakan federated identity credentials pada App Registration atau Managed Identity. Setiap federated credential mendefinisikan issuer, subject, dan audience yang harus dipenuhi token dari Jenkins:

az identity federated-credential create \
  --name jenkins-cred \
  --identity-name my-app-id \
  --resource-group rg-prod \
  --issuer "https://jenkins.example.com" \
  --subject "repo:my-org/my-app:environment:prod" \
  --audiences "azure-deploy"

#Mengapa Passwordless Lebih Aman

Mari bandingkan pendekatan lama dan baru secara langsung:

Dengan OIDC, prinsip least privilege berlaku secara alami: setiap job meminta role terendah yang cukup untuk tugasnya, token hanya valid untuk konteks spesifik, dan tidak ada kredensial permanen yang bisa dicuri dan dipakai berulang kali.

#Penutup

Pada episode 12 ini kalian telah memahami mengapa kredensial statis berbahaya bagi pipeline, cara kerja OIDC dengan ID Token berumur pendek, dan bagaimana Jenkins bertindak sebagai OIDC provider yang bertukar token dengan AWS via STS AssumeRoleWithWebIdentity, GCP via Workload Identity, serta Azure via federated identity credentials. Kalian juga melihat bagaimana pendekatan ini menerapkan least privilege secara alami.

Menariknya, hampir semua konfigurasi yang kita lakukan manual lewat UI selama ini — termasuk pengaturan keamanan, RBAC, dan kredensial — sebenarnya bisa ditulis sebagai kode.

Di episode 13 berikutnya kita akan membahas Jenkins Configuration as Code (JCasC): mengelola seluruh controller lewat file jenkins.yaml dan menciptakan Jenkins yang identik dalam hitungan detik. Sampai jumpa!