Clever Geek Handbook

Keajaiban 2 baris di Lua atau cara menyampaikan header otorisasi-header HTTP Authorization asli ke layanan web

Artikel ini akan bermanfaat bagi mereka:



  • yang perlu menggunakan beberapa jenis otorisasi dalam satu permintaan ke server;
  • yang ingin membuka layanan dunia Kubernetes / Docker ke Internet umum, tanpa memikirkan tentang cara melindungi layanan tertentu;
  • berpikir bahwa semuanya telah dilakukan oleh seseorang, dan ingin membuat dunia menjadi lebih nyaman dan aman.






Layanan Kata Pengantar yang tersedia melalui Kubernetes memiliki beragam metode otorisasi. Salah satu yang lebih modis adalah header Otorisasi: Bearer - misalnya: otorisasi JWT ( JSON Web Token ) dengan transfer banyak kunci, dan oleh karena itu, nilai, dalam satu header. Ada juga Basic authorization, misalnya untuk Registry (image repository Docker). Otorisasi ini tidak menggunakan cookie dan secara otomatis ditambahkan oleh browser (kecuali Safari - ada nuansa yang belum kami putuskan) ke semua permintaan ke server.







Masalah 1:



Saya tidak dapat masuk melalui Firefox & Safari di antarmuka OS Penyimpanan, Loader ditampilkan, dan hanya itu.



Hipotesis mini:



Masalah proxy. Pemeriksaan cepat menunjukkan hasilnya: jika otorisasi tanpa menggunakan proxy (akses aman universal menggunakan sertifikat), maka semuanya berfungsi. Jadi apa masalahnya?



Setelah menganalisis tumpukan jaringan, kami menyadari bahwa header Otorisasi sedang digunakan, namun, sebelumnya, selama konfigurasi proxy layanan Rancher, ditemukan bahwa header ini diteruskan ke layanan yang di-proxy dan berisi data otorisasi untuk sertifikat, jadi diputuskan untuk hanya menghapusnya setelah proses otorisasi selesai (FakeBasicAuth ).



Masalah 2:



Di banyak server web, otorisasi dengan sertifikat pribadi diimplementasikan melalui emulasi otorisasi Dasar (sebenarnya, mengganggu permintaan pengguna), mungkin untuk mengurangi perubahan pada kode utama server web. Metode ini disebut FakeBasicAuth. Setelah menyetel tajuk semacam itu, server web menimpa tajuk Otorisasi yang berasal dari pengguna.



Hipotesis:



  1. Cakupan tajuk FakeBasicAuth cocok untuk lebih banyak pembatasan, sehingga tajuk asli dipulihkan untuk transmisi ke sumber yang diproksikan sehingga hanya tajuk asli, jika ada, yang ditransmisikan.
  2. Cakupan header Otorisasi dapat dirancang sehingga header akan disimpan sebelum mengaktifkan mekanisme FakeBasicAuth dan dipulihkan setelahnya.


Status Terlihat - Tujuan:



OS Penyimpanan mengotorisasi, Anda dapat mengonfigurasi layanan ini sambil mempertahankan pendekatan terpadu untuk menyediakan layanan ke Internet eksternal.



Sasaran tambahan:



Akses http terpadu, cepat, dan aman sambil mempertahankan fungsionalitas semua layanan http yang mungkin (misalnya, REST API untuk aplikasi seluler atau Registry Docker).



Bagaimana cara memeriksanya?



  • docker login registry-rancher.xxx.ru - menggunakan kunci dan login / kata sandi.
  • storageos-rancher.xxx.ru/#/login - menggunakan login dan kata sandi dari configs secret rancher.xxx.ru/p/c-84bnv : p-qj9qm / secret / kube-system: init-secr ... (tidak berfungsi di Safari ).
  • registry-ui-rancher.xxx.ru - menggunakan browser dan login / kata sandi dari Registry. Bagi mereka yang membaca trik dengan hati-hati: Anda dapat menggunakan antarmuka ini sebagai pengganti registry-rancher.xxx.ru docker login standar - ada proxy bawaan ke Registry.


Menguji hipotesis:



1. Berdasarkan pengalaman sebelumnya, mari kita coba mencari cara di Internet untuk permintaan seperti itu: apache authentication external basic via cert.



Ada artikel yang kurang lebih memadai tentang ldap . Lewat sini: 



RewriteEngine on
RewriteCond %{IS_SUBREQ} ^false$
RewriteCond %{LA-U:REMOTE_USER} (.+)
RewriteRule . - [E=RU:%1]
RequestHeader set REMOTE_USER %{RU}e


Lalu teruskan judul di header tambahan melalui konstruksi 



RequestHeader add Authorization "expr=%{env:zt-auth-before}" "expr=%{env:zt-auth-before} =~/.{1,}/"


Namun, sayangnya, konstruksi ini tidak menyiratkan pembuatan header yang identik, header permintaan pengguna, dan env dibentuk dengan tidak benar.



Oleh karena itu, metode yang didasarkan pada penulisan ulang standar ternyata tidak berguna dan rumit.



2. Jika kita tidak bisa melakukannya sebagai standar, maka kita perlu beralih ke lua, sebelumnya kita telah melihat bahwa ada blok pemrosesan permintaan yang dijalankan sebelum sertifikat diproses, lihat kembali diagram blok dari artikel lua_load_resty_core dan instruksi module_lua_writinghooks dengan konstruksi awal.



Ternyata kami dapat menggunakan skrip yang sama ( Bagaimana kami di ZeroTech berteman dengan Apple Safari dan sertifikat klien dengan websockets) untuk mempertahankan header Otorisasi sebelum menggantinya dengan FakeBasicAuth. 







LuaHookAccessChecker /usr/local/etc/apache24/sslincludes/websocket_token.lua handler early


Di Lua, sekarang terlihat seperti ini: 




require 'apache2'

function handler(r)
        local fmt = '%Y%m%d%H%M%S'
        local timeout = 3600 -- 1 hour
        local auth = r.headers_in['Authorization']

        r.notes['zt-cert-timeout'] = timeout
        r.notes['zt-cert-date-next'] = os.date(fmt,os.time()+timeout)
        r.notes['zt-cert-date-halfnext'] = os.date(fmt,os.time()+ (timeout/2))
        r.notes['zt-cert-date-now'] = os.date(fmt,os.time())

        if auth ~= nil then
                r.notes['zt-auth-before'] = auth
        end

        return apache2.OK
end


Catatan:



Desain baru dicetak tebal. Dan karena kita tahu bahwa env yang diperoleh dari Lua hanya tersedia untuk ekspresi expr, kita menambahkan konstruksi di sebelah enkripsi token zt-cert:



# cookie keluar ke pengguna 




Header set Set-Cookie "expr=zt-cert=%{sha1:...


# berikan tajuk ke layanan yang di-proxy-kan 




RequestHeader add Authorization "expr=%{env:zt-auth-before}" "expr=%{env:zt-auth-before} =~/.{1,}/"


Ketersediaan data untuk transmisi ke layanan diperiksa dengan mentransfer data kembali ke pengguna ke browser: 



Header add Authorization "expr=%{env:zt-auth-before}" "expr=%{env:zt-auth-before} =~/.{1,}/"


Hal yang paling menarik disini adalah cara untuk mengecek keberadaan data agar tidak mengirimkan header ke layanan proxy jika tidak datang dari luar browser pengguna. Bagian kedua dari konstruksi bertanggung jawab untuk ini: 



"expr=%{env:zt-auth-before} =~/.{1,}/"


Penyelesaian: Tidak ada



solusi yang siap pakai di Internet saat ini, sekitar tiga jam dihabiskan untuk mencari dan mencoba menguji variasi, karena saya tidak ingin "menemukan kembali roda".



Menambahkan 5 baris, 3 di antaranya dapat dihapus dengan aman. Bagaimana menurut anda? - Tulis pilihan Anda untuk jawaban di komentar ke artikel.



Saya tidak ingin menulis tentang pengalaman ini, karena sebenarnya hanya 2 baris dan judul Otorisasi akan sampai ke penerima, tetapi saya memutuskan untuk tetap membagikan informasi, karena ini menggunakan pengetahuan yang baik dari penelitian sebelumnya tentang sertifikat (kita sedang membicarakan artikel ini ). Selain itu, hampir tidak ada pemberani untuk menulis sesuatu sendiri dan sangat sederhana dalam bahasa yang tidak dikenal.





More articles:


All Articles