Tentang jadwal rotasi

Topik ini memperkenalkan konsep rotasi secret. Sebelum memulai, sebaiknya tinjau Ringkasan platform untuk memahami lanskap Google Cloud secara keseluruhan. Sebaiknya baca juga ringkasan produk Secret Manager.

Pengantar

Rotasi berkala membantu:

• Batasi dampak jika rahasia bocor.
• Pastikan individu yang tidak lagi memerlukan akses ke secret tidak dapat menggunakan nilai secret yang lama.
• Terus lakukan alur rotasi untuk mengurangi kemungkinan pemadaman jika terjadi rotasi darurat.

Secret Manager memiliki konsep Secret, Secret Versions, dan Rotation Schedules, yang menyediakan dasar untuk mem-build workload yang mendukung secret yang dirotasi.

Topik ini memberikan rekomendasi untuk merotasi secret yang disimpan di Secret Manager. Bagian selanjutnya membahas manfaat dan konsekuensi untuk:

• Metode mengikat versi rahasia ke aplikasi Anda.
• Pendekatan untuk merotasi rahasia.

Mengikat ke versi rahasia

Sebuah secret di Secret Manager dapat memiliki beberapa versi secret. Versi secret berisi payload yang tidak dapat diubah (string byte rahasia sebenarnya) serta diurutkan dan diberi nomor. Untuk merotasi secret, tambahkan versi secret baru ke secret yang ada.

Versi secret yang baru saja ditambahkan pada secret dapat direferensikan menggunakan alias latest. Alias latest, meskipun nyaman untuk pengembangan, dapat menjadi masalah bagi beberapa beban kerja produksi karena nilai yang buruk dapat segera diluncurkan dan mengakibatkan pemadaman layanan di seluruh layanan. Metode alternatif untuk mengikat ke versi rahasia dijelaskan dalam skenario berikut.

Peluncuran bertahap

Peluncuran bertahap adalah prinsip panduan untuk skenario berikut. Jika Anda memilih peluncuran rahasia yang lebih lambat, risiko kerusakan akan lebih rendah, tetapi juga waktu pemulihan yang lebih lambat. Beberapa secret dapat menjadi tidak valid dalam sistem eksternal (seperti API atau database yang melacak nilai secret yang valid) yang mungkin berada dalam kendali Anda atau mungkin tidak. Dalam hal ini, pemulihan memerlukan peluncuran.

Ada kemungkinan rahasia buruk akan diluncurkan selama rotasi manual atau otomatis. Alur kerja rotasi yang kuat harus dapat mendeteksi kerusakan secara otomatis (misalnya, tingkat error HTTP) dan rollback untuk menggunakan versi rahasia yang lebih lama (melalui deployment konfigurasi sebelumnya).

Peluncuran versi secret baru bergantung pada cara secret terikat ke aplikasi Anda.

Pendekatan 1: Menyelesaikan masalah selama proses rilis yang ada

Selesaikan dan ikat versi rahasia dengan rilis aplikasi Anda. Untuk sebagian besar deployment, hal ini melibatkan penyelesaian versi secret terbaru menjadi nama resource versi secret yang lengkap dan meluncurkannya bersama aplikasi sebagai flag atau dalam file konfigurasi. Sebaiknya selesaikan nama versi rahasia pada waktu rotasi, simpan nama resource di tempat yang tahan lama (misalnya, commit ke Git), dan masukkan nama versi ke dalam konfigurasi deployment selama push untuk mencegah deployment yang diblokir.

Saat aplikasi dimulai, panggil Secret Manager dengan nama versi secret tertentu untuk mengakses nilai secret.

Pendekatan ini memiliki manfaat sebagai berikut:

• Aplikasi Anda menggunakan versi secret yang sama setiap kali mulai ulang, sehingga meningkatkan prediksi dan mengurangi kompleksitas operasional.
• Proses manajemen perubahan yang ada untuk peluncuran dan rollback dapat digunakan kembali untuk rotasi secret dan deployment versi secret.
• Nilai ini dapat diluncurkan secara bertahap, sehingga mengurangi dampak deployment nilai yang buruk.

Catatan: Menyelesaikan versi terbaru saat deployment dapat memblokir deployment jika setidaknya ada versi secret yang buruk. Menyelesaikan masalah saat deployment mungkin tidak terlalu terisolasi atau tidak dapat direproduksi karena keberhasilan peluncuran bergantung pada status versi rahasia di Secret Manager. Jika versi secret sebelumnya berfungsi, buat versi secret baru dengan nilai yang sama dan tunggu hingga diluncurkan. Pada dasarnya, tindakan ini adalah "roll forward" dan memerlukan izin secretmanager.versions.access pada secret untuk menyalin nilai dari versi lama ke versi baru.

Pendekatan 2: Menyelesaikan saat memulai aplikasi

Ambil payload rahasia terbaru saat aplikasi dimulai dan terus gunakan rahasia selama durasi aplikasi.

Keuntungan dari pendekatan ini adalah bahwa pendekatan ini tidak memerlukan modifikasi pipeline CI/CD untuk menyelesaikan versi secret. Namun, jika secret yang buruk diluncurkan, aplikasi akan gagal dimulai saat instance dimulai ulang atau peningkatan skala layanan dan dapat menurun menjadi pemadaman layanan.

Pendekatan 3: Selesaikan secara terus-menerus

Lakukan polling untuk versi secret terbaru secara terus-menerus di aplikasi dan segera gunakan nilai secret baru.

Pendekatan ini berisiko pemadaman layanan secara langsung di seluruh layanan karena tidak ada penerapan nilai rahasia yang baru secara bertahap.

Putar rahasia Anda

Jika secret dapat diperbarui secara dinamis (misalnya, jika sistem eksternal yang memvalidasi secret menyediakan Admin API), sebaiknya siapkan tugas rotasi yang berjalan secara berkala. Langkah-langkah umum diuraikan di bagian berikut terkait Cloud Run sebagai contoh lingkungan komputasi.

Mengonfigurasi jadwal rotasi pada Secret Anda

Siapkan jadwal rotasi untuk secret Anda. Topik Pub/Sub harus dikonfigurasi di secret untuk menerima notifikasi saat tiba waktunya untuk merotasi rahasia Anda. Lihat panduan Notifikasi Peristiwa untuk mengonfigurasi topik mengenai secret Anda.

Luncurkan Cloud Run untuk membuat versi secret baru

Buat dan konfigurasi layanan Cloud Run untuk menerima notifikasi rotasi dan menjalankan langkah rotasi:

1. Mendapatkan atau membuat secret baru di sistem eksternal (misalnya, database, penyedia API).

   Pastikan tindakan ini tidak membatalkan secret yang sudah ada sehingga beban kerja yang ada tidak terpengaruh.

2. Mengupdate Secret Manager dengan secret baru.

   Buat SecretVersion baru di Secret Manager. Tindakan ini juga akan memperbarui alias latest agar mengarah ke secret yang baru dibuat.

Percobaan Ulang dan Konkurensi

Karena proses rotasi dapat dihentikan kapan saja, layanan Cloud Run harus dapat memulai ulang proses dari posisi terakhir (harus reentrant).

Sebaiknya konfigurasikan ulang di Pub/Sub sehingga rotasi yang gagal atau terganggu dapat dijalankan kembali. Selain itu, konfigurasikan instance maksimum konkurensi dan instance maksimum di layanan Cloud Run Anda untuk meminimalkan kemungkinan eksekusi rotasi serentak yang mengganggu satu sama lain.

Untuk membuat fungsi rotasi reentrant, sebaiknya simpan status agar proses rotasi dapat dilanjutkan. Ada dua fitur Secret Manager yang dapat membantu hal ini:

• Menggunakan label pada Rahasia untuk menyimpan status selama rotasi. Tambahkan label ke Secret untuk melacak jumlah versi terakhir yang berhasil ditambahkan selama alur kerja rotasi (yaitu ROTATING_TO_NEW_VERSION_NUMBER=3). Setelah rotasi selesai, hapus label pelacakan rotasi.
• Gunakan etag untuk memverifikasi bahwa proses lain tidak secara serentak mengubah secret selama alur kerja rotasi. Pelajari etag versi rahasia dan rahasia lebih lanjut.

Catatan: Etag untuk versi secret dan secret tidak saling bergantung. Dengan kata lain, menambahkan versi baru tidak akan mengubah etag rahasia induk.

Izin Identity and Access Management

Proses rotasi Anda akan memerlukan izin secretmanager.versions.add untuk menambahkan versi secret baru, dan mungkin memerlukan secretmanager.versions.access untuk membaca versi secret sebelumnya.

Akun layanan Cloud Run default memiliki peran Editor, yang mencakup izin untuk menambahkan, tetapi tidak mengakses versi secret. Untuk mengikuti prinsip hak istimewa terendah, sebaiknya JANGAN menggunakan akun layanan default. Sebagai gantinya, siapkan akun layanan terpisah untuk layanan Cloud Run Anda dengan peran Secret Manager yang diberikan sesuai kebutuhan (mungkin salah satu atau beberapa):

• roles/secretmanager.secretVersionAdder
• roles/secretmanager.secretVersionManager
• roles/secretmanager.secretAdmin
• roles/secretmanager.secretAccessor

Meluncurkan SecretVersion baru ke workload

Setelah SecretVersion baru yang valid telah didaftarkan ke sistem eksternal dan disimpan di Secret Manager, luncurkan ke aplikasi Anda. Peluncuran ini bervariasi berdasarkan pendekatan Anda terhadap binding secret (lihat bagian Binding ke versi secret) dan umumnya tidak memerlukan intervensi manual.

Membersihkan versi secret lama

Setelah semua aplikasi dirotasikan dari versi secret lama, aplikasi tersebut dapat dibersihkan dengan aman. Proses pembersihan akan bergantung pada jenis secret, tetapi umumnya:

1. Pastikan versi secret baru telah diluncurkan sepenuhnya ke semua aplikasi.
2. Nonaktifkan versi secret lama di Secret Manager dan verifikasi bahwa aplikasi tidak rusak (tunggu sejumlah waktu yang wajar untuk memungkinkan manusia melakukan intervensi jika penonaktifan membuat konsumen berhenti).
3. Hapus atau batalkan pendaftaran versi rahasia lama dari sistem eksternal.
4. Hancurkan versi secret lama di Secret Manager.

Langkah selanjutnya

• Pelajari cara menyiapkan jadwal rotasi untuk secret.