Praktik terbaik Secret Manager

Panduan ini memperkenalkan beberapa praktik terbaik saat menggunakan Secret Manager. Panduan ini bukanlah daftar rekomendasi yang 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.

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 diambil secara otomatis 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 secara aman di luar Secret Manager API.

Praktik coding

Hindari meneruskan secret ke aplikasi Anda melalui sistem file atau melalui variabel lingkungan. Berikut adalah beberapa alasan untuk menggunakan metode lain dalam menangani secret:

  • 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 dapat membocorkan secret.

  • 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 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.

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 secret tertentu yang dibaca saat browser dijalankan. 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 dengan menempatkan secret dalam status yang tampak sama seperti 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 tetapkan 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 habis masa berlakunya.

Secara berkala rotasi secret Anda untuk melakukan hal berikut:

  • Batasi dampak jika rahasia bocor.

  • 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 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 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 secret regional jika Anda memiliki persyaratan kedaulatan dan residensi data yang ketat. Secret regional memungkinkan Anda menyimpan data sensitif dalam lokasi geografis tertentu, memberikan jaminan lengkap dalam penyimpanan, penggunaan, dan pengiriman, sehingga membantu Anda mematuhi persyaratan hukum, peraturan, atau organisasi terkait residensi data.