Praktik terbaik Secret Manager

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

Kredensial diperlukan untuk mengautentikasi ke Secret Manager API. Semua library klien menggunakan strategi serupa untuk mencari kredensial yang disebut sebagai "Kredensial Default Aplikasi".

  • Saat melakukan pengembangan secara lokal, gunakan gcloud auth application-default login. Langkah ini akan membuat file dengan kredensial yang diambil secara otomatis oleh library klien.
  • Di Compute Engine dan platform komputasi Google Cloud lainnya seperti Cloud Functions, library klien mendapatkan kredensial melalui server metadata instance.
  • Di GKE, workload identity juga memberikan kredensial melalui layanan metadata.
  • Di platform lain seperti Amazon Web Services atau Microsoft Azure, pertimbangkan untuk menyiapkan federasi identitas workload yang menggunakan mekanisme identitas yang ada untuk melakukan autentikasi ke Google Cloud API.

Semua metode ini lebih disarankan untuk mengekspor kredensial akun layanan karena tidak memerlukan penyimpanan dan akses rahasia tambahan dengan aman di luar Secret Manager API.

Praktik Coding

Meneruskan secret ke aplikasi Anda melalui sistem file atau melalui variabel lingkungan adalah hal yang biasa, tetapi harus dihindari jika memungkinkan karena alasan berikut:

  • Jika secret dapat diakses pada sistem file, kerentanan aplikasi seperti serangan directory traversal dapat menjadi lebih tinggi karena penyerang dapat membaca materi rahasia.
  • Ketika secret digunakan melalui variabel lingkungan, kesalahan konfigurasi, seperti mengaktifkan endpoint debug atau menyertakan dependensi yang membuat log detail lingkungan proses dapat membocorkan secret.
  • Saat menyinkronkan materi secret ke penyimpanan data lain (seperti Kubernetes Secret), pertimbangkan kontrol akses penyimpanan data tersebut, misalnya:
    • Apakah datastore memperluas akses rahasia?
    • Apakah mungkin untuk mengaudit akses rahasia?
    • 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 variabel lingkungan. Untuk mengetahui informasi selengkapnya, lihat Menggunakan Secret Manager dengan produk lainnya.

Administrasi

Pilih kebijakan replikasi otomatis saat membuat secret kecuali jika workload Anda memiliki persyaratan lokasi tertentu (dapat diterapkan menggunakan batasan constraints/gcp.resourceLocations).

Rahasia referensi berdasarkan nomor versinya, bukan menggunakan alias terbaru. Men-deploy update ke nomor versi menggunakan proses rilis yang ada. Biasanya hal ini berarti mengonfigurasi aplikasi Anda dengan versi rahasia tertentu yang dibaca saat perangkat dinyalakan. Meskipun penggunaan alias terbaru mungkin lebih praktis, jika ada masalah dengan versi secret yang baru, beban kerja 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 menghancurkan atau menghapus secret. Hal ini membantu mencegah pemadaman layanan dengan menempatkan secret dalam status yang tampak sama dengan ERUS, tetapi dapat dibatalkan. Artinya, Anda dapat menonaktifkan dan menunggu seminggu sehingga Anda yakin tidak ada dependensi yang tersisa sebelum menghapus data secara permanen.

Jangan tetapkan expiration di secret produksi kecuali Anda yakin bahwa secret tersebut harus dihapus tanpa dapat dipulihkan. Fitur kedaluwarsa paling cocok untuk pembersihan otomatis lingkungan sementara. Pertimbangkan kondisi IAM berbasis waktu sebagai alternatif untuk secret yang akan segera berakhir.

Putar 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 telah diakses sebelumnya.
  • Terus lakukan alur rotasi untuk mengurangi kemungkinan pemadaman.

Pantau secret di seluruh organisasi Anda menggunakan Inventaris Aset Cloud untuk...

  • Membantu mengidentifikasi rahasia di seluruh organisasi Anda.
  • Identifikasi ketidaksesuaian terhadap persyaratan organisasi seperti rotasi, konfigurasi enkripsi, dan lokasi.

Aktifkan log akses data untuk mendapatkan dan menganalisis informasi permintaan AccessSecretVersion. Aktifkan opsi 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 menggunakan 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 rahasia.

Perkirakan puncak penggunaan secret Anda (dengan mempertimbangkan "gundukan pengembangan" karena adanya deployment aplikasi secara serentak atau penskalaan otomatis layanan) dan pastikan project Anda memiliki kuota yang cukup untuk menangani peristiwa tersebut. Jika diperlukan kuota lebih banyak, minta penambahan.