Panduan ini memperkenalkan beberapa praktik terbaik saat menggunakan Secret Manager. Panduan ini bukan daftar rekomendasi lengkap. Sebaiknya tinjau ringkasan platform untuk memahami lanskap Google Cloud secara keseluruhan 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 hanya untuk admin super yang aman menggunakan akun layanan.
-
Pecah aplikasi dan lingkungan (staging atau produksi) menjadi beberapa bagian project seperti yang dijelaskan dalam Menentukan hierarki resource untuk zona landing Google Cloud Anda. Hal ini dapat membantu mengisolasi lingkungan dengan binding IAM level project dan memastikan bahwa kuota diterapkan secara independen.
-
Pilih peran pilihan dengan izin minimum yang diperlukan, atau buat peran khusus jika perlu.
-
Jika secret untuk banyak layanan berada dalam satu project, gunakan level rahasia Binding IAM, atau IAM Kondisi untuk membatasi akses ke subset secret yang diperlukan.
-
Pemberi Rekomendasi IAM dapat lebih membantu mengidentifikasi binding IAM yang memiliki hak istimewa berlebih.
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. Perintah ini membuat sebuah file dengan kredensial yang secara 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.
-
Pada platform lain seperti Amazon Web Services atau Microsoft Azure, pertimbangkan menyiapkan federasi identitas workload, 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
Hindari meneruskan secret ke aplikasi Anda melalui sistem file atau lingkungan variabel. Berikut adalah beberapa alasan untuk menggunakan metode lain untuk menangani secret:
-
Ketika sebuah rahasia dapat diakses pada sistem file, maka kerentanan aplikasi seperti serangan traversal direktori dapat menjadi tingkat keparahan yang lebih tinggi karena bisa membaca materi rahasia.
-
Ketika secret digunakan melalui variabel lingkungan, kesalahan konfigurasi seperti mengaktifkan endpoint debug atau menyertakan dependensi yang mencatat log proses detail lingkungan mungkin membocorkan rahasia.
-
Saat menyinkronkan materi rahasia ke datastore lain (seperti Kubernetes Secrets), evaluasi kontrol akses yang disediakan oleh datastore tersebut. Pertimbangkan hal berikut:
-
Apakah datastore memperluas akses secret?
-
Apakah akses secret dapat diaudit?
-
Apakah datastore mematuhi persyaratan enkripsi data dalam penyimpanan dan regionalisasi Anda?
-
Sebaiknya gunakan Secret Manager API secara langsung menggunakan salah satu menyediakan library klien, atau dengan mengikuti REST atau Dokumentasi GRPC.
Administrasi
Referensikan secret berdasarkan nomor versi, bukan menggunakan alias terbaru. Deploy pembaruan ke nomor versi menggunakan proses rilis yang tersedia. Biasanya hal ini berarti mengonfigurasi aplikasi Anda dengan versi rahasia tertentu yang dibaca saat {i>startup<i}. Meskipun penggunaan alias terbaru mungkin memudahkan, jika ada masalah dengan versi baru secret, workload Anda mungkin tidak 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 layanan dengan menempatkan rahasia dengan status yang sama seperti menghancurkan tetapi dapat dibatalkan. Yaitu, Anda dapat menonaktifkan dan menunggu satu minggu sehingga Anda yakin tidak ada yang dependensi sebelum menghapus data secara permanen.
Jangan tetapkan masa berlaku rahasia produksi kecuali Anda yakin bahwa rahasia tersebut harus dihapus tanpa dapat dipulihkan. Fitur masa berlaku paling cocok untuk pembersihan otomatis lingkungan sementara. Pertimbangkan kondisi IAM berbasis waktu sebagai alternatif untuk secret yang kedaluwarsa.
Putar secara berkala rahasia Anda untuk melakukan hal berikut:
-
Batasi dampaknya jika terjadi kebocoran rahasia.
-
Pastikan bahwa individu yang tidak lagi memerlukan akses ke secret tidak dapat terus menggunakan secret yang sebelumnya diakses.
-
Mengurangi kemungkinan pemadaman layanan.
Pantau secret di seluruh organisasi Anda menggunakan Cloud Asset Inventory karena alasan berikut:
-
Membantu mengidentifikasi rahasia di seluruh organisasi Anda.
-
Mengidentifikasi ketidaksesuaian dengan persyaratan organisasi seperti rotasi, konfigurasi enkripsi, dan lokasi.
Aktifkan log akses data untuk mendapatkan dan menganalisis informasi permintaan AccessSecretVersion. Aktifkan ini di level 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.
constraints/iam.allowedPolicyMemberDomains
kebijakan organisasi dapat digunakan untuk membatasi identitas yang dapat ditambahkan ke kebijakan IAM
untuk secret.
Estimasi penggunaan secret puncak Anda (dengan mempertimbangkan thundering herd permintaan karena deployment 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.
Kepatuhan residensi data
Pilih regional secrets jika Anda memiliki residensi data yang ketat dan persyaratan kedaulatan negara tersebut. Rahasia regional memungkinkan Anda menyimpan data sensitif dalam lokasi geografis tertentu lokasi bisnis, memberikan jaminan lengkap dalam penyimpanan, saat digunakan, dan dalam pengiriman, yang membantu Anda mematuhi kebijakan, peraturan, atau persyaratan organisasi seputar residensi data.