Belajar Jenkins - Jenkins Security, RBAC & Authentication

#Pendahuluan

Di episode 10 sebelumnya kita membahas cara menyimpan build artifact dan mengelola workspace antar agent. Namun ada satu pertanyaan yang belum kita jawab: siapa saja yang boleh masuk dan berbuat apa di Jenkins kalian?

Jenkins sering kali dibiarkan berjalan dengan pengaturan default yang sangat permisif, termasuk anonymous read access. Dalam kondisi ini, siapa pun yang tahu alamat Jenkins kalian — termasuk orang asing di internet — bisa membaca daftar job, membuka konfigurasi, bahkan melihat isi workspace berisi kode sumber dan secret. Bayangkan kantor dengan pintu terbuka lebar dan semua dokumen di atas meja bisa dibaca tanpa izin; itu gambaran controller yang tidak diamankan.

Di episode ini kita akan menutup celah tersebut satu per satu: mematikan akses anonim, memilih skema autentikasi, menerapkan Role-Based Authorization Strategy (RBAC), lalu mengamankan eksekusi script Groovy lewat Script Security dan Groovy Sandbox. Topik ini wajib dikuasai sebelum Jenkins kalian menyentuh jaringan produksi.

#Pembahasan Utama

#Autentikasi Berbeda dengan Authorization

Sebelum masuk ke pengaturannya, ingat dua konsep yang sering tertukar:

• Autentikasi menjawab pertanyaan "siapa kamu?" — proses verifikasi identitas, misalnya lewat user database atau LDAP.
• Authorization menjawab pertanyaan "apa yang boleh kamu lakukan?" — proses menentukan hak akses setelah identitas diketahui.

#Level 1: Matikan Anonymous Read Access

Langkah paling mendasar ada di Manage Jenkins > Security. Centang opsi Disable anonymous read access agar pengunjung tanpa login tidak bisa melihat apa pun.

Selanjutnya atur strategi authorization. Untuk lab atau percobaan, pilih Logged-in users can do anything — semua user terautentikasi memiliki akses penuh. Ini memang lebih aman daripada default, tetapi terlalu lebar untuk produksi; kita akan naik level ke RBAC di bagian berikutnya.

#Level 2: Pilih Skema Autentikasi

Jenkins menyediakan beberapa cara untuk memverifikasi identitas user. Pilihan terbaik tergantung skala organisasi kalian:

Semua skema ini dipilih di Manage Jenkins > Security > Global Security pada bagian Security Realm. Di episode 12 kita akan membahas satu turunan OAuth 2.0, yaitu OIDC, untuk autentikasi passwordless ke cloud.

#Level 3: RBAC dengan Role-Based Authorization Strategy

Setelah autentikasi, terapkan Role-Based Authorization Strategy lewat plugin Role-based Authorization Strategy. Plugin ini memisahkan hak akses menjadi tiga lingkup:

• Global roles — hak di level controller, misalnya Overall/Administer, Overall/Read, Overall/Configure.
• Item roles — hak per job atau project, biasanya dicocokkan dengan pola nama seperti my-app-*.
• Agent roles — hak untuk mengelola node agent.

Cara aktivasi: install plugin, lalu di Manage Jenkins > Security > Global Security pilih Role-Based Strategy sebagai authorization, dan klik Save. Berikutnya menu Manage and Assign Roles muncul untuk mendefinisikan peran. Contoh pemetaan peran yang umum di tim pengembangan:

Dengan pola ini, Tester bisa menjalankan build dan membaca hasilnya tetapi tidak bisa mengubah konfigurasi job, sementara Developer yang tidak diberi hak Overall/Administer pun tetap bisa mengerjakan projectnya. Setiap user atau grup kemudian di-assign ke peran tertentu melalui halaman Assign Roles.

#Level 4: Script Security & Groovy Sandbox

Pipeline Jenkins berjalan dalam Groovy Sandbox secara default. Sandbox membatasi kode agar tidak bisa memanggil metode berbahaya di luar area yang diizinkan. Jika sebuah pipeline mencoba memanggil metode yang tidak diizinkan, eksekusi dihentikan dan Jenkins meminta admin menyetujui script tersebut. Contoh kode yang memicu proses approval:

Pipeline yang butuh approval

stage('Cek Kapasitas Agent') {
    steps {
        script {
            def node = hudson.model.Hudson.instance.getNode('linux-runner')
            println "Total executors: " + node.getNumExecutors()
        }
    }
}

Pemanggilan hudson.model.Hudson.instance adalah static method yang dianggap sensitif, sehingga pipeline berhenti dengan error dan menampilkan pesan seperti:

Scripts not permitted to use: staticMethod hudson.model.Hudson getInstance
org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException:
    Scripts not permitted to use: staticMethod hudson.model.Hudson getInstance

Admin kemudian membuka Manage Jenkins > In-process Script Approval dan memilih Approve atau Deny terhadap signature metode yang ditolak. Setelah disetujui, pipeline berikutnya bisa memanggil metode tersebut tanpa hambatan.

#CSRF Protection

Cross-Site Request Forgery (CSRF) memaksa korban mengirim request tanpa sadar. Sejak Jenkins 2.0, perlindungan CSRF aktif secara default: setiap request POST harus menyertakan crumb token yang dihasilkan per sesi. Saat berinteraksi lewat API, kalian harus mengambil crumb terlebih dahulu lalu mengirimkannya lewat header Jenkins-Crumb:

curl -s -u admin:API_TOKEN \
  -c /tmp/crumb.jar \
  https://jenkins.example.com/crumbIssuer/api/json
 
curl -s -u admin:API_TOKEN \
  -b /tmp/crumb.jar \
  -H "Jenkins-Crumb: <hasil-crumb>" \
  -X POST \
  https://jenkins.example.com/job/my-app/build

#Penutup

Pada episode 11 ini kalian telah belajar mengamankan controller Jenkins dari dalam ke luar: mematikan anonymous read access, memilih skema autentikasi yang sesuai skala tim, menerapkan RBAC dengan Role-Based Authorization Strategy untuk memisahkan peran Admin, Developer, dan Tester, memahami cara kerja Script Security dan Groovy Sandbox beserta proses approval script, serta mengenali perlindungan CSRF yang aktif secara default.

Keamanan tidak berhenti di pengaturan controller. Satu titik yang masih sering bocor adalah kredensial cloud statis — misalnya AWS Access Key yang disimpan permanen di Jenkins Credentials.

Di episode 12 berikutnya kita akan membahas Passwordless Cloud Authentication Menggunakan OIDC — mengganti kredensial statis dengan token berumur pendek agar autentikasi ke AWS, GCP, dan Azure menjadi lebih aman dan bebas password. Sampai jumpa!