Panduan ini memperkenalkan beberapa praktik terbaik saat menggunakan Secret Manager. Panduan ini bukanlah daftar lengkap rekomendasi. Sebaiknya tinjau ringkasan platform untuk memahami keseluruhan lanskap Google Cloud dan ringkasan Secret Manager sebelum Anda membaca panduan ini.
Kontrol akses
Akses ke Secret Manager API dilindungi oleh IAM. Ikuti prinsip hak istimewa terendah saat memberikan izin ke secret.
- Batasi kepemilikan organisasi ke akun admin super yang aman.
- Segmenkan aplikasi dan lingkungan (staging/produksi) ke dalam project terpisah seperti yang dijelaskan dalam Menentukan hierarki resource untuk zona landing Google Cloud. Hal ini dapat membantu mengisolasi lingkungan dengan binding IAM level project dan memastikan kuota diterapkan secara independen.
- Pilih peran pilihan dengan izin minimum yang diperlukan, atau buat peran khusus jika diperlukan.
- Jika secret untuk banyak layanan berada dalam satu project, gunakan binding IAM level secret, atau Kondisi IAM untuk membatasi akses ke subset secret yang diperlukan.
- Pemberi Rekomendasi IAM dapat lebih jauh membantu mengidentifikasi binding IAM yang memiliki hak istimewa.
Kredensial diperlukan untuk mengautentikasi ke Secret Manager API. Semua library klien menggunakan strategi serupa untuk mencari kredensial yang disebut sebagai "Kredensial Default Aplikasi".
- Saat mengembangkan secara lokal, gunakan
gcloud auth application-default login. Tindakan ini akan membuat file dengan kredensial yang otomatis diambil oleh library klien. - Di Compute Engine dan platform komputasi Google Cloud lainnya seperti fungsi Cloud Run, library klien mendapatkan kredensial melalui server metadata instance.
- Di GKE, workload identity juga menyediakan kredensial melalui layanan metadata.
- Di platform lain seperti Amazon Web Services atau Microsoft Azure, pertimbangkan untuk menyiapkan workload identity federation yang menggunakan mekanisme identitas yang ada untuk melakukan autentikasi ke Google Cloud API.
Semua metode ini lebih disukai daripada mengekspor kredensial akun layanan karena tidak memerlukan penyimpanan dan akses rahasia tambahan yang aman di luar Secret Manager API.
Praktik Coding
Meneruskan secret ke aplikasi Anda melalui sistem file atau melalui variabel lingkungan adalah hal yang umum, tetapi harus dihindari jika memungkinkan karena alasan berikut:
- Jika secret dapat diakses di sistem file, kerentanan aplikasi seperti serangan traversal direktori dapat menjadi lebih parah karena penyerang dapat memperoleh kemampuan untuk membaca materi rahasia.
- Saat secret digunakan melalui variabel lingkungan, kesalahan konfigurasi seperti mengaktifkan endpoint debug atau menyertakan dependensi yang mencatat detail lingkungan proses ke dalam log dapat membocorkan secret.
- Saat menyinkronkan materi rahasia ke penyimpanan data lain (seperti Kubernetes
Secrets), pertimbangkan kontrol akses penyimpanan data tersebut, misalnya:
- Apakah datastore memperluas akses secret?
- Apakah dapat mengaudit akses secret?
- Apakah datastore mematuhi persyaratan enkripsi data dalam penyimpanan dan regionalisasi Anda?
Sebaiknya gunakan Secret Manager API secara langsung (menggunakan salah satu library klien yang disediakan, atau dengan mengikuti dokumentasi REST atau GRPC).
Namun, untuk beberapa integrasi produk seperti integrasi serverless, Anda dapat meneruskan secret melalui sistem file atau melalui variabel lingkungan. Untuk mengetahui informasinya, lihat Menggunakan Secret Manager dengan produk lain.
Administrasi
Pilih kebijakan replikasi otomatis saat membuat secret kecuali jika workload Anda memiliki persyaratan lokasi tertentu (dapat diterapkan menggunakan batasan constraints/gcp.resourceLocations).
Referensikan secret berdasarkan nomor versinya, bukan menggunakan alias terbaru. Deploy update ke nomor versi menggunakan proses rilis yang ada. Biasanya, ini berarti mengonfigurasi aplikasi Anda dengan versi secret tertentu yang dibaca saat browser dijalankan. Meskipun penggunaan alias terbaru mungkin memudahkan, jika terjadi masalah dengan versi baru secret, workload Anda mungkin tidak akan dapat menggunakan versi secret. Dengan menyematkan ke nomor versi, konfigurasi dapat divalidasi dan di-roll back menggunakan proses rilis yang ada.
Nonaktifkan versi secret sebelum menghancurkannya atau menghapus secret. Hal ini membantu mencegah pemadaman dengan menempatkan secret dalam status yang tampak sama dengan penghancuran, tetapi dapat dikembalikan. Artinya, Anda dapat menonaktifkan dan menunggu seminggu agar dapat memastikan tidak ada dependensi yang tertinggal sebelum menghapus data secara permanen.
Jangan menetapkan masa berlaku pada secret produksi kecuali jika Anda yakin bahwa secret tersebut harus dihapus secara permanen. Fitur masa berlaku paling cocok untuk pembersihan otomatis lingkungan sementara. Pertimbangkan kondisi IAM berbasis waktu sebagai alternatif untuk secret yang akan berakhir masa berlakunya.
Rotasikan secret Anda secara berkala untuk melakukan hal berikut:
- Batasi dampak jika rahasia bocor.
- Pastikan individu yang tidak lagi memerlukan akses ke secret tidak dapat terus menggunakan secret yang sebelumnya diakses.
- Lakukan alur rotasi secara terus-menerus untuk mengurangi kemungkinan penghentian layanan.
Pantau secret di seluruh organisasi Anda menggunakan Inventaris Aset Cloud untuk...
- Membantu mengidentifikasi secret di seluruh organisasi Anda.
- Identifikasi ketidaksesuaian dengan persyaratan organisasi seperti rotasi, konfigurasi enkripsi, dan lokasi.
Aktifkan log akses data untuk mendapatkan dan menganalisis informasi permintaan AccessSecretVersion. Aktifkan ini di tingkat folder atau organisasi untuk menerapkan logging tanpa harus mengonfigurasinya di setiap secret atau project.
Selain kontrol IAM, Anda dapat membatasi akses ke Secret Manager API dengan kontrol berbasis jaringan dengan menyiapkan perimeter Kontrol Layanan VPC untuk organisasi Anda.
Kebijakan organisasi constraints/iam.allowedPolicyMemberDomains
dapat digunakan untuk membatasi identitas yang dapat ditambahkan ke
kebijakan IAM untuk secret.
Estimasi penggunaan secret puncak Anda (dengan mempertimbangkan "thundering herd" permintaan karena pen-deployan aplikasi serentak atau penskalaan otomatis layanan Anda) dan pastikan bahwa project Anda memiliki kuota yang cukup untuk menangani peristiwa tersebut. Jika memerlukan kuota lebih banyak, minta penambahan.