Kiat & trik Kubernetes: akses ke situs dev

Kami melanjutkan serangkaian artikel praktis tentang cara membuat hidup lebih mudah bagi pengembang dan pengembang dalam pekerjaan sehari-hari mereka dengan Kubernetes. Semuanya dikumpulkan dari pengalaman kami dalam menyelesaikan masalah dari klien dan ditingkatkan dari waktu ke waktu, tetapi masih tidak mengklaim sebagai yang ideal - menganggapnya lebih sebagai ide dan kekosongan, menyarankan solusi dan peningkatan dalam komentar Anda.


Kali ini, dua topik akan dipertimbangkan, secara kondisional terkait dengan satu topik: akses pengguna ke lingkungan dev.

1. Bagaimana kita menutup sirkuit dev dari pengguna yang tidak perlu?

Kita sering menghadapi tugas untuk menutup seluruh rangkaian dev (puluhan / ratusan aplikasi) di belakang auth dasar atau daftar putih, sehingga bot pencarian atau hanya orang pihak ketiga tidak bisa sampai di sana.

Biasanya, untuk membatasi akses, setiap Ingress dan aplikasi perlu membuat rahasia auth dasar yang terpisah . Mengelolanya sangat bermasalah saat mengetik dengan selusin aplikasi. Oleh karena itu, kami mengatur kontrol akses terpusat.

Untuk melakukan ini, nginx dibuat dengan konfigurasi tipe ini:

location / { satisfy any; auth_basic "Authentication or whitelist!"; auth_basic_user_file /etc/nginx/htpasswd/htpasswd; allow 10.0.0.0/8; allow 175.28.12.2/32; deny all; try_files FAKE_NON_EXISTENT @return200; } location @return200 { return 200 Ok; } 

Lebih lanjut dalam Ingress aplikasi, kami cukup menambahkan anotasi:

ingress.kubernetes.io/auth-url: "http://dev-auth.dev-auth-infra.svc.cluster.local"

Jadi, ketika mengakses aplikasi, permintaan pergi ke layanan dev-auth , yang memeriksa apakah auth dasar dasar yang benar dimasukkan atau klien memasukkan daftar putih. Jika salah satu syarat terpenuhi, permintaan dikonfirmasi dan lolos ke aplikasi.



Dalam hal menggunakan layanan seperti itu, satu repositori cukup, di mana daftar semua akses disimpan dan melalui mana kita dapat dengan mudah mengkonfigurasi "pusat otorisasi tunggal" kami. Distribusi ke aplikasi baru dilakukan dengan penambahan anotasi dasar.

2. Bagaimana kami menyediakan akses ke aplikasi di dalam Kubernetes di lingkungan pengembang?

... baik itu Redis, RabbitMQ, PostgreSQL atau pengembang PHP favorit Xdebug.

Sangat sering, ketika menerjemahkan aplikasi ke Kubernetes, untuk memastikan keamanan yang lebih baik, kita harus memblokir akses dari luar dan sepenuhnya. Dan kemudian pengembang yang terbiasa “membuka IDE mereka” ke database atau ke Xdebug mengalami kesulitan serius.

Untuk mengatasi masalah ini, kami menggunakan VPN langsung di kluster Kubernetes. Skema umum terlihat sehingga ketika terhubung ke server VPN yang berjalan di K8s, dalam file konfigurasi OpenVPN kami mendorong alamat server DNS, yang juga hidup di K8s. OpenVPN mengkonfigurasi VPN sedemikian rupa sehingga ketika meminta sumber daya di dalam Kubernetes, ia pertama-tama pergi ke server DNS Kubernetes - misalnya, di belakang alamat layanan redis.production.svc.cluster.local . DNS di Kubernetes menyelesaikannya menjadi 10.244.1.15 dan permintaan untuk alamat IP ini melalui OpenVPN langsung ke kluster Kubernetes.

Selama pengoperasian solusi ini, kami berhasil mengembangkannya berulang kali. Khususnya:

1. Karena kami tidak menemukan panel admin yang sederhana dan memadai (untuk kasus kami) untuk akuntansi akses ke VPN , kami harus membuat antarmuka sederhana kami sendiri - bagan resmi hanya menyediakan opsi untuk meluncurkan perintah konsol untuk menerbitkan sertifikat.
   
   Panel admin yang dihasilkan (lihat juga di Docker Hub ) terlihat sangat asketis:
   
   
   Anda dapat membuat pengguna baru atau mencabut sertifikat lama:
   
   
   Anda juga dapat melihat konfigurasi untuk klien ini:
   
   
2. Kami menambahkan otorisasi dalam VPN berdasarkan pada pengguna di GitLab , tempat kata sandi diperiksa dan jika pengguna aktif di GitLab. Ini untuk kasus ketika klien ingin mengelola pengguna yang dapat terhubung ke dev VPN hanya berdasarkan GitLab, dan tanpa menggunakan admin tambahan - dalam arti, ternyata "SSO untuk orang miskin." Sebagai dasar, mereka mengambil grafik yang sudah jadi .
   
   Untuk melakukan ini, kami menulis skrip Python yang, saat menghubungkan pengguna ke OpenVPN, menggunakan nama pengguna dan kata sandi, membandingkan hash dalam database GitLab dan memeriksa statusnya (apakah itu aktif).
   
   
   
   Ini skripnya sendiri:
   
   

    #!/usr/bin/env python3 # pip3 install psycopg2-binary bcrypt import bcrypt import sys import os import psycopg2 import yaml with open("/etc/openvpn/setup/config.yaml", 'r') as ymlfile: cfg = yaml.load(ymlfile) def get_user_info(username=''): try: connect_str = "dbname=%s user=%s host=%s password=%s" % (cfg['db'], cfg['user'], cfg['host'], cfg['pass']) # use our connection values to establish a connection conn = psycopg2.connect(connect_str) # create a psycopg2 cursor that can execute queries cursor = conn.cursor() # create a new table with a single column called "name" cursor.execute("""SELECT encrypted_password,state FROM users WHERE username='%s';""" % username) # run a SELECT statement - no data in there, but we can try it rows = cursor.fetchall() print(rows) return(rows[0]) except Exception as e: print("Uh oh, can't connect. Invalid dbname, user or password?") print(e) def check_user_auth(): username = os.environ['username'] password = bytes(os.environ['password'], 'utf-8') # hashed = bcrypt.hashpw(password, bcrypt.gensalt()) user_info = get_user_info(username=username) user_encrypted_password = bytes(user_info[0], 'utf-8') user_state = True if user_info[1] == 'active' else False if bcrypt.checkpw(password, user_encrypted_password) and user_state: print("It matches!") sys.exit(0) else: print("It does not match :(") sys.exit(1) def main(): check_user_auth() if __name__ == '__main__': main() 

   
   Dan dalam konfigurasi OpenVPN cukup tentukan yang berikut:
   
   auth-user-pass-verify /etc/openvpn/auth-user.py via-env
script-security 3
client-cert-not-required
   
   Jadi, jika seorang karyawan meninggalkan klien, mereka hanya menonaktifkannya di GitLab, setelah itu ia tidak akan dapat terhubung ke VPN.

Alih-alih sebuah kesimpulan

Melanjutkan serangkaian artikel dengan resep Flant praktis untuk operasi Kubernetes, saya akan membahas topik-topik seperti menyoroti setiap node untuk tugas-tugas tertentu (mengapa dan bagaimana?) Dan mengkonfigurasi layanan seperti php-fpm / gunicorn yang berjalan dalam wadah untuk beban berat. Berlangganan ke blog kami agar tidak ketinggalan pembaruan!

PS

Lainnya dari siklus tips & trik K8:

• " Halaman kesalahan yang dipersonalisasi di NGINX Ingress ";
• " Transfer sumber daya yang bekerja di sebuah cluster ke manajemen Helm 2 ";
• " Tentang alokasi node dan beban pada aplikasi web ";
• " Mempercepat bootstrap dari database besar. "

Baca juga di blog kami:

• “ 11 Cara untuk (Tidak) Menjadi Korban Peretasan Kubernetes ”;
• “ Bangun dan instal aplikasi di Kubernet menggunakan dapp dan GitLab CI ”;
• “ Monitoring and Kubernetes ” (ulasan dan laporan video) ;
• " Pengalaman kami dengan Kubernetes dalam proyek-proyek kecil " (laporan video, yang mencakup pengenalan ke perangkat teknis Kubernetes) .