
Salah satu masalah menjengkelkan yang muncul saat membuat NAS, adalah bahwa tidak semua perangkat lunak dapat bekerja dengan LDAP, dan beberapa tidak mengandung mekanisme otentikasi.
Solusinya adalah otentikasi ujung-ke-ujung melalui proxy terbalik.
Contoh cara melakukan ini dibahas dengan sangat rinci, misalnya, dalam artikel ini .
Karena artikel ini adalah bagian dari siklus NAS ,
di sini saya akan fokus pada bagaimana menyesuaikan solusi ini dengan layanan dalam wadah Docker.
Solusinya didasarkan pada contoh penerapan otentikasi melalui agen NAPX LDAP Auth eksternal, tapi saya menggunakan versi kemas dari LinuxServer.io karena ini adalah gambar siap pakai yang memenuhi standar tertentu.
Satu-satunya masalah adalah bahwa patch LinuxServer.io memecahkan otentikasi HTTP dasar, tetapi setelah perbaikan bug diunggah , menjadi mungkin untuk menggunakan ini lagi.
Otentikasi umum
Seperti yang ditunjukkan dalam artikel, otentikasi dilakukan sebagai berikut:
- Klien mengakses layanan.
- Proxy sebaliknya akan mengarahkan jika cookie diatur.
- Jika tidak ada cookie, permintaan dibuat ke layanan otentikasi.
- Layanan otentikasi meminta nama pengguna dan kata sandi, yang diverifikasi dengan mengakses server LDAP.
- Jika verifikasi berhasil, ini menetapkan cookie dan mengalihkan ke layanan.

Opsi alternatif mungkin menggunakan modul yang dikompilasi untuk nginx, tetapi saya tidak akan mempertimbangkan opsi ini di sini karena beberapa masalah dengan modul ini dan fleksibilitasnya yang kurang.
Gambar yang dimodifikasi untuk server OpenLDAP ada di sini .
Otentikasi kontainer
Di dalam NAS, layanan bekerja dalam wadah, sehingga ada keinginan untuk membuatnya sehingga dimungkinkan untuk beralih mode otentikasi dengan hanya mengatur variabel di dalam wadah.
Mekanisme seperti ini sudah ada dalam gambar ngingx-proxy yang digunakan dan diimplementasikan melalui templat yang diproses oleh docker-gen .
Itu memasukkan metadata ke dalam templat yang berisi deskripsi dari wadah Docker yang sedang berjalan.
Dengan demikian, semua yang perlu dilakukan adalah untuk memperbaiki template konfigurasi proxy terbalik sehingga jika ada variabel kondisional dalam wadah, pengalihan ke layanan otentikasi end-to-end, yang juga berfungsi dalam wadah, disertakan.
Kemudian, buat penyesuaian yang sesuai dengan konfigurasi susunan buruh pelabuhan.
Implementasi otentikasi
Modifikasi template konfigurasi nginx-proxy
Pertama-tama, hulu baru ditambahkan, yang memungkinkan Anda untuk mengakses layanan otentikasi di konfigurasi:
proxy_cache_path cache/ keys_zone=auth_cache:10m; upstream ldap-backend { server {{ $.Env.LDAP_BACKEND }}:{{ or $.Env.LDAP_LOGIN_PORT "9000" }}; }
Dapat dilihat bahwa layanan otentikasi berjalan pada host ${LDAP_BACKEND}
dan port ${LDAP_LOGIN_PORT }
, standarnya adalah 9000.
Nilai-nilai variabel akan diganti oleh docker-gen sehingga bagian konfigurasi ini akan terlihat seperti ini di /etc/nginx/conf.d/default.conf
di dalam wadah:
Tambahan berikut menetapkan variabel ext_ldap_auth
jika variabel LDAP_EXT_AUTH dikokang dalam wadah layanan tertentu.
Juga, beberapa variabel lagi diatur untuk mengkonfigurasi otentikasi.
{{/* Nginx LDAP authentication enabled */}} {{ $ext_ldap_auth := parseBool (or (first (groupByKeys $containers "Env.LDAP_EXT_AUTH")) "false") }} {{/* User need to be participated in these groups to use service */}} {{ $ldap_add_groups := or (first (groupByKeys $containers "Env.LDAP_EXT_ADD_GROUPS")) "" }} {{/* Use HTML login page or HTTP Basic authentication */}} {{ $ldap_use_login_page := parseBool (or $.Env.LDAP_USE_LOGIN_PAGE "false" ) }}
Blok tambahan tambahan diberikan di bawah ini. Ini diaktifkan hanya jika variabel ext_ldap_auth
.
Jika ldap_use_login_page
diatur, maka pengalihan ke halaman otentikasi akan diaktifkan, jika tidak maka jendela otentikasi dasar HTTP akan digunakan.
Path /auth-proxy
adalah pengalihan ke layanan otentikasi.
Parameter akan melewati header HTTP.
Parameter apa dan mengapa diperlukan, dijelaskan secara rinci dalam komentar.
Bagian LDAP {{ if ($ext_ldap_auth) }}
Terakhir, ketika otentikasi LDAP untuk layanan diaktifkan, auth_request
ditambahkan ke lokasinya:
location / { {{ if ($ext_ldap_auth) }} auth_request /auth-proxy; {{ if ($ldap_use_login_page) }}
Berikut ini adalah daftar lengkap templat.
nginx.tmpl {{ $CurrentContainer := where $ "ID" .Docker.CurrentContainerID | first }} {{ define "upstream" }} {{ if .Address }} {{/* If we got the containers from swarm and this container's port is published to host, use host IP:PORT */}} {{ if and .Container.Node.ID .Address.HostPort }} # {{ .Container.Node.Name }}/{{ .Container.Name }} server {{ .Container.Node.Address.IP }}:{{ .Address.HostPort }}; {{/* If there is no swarm node or the port is not published on host, use container's IP:PORT */}} {{ else if .Network }}
Modifikasi konfigurasi penulisan-dok
Di docker-compose.yml
ditambahkan:
- Layanan baru "ldap-auth", yang bertanggung jawab untuk otorisasi.
- Blok variabel yang mengonfigurasi interaksi dengan server LDAP.
Apa yang tertulis dalam variabel, nginx akan melewati layanan otentikasi melalui header HTTP.
Tujuan dari parameter jelas dari nama variabel, jadi saya tidak akan memikirkannya.
Lihat konfigurasi lengkap di bawah ini.
docker-compose.yml version: '2' networks: internal: docker0: external: name: docker0 services: ldap-auth: image: linuxserver/ldap-auth:latest container_name: ldap-auth networks: - internal - docker0 environment: - TZ=Europe/Moscow expose: - 8888 - 9000 restart: unless-stopped nginx-proxy: depends_on: - ldap-auth networks: - internal - docker0 restart: always image: jwilder/nginx-proxy ports: - "80:80" - "443:443" volumes: - ./certs:/etc/nginx/certs:ro - ./vhost.d:/etc/nginx/vhost.d - ./html:/usr/share/nginx/html - /var/run/docker.sock:/tmp/docker.sock:ro - ./local-config:/etc/nginx/conf.d - ./nginx.tmpl:/app/nginx.tmpl environment: - DEFAULT_HOST=nas.nas - LDAP_BACKEND=ldap-auth #- LDAP_BACKEND_PORT=8888 #- LDAP_LOGIN_PORT=9000 - LDAP_HOST=ldap://172.21.0.1:389 #- LDAP_METHOD=start_tls - LDAP_METHOD=plain - LDAP_UID=uid - LDAP_PASS=LDAP_PASSWORD - LDAP_BASE=ou=users,dc=nas,dc=nas - LDAP_BIND_DN=cn=readonly,dc=nas,dc=nas - LDAP_USER_FILTER=(uid=%(username)s) #- LDAP_USE_LOGIN_PAGE=true labels: - "com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy=true" letsencrypt-dns: image: adferrand/letsencrypt-dns restart: always volumes: - ./certs/letsencrypt:/etc/letsencrypt environment: - "LETSENCRYPT_USER_MAIL=MAIL@MAIL.COM" - "LEXICON_PROVIDER=cloudns" - "LEXICON_OPTIONS=--delegated NAS.cloudns.cc" - "LEXICON_PROVIDER_OPTIONS=--auth-id=CLOUDNS_ID --auth-password=CLOUDNS_PASSWORD"
Gunakan dengan layanan
Otentikasi ujung ke ujung dimatikan secara default.
Untuk mengaktifkannya, cukup dengan mengatur variabel di lingkungan wadah yang diinginkan:
LDAP_EXT_AUTH=true
- aktifkan otentikasi.LDAP_EXT_ADD_GROUPS=(memberOf=cn=users_cloud,ou=groups,dc=nas,dc=nas)
- filter opsional, daftar grup yang harus menjadi anggota pengguna untuk diautentikasi. Ini memberikan dukungan otorisasi.
environment: - LDAP_EXT_AUTH=true - LDAP_EXT_ADD_GROUPS=(memberOf=cn=users_cloud,ou=groups,dc=nas,dc=nas)
Kesimpulan
Secara umum, solusinya telah bekerja untuk waktu yang lama dan tidak hanya memberikan otentikasi, tetapi juga otorisasi.
Ini memungkinkan Anda untuk menggunakan layanan apa pun dalam wadah di NAS, terlepas dari apakah mereka mendukung otentikasi melalui LDAP.
Meskipun ada beberapa masalah:
- HTML ,
ldap_use_login_page
. . — . - . LDAP , , docker-gen .
- , . , , , . .
NAS .