AWS menambahkan penyedia kredensial beban kerja untuk pengiriman sertifikat dan rahasia

AWS memperkenalkan AWS Workload Credentials Provider, sebuah layanan klien sumber terbuka yang memberi aplikasi jalur lokal untuk sertifikat dan rahasia dari AWS Secrets Manager dan AWS Certificate Manager.

Provider ini menargetkan masalah operasional yang sudah familiar: tim menyimpan rahasia dan sertifikat di layanan cloud terkelola, lalu menulis skrip mereka sendiri untuk mengambilnya, menyimpannya dalam cache, menaruhnya ke disk, dan memuat ulang NGINX, Apache, atau layanan lain yang bergantung sebelum sertifikat kedaluwarsa. AWS kini menawarkan agen first-party untuk pekerjaan sisi klien tersebut.

AWS merancang alat ini untuk beban kerja di AWS, di pusat data, dan di lingkungan lain. Hal ini penting bagi tim yang menjalankan lingkungan hybrid tetapi sudah menggunakan AWS untuk penerbitan sertifikat atau penyimpanan rahasia. Sebuah layanan pada instance EC2, server Windows, atau host Linux on-premises dapat memakai sumber terkelola yang sama tanpa harus sepenuhnya berpindah ke runtime AWS.

Pengembang mengonfigurasi provider ini dengan file TOML. File tersebut mendefinisikan ARN sertifikat, ARN peran IAM, jalur output untuk materi sertifikat, file kunci privat, rantai sertifikat, perintah penyegaran, logging, dan perilaku runtime. Provider kemudian mengambil materi yang dikonfigurasi, menulis file dengan izin terbatas, dan menyegarkan salinan lokal ketika AWS melaporkan adanya perubahan konten.

AWS mengatakan provider ini mendukung ekspor sertifikat ACM untuk sertifikat TLS publik dan privat. Itu memberi arsitek satu opsi lagi untuk server web dan endpoint layanan yang memerlukan aset TLS berbasis file, termasuk stack yang tidak dapat memanggil API AWS di dalam jalur permintaan.

Dukungan Secrets Manager memperluas model AWS Secrets Manager Agent yang lebih lama. Tim yang sudah menerapkan agen tersebut dapat melihat Workload Credentials Provider sebagai jalur penerus yang lebih luas, karena AWS telah memposisikan proyek baru ini untuk menangani rahasia sekaligus sertifikat.

Provider memeriksa sertifikat yang dikonfigurasi setiap 24 jam. Ia juga menjalankan penyegaran awal saat startup, menyebar waktu penyegaran di antara host untuk menghindari lonjakan permintaan, dan memungkinkan operator memuat ulang konfigurasi tanpa menginstal ulang layanan. Tim dapat mengonfigurasi hingga 50 sertifikat, dan provider mengelola setiap sertifikat dalam prosesnya sendiri.

Model proses itu memberi operator batas blast radius yang berguna. Kegagalan pada satu alur kerja sertifikat seharusnya tidak menghentikan provider mengelola sertifikat lain pada host yang sama. Tim yang menjalankan server multi-tenant atau gateway bersama akan memperhatikan isolasi tersebut.

Perintah reload menutup celah antara rotasi sertifikat dan penggunaan aplikasi. Sebuah provider dapat menulis sertifikat baru ke /etc/pki/tls/certs/example.com.crt, menulis kunci ke /etc/pki/tls/private/example.com.key, memperbarui file chain, dan menjalankan /usr/sbin/nginx -s reload. Operator tidak lagi membutuhkan cron job terpisah yang menebak kapan ACM mengubah sertifikat.

Penerapan Linux memerlukan systemd. Penerapan Windows memerlukan PowerShell 5.1 atau yang lebih baru. AWS menjalankan layanan ini di bawah pengguna berprivilege rendah, yang sesuai dengan pola yang diinginkan tim keamanan untuk agen kredensial lokal: berikan agen izin host minimum yang dibutuhkannya untuk menulis file dan memicu perintah reload yang terbatas.

Arsitektur ini akan menarik bagi tim yang menggunakan perangkat lunak berbasis file. Web server, layanan Java lama, service mesh dengan file watcher, dan appliance siap pakai sering kali mengharapkan sertifikat dan kunci berada di disk. Pengembang dapat mengubah kode aplikasi untuk memanggil API Secrets Manager atau ACM, tetapi banyak tim operasi lebih memilih menjaga kredensial tetap di luar runtime aplikasi dan membiarkan layanan host menangani pengambilan serta rotasi.

Provider ini juga memberi pelanggan AWS jawaban native untuk pola yang banyak tim selesaikan dengan Vault Agent. HashiCorp Vault Agent dapat mengautentikasi, menyimpan cache, merender template, dan memperbarui kredensial untuk aplikasi lokal. AWS kini mencakup peran sisi klien serupa bagi pelanggan yang menyimpan sumber kebenaran mereka di Secrets Manager dan ACM.

Perbandingan itu punya batas. Vault mendukung ekosistem identitas dan rahasia yang lebih luas, termasuk kredensial database dinamis, banyak metode auth, dan rendering template lintas penyedia. Workload Credentials Provider lebih masuk akal ketika sebuah tim telah berkomitmen pada layanan terkelola AWS dan menginginkan lebih sedikit komponen bergerak di host.

Penetapan harga mengikuti layanan dasarnya. AWS tidak mengenakan biaya untuk provider itu sendiri, dan AWS merilis proyek ini di bawah lisensi Apache 2.0. Tim tetap membayar untuk Secrets Manager, fitur ACM, penggunaan API, dan infrastruktur terkait apa pun. Caching dapat mengurangi volume permintaan, tetapi arsitek sebaiknya memodelkan panggilan Secrets Manager di seluruh armada dengan banyak host dan restart yang sering.

Tim keamanan sebaiknya meninjau desain peran IAM sebelum meluncurkan provider ini. Host memerlukan izin untuk mengekspor sertifikat tertentu atau membaca rahasia tertentu. Akses baca yang terlalu luas akan menciptakan kembali risiko yang justru ingin dikurangi oleh penyimpanan rahasia terpusat. Model yang lebih bersih memberi setiap workload akses hanya ke ARN sertifikat dan ARN rahasia yang dibutuhkannya.

Operator juga sebaiknya memperlakukan file lokal sebagai aset sensitif. Provider dapat menulis kunci sertifikat dengan izin terbatas, tetapi kompromi host tetap membuka file di disk. Tim harus memasangkan alat ini dengan enkripsi disk, penguatan host, log audit, dan kontrol ketat di sekitar perintah reload.

Kasus penggunaan paling praktis dimulai dari pembaruan TLS. Sebuah tim yang menjalankan NGINX di EC2 dapat menerbitkan sertifikat di ACM, mengonfigurasi provider untuk mengekspornya, menempatkan sertifikat dan kunci pada jalur yang sudah dipakai NGINX, lalu memuat ulang NGINX setelah penyegaran. Stack aplikasi mempertahankan tata letak TLS saat ini, sementara AWS mengambil alih penerbitan sertifikat dan provider menangani pengiriman lokal.

Kasus penggunaan kedua cocok untuk aplikasi hybrid. Sebuah perusahaan mungkin menjalankan database proxy atau internal API gateway di pusat data privat sambil menyimpan rahasia di AWS. Workload Credentials Provider memungkinkan host tersebut memakai kredensial terkelola AWS tanpa menambahkan layanan sinkronisasi kustom.

Kasus penggunaan ketiga cocok untuk program migrasi. Tim dapat memindahkan penyimpanan rahasia ke AWS terlebih dahulu, lalu mengubah kode aplikasi nanti. Provider menjembatani kontrak lama berbasis file dan backend rahasia terkelola yang baru, sehingga memberi tim platform jalur migrasi dengan risiko lebih rendah.

Arsitek tetap harus memutuskan apakah file lokal cocok untuk workload tersebut. Untuk layanan cloud-native baru, panggilan SDK langsung atau identitas workload dapat menghindari penulisan materi jangka panjang ke disk. Untuk perangkat lunak yang sudah mengharapkan file, provider ini mengurangi kode kustom dan memberi operator loop refresh terkelola.

AWS juga memberi tim platform sebuah kait tata kelola. Tim pusat dapat menstandarkan ACM dan Secrets Manager, memublikasikan pola konfigurasi provider, dan membiarkan tim aplikasi memakai file lokal tanpa harus mempelajari seluruh permukaan API AWS. Ini membantu di lingkungan di mana tim operasi memiliki host dan tim aplikasi memiliki layanan yang dideploy.

Trade-off-nya berada di control plane. Tim mendapatkan jalur yang didukung AWS untuk pengiriman lokal, tetapi mereka juga mengikat lebih banyak siklus hidup kredensial ke API AWS, kebijakan IAM, dan perilaku layanan regional. Tim multi-cloud sebaiknya menguji mode kegagalan: perilaku cache yang usang, startup saat gangguan API AWS, kesalahan ekspor sertifikat, dan kegagalan reload layanan.

Workload Credentials Provider tidak akan menghilangkan kebutuhan akan arsitektur kredensial. Ia mempersempit satu bagian yang merepotkan darinya. Tim yang sudah bergantung pada Secrets Manager dan ACM dapat mengganti skrip pembaruan yang rapuh dengan layanan yang dikelola AWS, lalu menghabiskan waktu peninjauan mereka pada batas akses, kontrol host, dan keamanan rollout.

AWS telah memublikasikan proyek ini di GitHub di aws/aws-workload-credentials-provider. Tim yang mengevaluasinya sebaiknya membaca dokumentasi proyek, memastikan dukungan ekspor ACM untuk jenis sertifikat mereka, dan menguji perilaku refresh serta reload terhadap layanan yang persis mereka jalankan di produksi.