pg_hba.conf

Chapter authentication memperkenalkan delapan metode pemeriksaan identitas, tetapi tidak satu pun metode itu dipilih lewat SQL. Semuanya dipanggil berdasarkan nama dari satu file teks: pg_hba.conf, gerbang pertama yang dilewati setiap koneksi sebelum diperbolehkan menyentuh database. Kesalahan menulis file ini punya dua wajah — server bisa menolak seluruh aplikasi karena satu baris salah alamat, atau sebaliknya membuka pintu lebih lebar dari yang dimaksud tanpa pesan peringatan apa pun. Server latihan kita menjalankan file yang pendek dan tetap, sehingga kita bisa membaca isinya secara nyata lewat view pg_hba_file_rules — dan dari situ membedah anatomi barisnya, urutan pencocokan yang membuat baris pertama selalu menang, kata kunci khususnya, sampai prosedur memuat ulang yang wajib setelah setiap penyuntingan.

Anatomi Satu Baris Aturan #

Setiap baris non-komentar di pg_hba.conf terdiri atas lima kolom yang dipisah spasi atau tab. Kolom type menentukan jalur koneksi, database dan user menyaring tujuan dan identitas, address membatasi asal jaringan, dan method memilih metode authentication dari chapter sebelumnya:

Contoh tampilan umum di server produksi — beginilah file itu biasa ditata, dari aturan paling spesifik ke paling longgar:

# TYPE      DATABASE    USER          ADDRESS         METHOD
local       all         postgres                      peer
local       all         all                           scram-sha-256
host        penjualan   app_web       10.0.0.0/24     scram-sha-256
hostssl     penjualan   app_laporan   0.0.0.0/0       scram-sha-256
host        all         all           0.0.0.0/0       reject

Notasi 10.0.0.0/24 berarti “seluruh alamat dari 10.0.0.0 sampai 10.0.0.255”. Format pasangan IP–netmask juga sah — 10.0.0.0 255.255.255.0 maknanya sama — tetapi CIDR lebih ringkas dan lebih sulit salah tulis. Baris local selalu mengosongkan kolom address karena unix socket tidak punya alamat jaringan.

Membaca Aturan Aktif: pg_hba_file_rules #

Menyunting pg_hba.conf tidak boleh menebak: sebelum dan sesudah mengubah, bacalah kembali hasil parsingnya. View pg_hba_file_rules menampilkan isi file persis seperti yang diparse server — termasuk kolom error yang terisi bila ada baris yang gagal diparse. Satu sifat pentingnya: view membaca isi file saat query dijalankan, bukan salinan aturan yang sudah dimuat, sehingga view ini bisa memeriksa tampilan suntingan bahkan sebelum reload dijalankan. Query berikut dijalankan di server latihan kita dan hasilnya adalah file yang benar-benar sedang terbaca:

-- Membaca kembali seluruh aturan pg_hba.conf yang aktif di server:
-- view pg_hba_file_rules memuat hasil parsing file oleh server.
-- Hanya superuser yang boleh membacanya.
SELECT rule_number, type, database, user_name, address, netmask,
       auth_method, error
FROM pg_hba_file_rules
ORDER BY rule_number;

Output yang Dihasilkan:

 rule_number | type  |   database    | user_name |  address  |                 netmask                 | auth_method | error 
-------------+-------+---------------+-----------+-----------+-----------------------------------------+-------------+-------
           1 | local | {all}         | {all}     |           |                                         | trust       | 
           2 | host  | {all}         | {all}     | 127.0.0.1 | 255.255.255.255                         | trust       | 
           3 | host  | {all}         | {all}     | ::1       | ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff | trust       | 
           4 | local | {replication} | {all}     |           |                                         | trust       | 
           5 | host  | {replication} | {all}     | 127.0.0.1 | 255.255.255.255                         | trust       | 
           6 | host  | {replication} | {all}     | ::1       | ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff | trust       | 
(6 rows)

Enam baris hasil itu adalah konfigurasi latihan kita secara utuh. Mari kita baca satu per satu:

1. Aturan 1 — local untuk all database dan all role dengan trust: inilah yang membuat psql kita terhubung lewat unix socket tanpa sandi, sebagaimana dibuktikan di chapter authentication.
2. Aturan 2 dan 3 — host untuk koneksi TCP dari 127.0.0.1 dan ::1 (localhost versi IPv4 dan IPv6). netmask 255.255.255.255 dan panjangnya ffff:...:ffff adalah bentuk penuh dari /32 dan /128: tepat satu alamat.
3. Aturan 4 sampai 6 — tiga aturan pertama diulang untuk database khusus replication, jalur yang dipakai koneksi physical replication seperti pg_basebackup dan standby server.
4. Kolom error yang kosong — seluruh baris lolos parsing. Bila satu baris salah tulis, kolom ini akan memuat pesan galat dan baris tersebut diabaikan; karena itu query ini layak menjadi pemeriksaan otomatis setelah migrasi konfigurasi.

Perhatikan juga bahwa kolom database dan user_name ditampilkan sebagai array — {all}, {replication} — karena satu baris memang boleh memuat beberapa nama sekaligus.

Urutan Pencocokan: Baris Pertama yang Cocok Menang #

Aturan dievaluasi dari atas ke bawah, dan evaluasi berhenti pada kecocokan pertama — baris di bawahnya tidak pernah dibaca untuk koneksi itu. Sifat ini membuat urutan baris sama pentingnya dengan isinya. Contoh klasik kesalahan urutan:

# TYPE      DATABASE    USER          ADDRESS         METHOD
host        all         all           192.168.1.0/24  scram-sha-256
host        penjualan   admin_laporan 192.168.1.5/32  trust

Niat penulisnya jelas: mesin 192.168.1.5 milik admin_laporan boleh masuk tanpa sandi. Kenyataannya, koneksi dari 192.168.1.5 dicocokkan lebih dulu oleh baris pertama — host all all 192.168.1.0/24 — sehingga admin_laporan tetap dimintai sandi SCRAM; baris kedua tidak pernah tersentuh. Penyusunan yang benar membalik urutannya: aturan spesifik (/32, role tunggal) di atas, aturan umum di bawah.

local, host, hostssl, hostnossl #

Kolom type memutuskan jalur mana yang ditangani satu baris. Perbedaannya menentukan apakah TLS bisa diwajibkan, karena unix socket tidak melalui jaringan sama sekali:

Pemisahan hostssl inilah alat untuk memaksa enkripsi lewat pg_hba.conf: cukup pastikan tidak ada baris host atau hostnossl yang bisa dicocokkan klien yang sama, maka satu-satunya jalan masuk adalah koneksi TLS — bahasan lengkapnya di chapter TLS dan Koneksi Aman .

Kata Kunci Khusus #

Kolom database dan user menerima lebih dari sekadar nama. Sejumlah kata kunci memberi makna khusus, dan mengutip salah satunya — misalnya "all" — membuat kata itu kehilangan makna khususnya dan dicocokkan sebagai nama biasa:

Kata kunci +nama_role layak digarisbawahi karena sering dipakai untuk role kelompok: baris host penjualan +tim_penjualan 10.0.0.0/24 scram-sha-256 mengizinkan seluruh anggota grup tim_penjualan tanpa perlu mendaftar satu per satu, dan penambahan anggota baru cukup lewat GRANT tim_penjualan TO ... tanpa menyentuh pg_hba.conf lagi. Daftar comma-separated juga sah pada kedua kolom — db1,db2 memilih dua database sekaligus.

Menyunting dan Memuat Ulang #

Server membaca pg_hba.conf saat start dan setiap kali menerima sinyal SIGHUP. Penyuntingan file di sistem yang sedang berjalan karena itu tidak otomatis berlaku — koneksi baru masih dilayani dengan aturan lama sampai server diminta membaca ulang. Tiga cara lazim untuk itu, semuanya tanpa memutus koneksi yang sedang aktif:

# cara 1: pg_ctl dari shell
pg_ctl reload -D /path/ke/pgdata

# cara 2: kirim SIGHUP langsung ke proses postmaster
kill -HUP <pid_postmaster>

Cara ketiga bisa dijalankan dari dalam SQL oleh superuser, dan kita uji nyata di server latihan karena pg_reload_conf() hanya memerintahkan pembacaan ulang — bukan mengubah konfigurasi:

-- Memuat ulang konfigurasi tanpa memutus koneksi yang sedang aktif:
-- pg_reload_conf() mengirim sinyal SIGHUP ke server.
SELECT pg_reload_conf();

-- Setelah muat ulang, jumlah aturan tetap enam karena isi
-- file pg_hba.conf memang tidak berubah.
SELECT count(*) AS jumlah_aturan
FROM pg_hba_file_rules;

Output yang Dihasilkan:

 pg_reload_conf 
----------------
 t
(1 row)

 jumlah_aturan 
---------------
             6
(1 row)

Nilai balik t berarti sinyal terkirim, dan penghitungan ulang mengkonfirmasi keenam aturan masih utuh — file kita memang tidak diubah. Prosedur lengkap setiap perubahan konfigurasi karenanya selalu tiga langkah: sunting file, reload, lalu verifikasi lewat pg_hba_file_rules — dan satu langkah terakhir yang tak boleh dilewat: uji koneksi baru dari klien yang benar-benar dimaksudkan berubah, karena reload tidak memberi tahu Anda bila aturan baru tidak berperilaku seperti dugaan.

Kesalahan Umum #

Satu catatan penutup untuk pengguna Windows: di sistem itu perubahan pg_hba.conf langsung berlaku bagi koneksi baru tanpa perlu reload, sehingga kebiasaan memuat ulang boleh dilewat — tetapi di Linux, tempat mayoritas server PostgreSQL berjalan, tiga langkah sunting–reload–verifikasi tetap wajib.

Enam baris pg_hba.conf di server kita menunjukkan satu hal yang belum dibahas: tidak ada satu pun baris hostssl, dan memang parameter ssl di server ini masih off. Koneksi TCP yang kita jalankan sejauh ini berjalan tanpa enkripsi. Chapter berikutnya menyalakannya: cara kerja TLS di PostgreSQL, parameter sslmode dari sisi klien, dan bagaimana memastikan jalur koneksi aplikasi ke database benar-benar terenkripsi.

Referensi #

• The pg_hba.conf File
• pg_hba_file_rules
• pg_ctl

-- Membaca kembali seluruh aturan pg_hba.conf yang aktif di server:
-- view pg_hba_file_rules memuat hasil parsing file oleh server.
-- Hanya superuser yang boleh membacanya.
SELECT rule_number, type, database, user_name, address, netmask,
       auth_method, error
FROM pg_hba_file_rules
ORDER BY rule_number;

-- Memuat ulang konfigurasi tanpa memutus koneksi yang sedang aktif:
-- pg_reload_conf() mengirim sinyal SIGHUP ke server.
SELECT pg_reload_conf();

-- Setelah muat ulang, jumlah aturan tetap enam karena isi
-- file pg_hba.conf memang tidak berubah.
SELECT count(*) AS jumlah_aturan
FROM pg_hba_file_rules;