Autentikasi proxy tepercaya OpenClaw

Autentikasi proxy tepercaya adalah mode untuk gateway yang berada di belakang proxy yang sadar identitas: proxy mengautentikasi orangnya, menambahkan header berisi identitas orang tersebut, dan gateway memercayai header itu, tetapi hanya jika datang dari proxy. Dokumentasinya dibuka dengan peringatan bahwa kesalahan konfigurasi akan mengekspos gateway, dan sebagian besar halamannya berisi daftar pemeriksaan yang membuat kepercayaan itu aman. Berikut daftarnya, sesuai urutan gateway mengevaluasinya.

Kapan dan bagaimana

• Gunakan mode ini di belakang Pomerium, Caddy dengan OAuth, nginx dengan oauth2-proxy, atau forward auth Traefik, di lingkungan kontainer tempat proxy menjadi satu-satunya jalur, atau saat browser mengalami galat WebSocket tidak terotorisasi karena tidak dapat meneruskan token dalam handshake; jangan gunakan saat proxy hanya melakukan terminasi TLS, saat ada jalur yang melewati proxy, saat Anda tidak yakin proxy menghapus header yang diteruskan, atau untuk akses pribadi satu pengguna, yang lebih sederhana dengan tailnet ditambah loopback.
• Alurnya: proxy mengautentikasi pengguna, menambahkan header identitas seperti header forwarded-user, gateway memverifikasi bahwa permintaan datang dari alamat proxy tepercaya, membaca header wajib dan identitas pengguna, lalu memberi otorisasi jika daftar izin pengguna, bila ditetapkan, mencakup pengguna tersebut; konfigurasinya melakukan bind ke jaringan lokal, hanya mencantumkan alamat atau rentang alamat proxy, menetapkan mode autentikasi, header pengguna, header wajib opsional, daftar izin pengguna opsional, loopback yang nonaktif secara default, dan persetujuan perangkat otomatis yang nonaktif secara default.
• Aturan runtime secara berurutan: lalu lintas berbentuk proxy diatribusikan sebelum autentikasi gateway dan harus berasal dari proxy tepercaya dengan header alamat klien yang mengarah ke klien non-loopback, jika tidak, rute yang diautentikasi gateway menolaknya karena atribusi proxy tidak ada; proxy harus menimpa rantai forwarded-for dengan aman, dan header alamat asli hanya diterima jika fallback-nya diaktifkan; sumber loopback ditolak kecuali opt-in bernilai true dan loopback juga tercantum sebagai proxy tepercaya; sumber yang cocok dengan salah satu alamat antarmuka milik host itu sendiri ditolak sebagai pelindung terhadap spoofing, dan penemuan antarmuka yang gagal juga berujung penolakan; kemudian header wajib dan header pengguna harus ada dan tidak kosong, dan daftar izin pengguna harus mencakup pengguna tersebut.
• Bukti header forwarded pada permintaan loopback membuatnya tidak memenuhi syarat untuk fallback kata sandi lokal langsung dan penyaringan berdasarkan identitas perangkat, sementara autentikasi trusted-proxy tetap gagal; klien internal yang tidak melewati proxy menggunakan kata sandi gateway, yang dipilih otomatis oleh perintah status tanpa override URL; daftar proxy tepercaya menerima rentang alamat dalam bentuk biasa maupun bentuk mapped, dan prefiks mapped yang mencakup semua alamat tetap memerlukan opt-in loopback untuk loopback.

Token Gateway tidak dapat menggantikan autentikasi proxy.

Pemberian scope, persetujuan otomatis, dan header scope

Scope identitas memberi pengguna terverifikasi tertentu scope yang hanya berlaku untuk sesi, tanpa memperluas izin perangkat mereka: kuncinya adalah identitas proxy atau login tailnet, email dicocokkan tanpa membedakan huruf besar dan kecil, pemberian tersebut digabungkan dengan scope yang diotorisasi untuk perangkat lalu dibatasi oleh header scope eksplisit, dan koneksi dengan token, kata sandi, atau tanpa autentikasi tidak pernah menerimanya. Persetujuan perangkat otomatis, yang nonaktif secara default, menggunakan identitas proxy sebagai batas persetujuan untuk perangkat operator browser dan native yang baru serta peningkatan scope dengan kunci yang sama: hanya koneksi trusted-proxy dengan identitas tidak kosong yang lolos daftar izin yang memenuhi syarat, koneksi dengan peran node dan peningkatan peran tidak pernah memenuhi syarat, scope yang diminta diiriskan dengan daftar yang dikonfigurasi (read, write, approvals, dan questions jika tidak ditetapkan, tidak pernah diperluas), header scope proxy juga membatasi pemberian yang persisten, dan mencantumkan admin membuat setiap pengguna proxy dapat menerima perangkat dengan akses admin penuh, yang dilaporkan audit keamanan sebagai kritis dan diperingatkan gateway saat startup. Sesi antarmuka kontrol tanpa perangkat tidak dapat mendeklarasikan scope sendiri: daftarnya dikosongkan dan pemberian identitas yang cocok diterapkan; kegagalan karena scope yang hilang setelah koneksi berhasil berarti Anda perlu memuat ulang agar browser menyandingkan identitas perangkatnya. Header scope mendeklarasikan scope jika ada, tidak mendeklarasikan apa pun jika ada tetapi kosong, dan kembali ke set operator default jika tidak ada, sementara rute plugin gateway-auth kembali ke write saja.

TLS, token campuran, dan audit

• Lakukan terminasi TLS sekali saja dan tetapkan header strict transport di tempat itu: di proxy untuk deployment yang menghadap internet dengan gateway di loopback di belakangnya, atau di gateway dengan TLS diaktifkan dan header strict transport security jika gateway melayani HTTPS sendiri; mulailah dengan max age yang pendek, naikkan hanya setelah yakin, tambahkan flag subdomain hanya jika setiap subdomain sudah siap, dan lewati langkah ini untuk pengembangan yang hanya memakai loopback.
• Startup menolak autentikasi trusted-proxy jika token bersama juga dikonfigurasi, karena token akan memungkinkan pemanggil di host yang sama melakukan autentikasi melalui jalur yang berbeda dari identitas yang diverifikasi proxy; hapus token atau ganti modenya, dan ingat bahwa header identitas loopback tetap gagal tertutup dan fallback token memang sengaja tidak didukung.
• Audit keamanan sengaja menandai mode ini sebagai kritis dan memeriksa daftar proxy tepercaya yang tidak ada, header pengguna yang tidak ada, daftar izin pengguna yang kosong, opt-in loopback yang aktif, dan persetujuan perangkat otomatis yang aktif; daftar periksanya menambahkan bahwa proxy harus menjadi satu-satunya jalur, daftar tepercaya dibuat seminimal mungkin, proxy menimpa header forwarded dan membangun ulang rantai forwarded-for, origin yang diizinkan dinyatakan secara eksplisit untuk antarmuka kontrol non-loopback, dan fallback kata sandi lokal apa pun tetap privat di balik firewall.

Scope operator OpenClaw menjelaskan model scope yang diisi oleh pemberian ini, dan OpenClaw di Tailscale menjelaskan alternatif yang lebih sederhana untuk akses khusus tailnet.

Membaca kode penolakan

Bagian pemecahan masalah memetakan setiap penolakan: sumber tidak tepercaya berarti permintaan tidak datang dari alamat proxy yang tercantum, dan alamat ini bisa berubah saat kontainer dimulai ulang; sumber loopback berarti proxy di host yang sama tanpa opt-in yang disengaja; sumber antarmuka lokal berarti ada proses di host gateway yang mengirim header identitas secara langsung atau proxy berbagi namespace jaringan host; pengguna tidak ada berarti header tidak ada atau salah nama; pengguna tidak diizinkan berarti akun sudah terautentikasi tetapi tidak ada di daftar izin, dan dokumentasi menegaskan agar daftar izin tidak dihapus sebagai jalan pintas; origin tidak diizinkan berarti origin browser gagal dalam pemeriksaan antarmuka kontrol. Pesan tentang autentikasi proxy yang diperlukan menandakan identitas yang ditolak, bukan gangguan jaringan, dan solusinya adalah masuk di proxy, bukan mengirim header dari browser. Migrasi dari autentikasi token terdiri dari enam langkah: konfigurasikan proxy, uji proxy secara terpisah, perbarui konfigurasi gateway, mulai ulang, uji WebSocket dari antarmuka kontrol, dan jalankan audit. Akses jarak jauh OpenClaw membandingkan pola akses jarak jauh lainnya, dan penyandingan OpenClaw menjelaskan alur perangkat yang digantikan oleh persetujuan otomatis.

Di Diali

Di Diali, setiap gateway pelanggan dijangkau melalui ingress platform dengan konfigurasi runtime yang dihasilkan dari dasbor dan diganti pada setiap rilis, sehingga mode ini bukan sesuatu yang harus dirakit pelanggan secara manual. OpenClaw yang di-hosting di Diali menjelaskan asisten yang di-hosting dan keamanan Diali menjelaskan batas di sekitar setiap runtime.

• Percayai header hanya dari alamat proxy yang tercantum.
• Sumber loopback dan antarmuka milik sendiri gagal tertutup.
• Header scope mempersempit; pemberian identitas menambah, hanya untuk sesi.