Halaman ini mencantumkan beberapa praktik terbaik untuk menggunakan Proxy Auth AlloyDB.
Menjaga agar klien Auth Proxy selalu dalam versi terbaru
Google merilis versi baru Proxy Auth setiap bulan. Anda dapat menemukan versi saat ini dengan memeriksa halaman rilis GitHub Proxy Auth AlloyDB.
Gunakan otomatisasi untuk mengupdate versi Proxy Autentikasi dan menguji versi baru di lingkungan non-produksi sebelum mempromosikan perubahan ke produksi.
Menjalankan klien Proxy Auth sebagai layanan tetap atau file bantuan
Dalam produksi, Anda harus menjalankan klien Auth Proxy sebagai layanan persisten atau sidecar.
Jika proses klien Auth Proxy dihentikan,semua koneksi yang ada melalui proses tersebut akan dihapus, dan aplikasi Anda tidak dapat membuat koneksi lagi ke instance AlloyDB dengan Proxy Auth AlloyDB. Untuk mencegah skenario ini, jalankan klien Auth Proxy sebagai layanan tetap, sehingga jika klien Auth Proxy berhenti karena alasan apa pun, klien tersebut akan otomatis dimulai ulang.
Berdasarkan tempat Anda menjalankan klien, gunakan opsi berikut:
- Untuk klien Proxy Auth yang berjalan di VM Linux, gunakan layanan seperti
systemd,upstart, atausupervisor. - Untuk beban kerja Windows, jalankan klien Proxy Auth sebagai Layanan Windows. Lihat Panduan Layanan Windows untuk mengetahui informasi selengkapnya.
- Untuk penyiapan Kubernetes, jalankan klien Proxy Auth sebagai sidecar.
Menjalankan klien Proxy Auth di mesin yang sama dengan workload Anda
Klien Proxy Autentikasi mengasumsikan bahwa klien tersebut berjalan di mesin yang sama dengan workload. Semua traffic klien ke Proxy Autentikasi tidak akan dienkripsi. Traffic dari Proxy Auth ke AlloyDB dienkripsi menggunakan mTLS.
Pastikan setiap klien Proxy Autentikasi berada di mesin yang sama sehingga tidak ada traffic terenkripsi yang keluar dari mesin. Proxy Auth AlloyDB harus ditempatkan bersama dengan klien yang ingin mengakses instance AlloyDB Anda.
Menggunakan akun layanan yang berbeda untuk setiap workload
Proxy Auth AlloyDB menggunakan akun utama IAM lingkungan untuk membuat tunnel yang aman ke instance AlloyDB. Untuk mengikuti prinsip hak istimewa minimum, setiap beban kerja, seperti aplikasi web atau aplikasi pemrosesan data backend, harus menggunakan akun layanan yang berbeda. Penggunaan akun layanan yang berbeda memastikan bahwa izin setiap beban kerja dapat dikelola (atau dicabut) secara terpisah.
Jangan men-deploy Proxy Auth AlloyDB sebagai bottleneck
Anda mungkin tergoda untuk men-deploy Proxy Auth AlloyDB di VM bersama dan menggunakannya untuk me-rutekan semua traffic dari sejumlah beban kerja ke instance AlloyDB Anda. Namun, pendekatan ini tidak aman dan menciptakan satu titik rawan kegagalan.
Karena beberapa klien akhirnya menggunakan akun IAM yang sama dengan yang digunakan Auth Proxy, mengidentifikasi beban kerja yang benar-benar mengakses instance AlloyDB Anda menjadi sulit, sehingga pendekatan ini tidak aman.
Pendekatan ini menciptakan titik kegagalan tunggal karena jika Proxy Auth AlloyDB dibebani dengan lonjakan traffic, semua koneksi klien akan terpengaruh secara negatif.
Sebagai gantinya, deploy klien Auth Proxy di setiap mesin yang memerlukan koneksi aman sebagai sidecar layanan persisten.
Mengurangi output log Proxy Auth AlloyDB untuk deployment produksi
Jika Anda perlu membatasi ukuran log Proxy Auth AlloyDB, tetapkan
opsi --verbose=false saat Anda memulai Proxy Auth AlloyDB. Perhatikan bahwa penggunaan opsi ini
akan mengurangi efektivitas output Proxy Auth AlloyDB dalam mendiagnosis
masalah koneksi.
Membaca pesan bantuan Proxy Auth AlloyDB
Proxy Auth AlloyDB menyertakan banyak fitur tambahan dan menyertakan pesan bantuan
yang lengkap dengan detail. Jalankan perintah ./alloydb-auth-proxy --help untuk menemukan opsi konfigurasi tambahan.
Berinteraksi dengan tim pengembangan di GitHub
Jika Anda yakin telah menemukan bug atau memiliki permintaan fitur, Anda dapat menghubungi tim pengembangan di repositori GitHub Proxy Autentikasi AlloyDB.