Halaman ini mencantumkan beberapa praktik terbaik untuk menggunakan Proxy Auth AlloyDB.
Memastikan klien Proxy Auth selalu yang 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 Auth dan menguji versi baru di lingkungan non-produksi sebelum mempromosikan perubahan ke produksi.
Menjalankan klien Proxy Auth sebagai layanan atau file bantuan yang persisten
Dalam produksi, Anda harus menjalankan klien Proxy Auth sebagai layanan persisten atau sidecar.
Jika proses klien Proxy Auth dihentikan, semua koneksi yang ada di dalamnya akan terputus, dan aplikasi Anda tidak dapat membuat koneksi lagi ke instance AlloyDB dengan Proxy Auth AlloyDB. Untuk mencegah skenario ini, jalankan klien Proxy Auth sebagai layanan tetap, sehingga jika klien Proxy Auth berhenti karena alasan apa pun, klien tersebut akan otomatis dimulai ulang.
Bergantung pada 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 file bantuan.
Jalankan klien Proxy Auth di mesin yang sama dengan workload Anda
Klien Proxy Auth mengasumsikan bahwa klien berjalan di mesin yang sama dengan workload. Semua traffic klien ke Proxy Auth tidak akan dienkripsi. Traffic dari Proxy Auth ke AlloyDB dienkripsi menggunakan mTLS.
Pastikan semua klien Auth Proxy berada di mesin yang sama sehingga tidak ada traffic yang tidak dienkripsi keluar dari mesin. Proxy Auth AlloyDB harus ditempatkan bersama klien yang ingin mengakses instance AlloyDB Anda.
Menggunakan akun layanan yang berbeda untuk setiap workload
Proxy Auth AlloyDB menggunakan pokok Identity and Access Management (IAM) lingkungan untuk membuat tunnel yang aman ke instance AlloyDB. Untuk mengikuti prinsip hak istimewa paling rendah, setiap workload, 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 hambatan
Anda mungkin tergoda untuk men-deploy Proxy Auth AlloyDB di VM bersama dan menggunakannya untuk merutekan semua traffic dari sejumlah beban kerja ke instance AlloyDB Anda. Namun, pendekatan ini tidak aman dan menciptakan satu titik kegagalan.
Jika beberapa klien akhirnya menggunakan pokok IAM yang sama dengan yang digunakan Auth Proxy, mengidentifikasi beban kerja yang sebenarnya mengakses instance AlloyDB Anda menjadi sulit, sehingga pendekatan ini tidak aman.
Pendekatan ini menciptakan satu titik kegagalan karena jika Proxy Auth AlloyDB kelebihan beban dengan lonjakan traffic, semua koneksi klien akan terpengaruh secara negatif.
Sebagai gantinya, deploy klien Proxy Auth di setiap mesin yang memerlukan koneksi aman sebagai sidecar atau 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 ekstensif 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 berinteraksi dengan tim pengembangan di repositori GitHub AlloyDB Auth Proxy.