Secara Otomatis Menerapkan Pembaruan Keamanan untuk AWS Elastic Beanstalk

Saya sudah menjadi penggemar Heroku sejak hari-hari awal. Tapi saya suka fakta bahwa AWS Elastic Beanstalk memberi Anda kontrol lebih besar atas karakteristik instans. Satu hal yang saya sukai dari Heroku adalah kenyataan bahwa saya dapat menggunakan suatu aplikasi dan tidak khawatir tentang pengelolaannya. Saya berasumsi Heroku memastikan semua pembaruan keamanan OS diterapkan tepat waktu. Saya hanya perlu memastikan aplikasi saya aman.

Penelitian awal saya di Beanstalk menunjukkan bahwa meskipun membangun dan mengonfigurasi instance untuk Anda, setelah itu pindah ke proses manajemen yang lebih manual. Pembaruan keamanan tidak akan secara otomatis diterapkan pada instance. Tampaknya ada dua bidang yang menjadi perhatian:

• Rilis AMI baru - Saat rilis AMI baru nampaknya kami ingin menjalankan yang terbaru (mungkin paling aman). Tetapi penelitian saya tampaknya mengindikasikan Anda perlu meluncurkan pengaturan baru secara manual untuk melihat versi AMI terbaru dan kemudian menciptakan lingkungan baru untuk menggunakan versi baru itu . Apakah ada cara otomatis yang lebih baik untuk memutar instance Anda menjadi rilis AMI baru?
• Di antara rilis akan ada pembaruan keamanan dirilis untuk paket. Sepertinya kami ingin memutakhirkannya juga. Penelitian saya tampaknya menunjukkan orang menginstal perintah untuk sesekali menjalankan pembaruan yum. Tetapi karena instance baru dibuat / dihancurkan berdasarkan penggunaan, sepertinya instance baru tidak selalu memiliki pembaruan (yaitu waktu antara pembuatan instance dan pembaruan yum pertama). Jadi kadang-kadang Anda akan memiliki contoh yang tidak ditambal. Dan Anda juga akan memiliki instans yang terus-menerus memperbaiki diri hingga rilis AMI yang baru diterapkan. Kekhawatiran saya yang lain adalah bahwa mungkin pembaruan keamanan ini belum melalui tinjauan Amazon sendiri (seperti rilis AMI lakukan) dan mungkin merusak aplikasi saya untuk secara otomatis memperbaruinya. Saya tahu Dreamhost pernah mengalami pemadaman 12 jam karena mereka menerapkan pembaruan debian sepenuhnya secara otomatis tanpa ulasan apa pun. Saya ingin memastikan hal yang sama tidak terjadi pada saya.

Jadi pertanyaan saya adalah apakah Amazon menyediakan cara untuk menawarkan PaaS yang dikelola sepenuhnya seperti Heroku? Atau apakah AWS Elastic Beanstalk benar-benar lebih dari sekadar skrip instalasi dan setelah itu Anda melakukannya sendiri (selain alat pemantauan dan penyebaran yang mereka sediakan)?

Pertama-tama, untuk menjadi jelas, tidak ada Elastic Beanstalk bukan PaaS dalam cara Anda berpikir tentang hal itu. Jika Anda memecahnya menjadi beberapa bagian, itu benar-benar lebih seperti memiliki template contoh tervirtualisasi dan otomatisasi penyebaran aplikasi seperti boneka atau koki. Seiring dengan ini, Anda mendapatkan akses otomatis ke layanan penyeimbang muatan, dan pemantauan cloud watch, yang memungkinkan Anda untuk memulai server aplikasi baru atau mematikan yang sudah ada berdasarkan metrik.

Apa yang membuatnya terasa seperti PaaS adalah bahwa titik penjualan utama adalah sistem penyebaran aplikasi yang mengambil kode Anda dan menyalinnya ke semua server aplikasi di cluster Anda.

Salah satu keluhan sebagian orang tentang PaaS adalah bahwa vendor PaaS membuat keputusan untuk Anda tentang lingkungan aplikasi. Bagi saya ini seperti proposisi nilai PaaS: sebagai pelanggan Anda bisa berkonsentrasi pada fungsionalitas aplikasi dan menyerahkan semua detail lainnya ke vendor PaaS. Anda membayar orang lain untuk mengelola infrastruktur dan menyediakan administrasi sistem. Untuk kesederhanaan Anda membayar mereka premi, seperti dalam kasus Heroku, yang menjalankan infrastruktur mereka di atas EC2 juga, hanya dengan cara yang transparan bagi Anda.

Amazon benar-benar menawarkan Elastic Beanstalk di atas Ec2 dan api REST mereka, dan tidak berusaha menyembunyikannya dari Anda. Ini karena mereka menghasilkan uang melalui IaaS, dan EB hanya mengatur pengaturan sekelompok sumber daya EC2 yang bisa Anda siapkan sendiri, diberi waktu dan tahu caranya.

Sekarang, dalam hal spesifikasi AMI, sekali lagi AMI adalah salah satu dari sekian banyak EC2 yang digunakan untuk memfasilitasi EB. Tidak ada yang ajaib tentang EB AMI - hanya Amazon linux yang telah dikonfigurasikan sebelumnya untuk bekerja dengan EB. Seperti AMI lainnya, Anda dapat memulainya di EC2, mengubah, dan mendapatkan AMI baru yang disesuaikan dari instance berjalan Anda. Amazon Linux pada dasarnya adalah persilangan antara Centos dan Fedora, dengan tambalan paravirtualization, dan repo yum pra-konfigurasi yang dikelola oleh Amazon.

Seperti yang mungkin Anda ketahui, Amazon linux sudah dikonfigurasi untuk menginstal patch keamanan saat boot. Namun, menjalankan instance tidak berbeda dengan server lain dalam hal penambalan. Penambalan dapat mengganggu layanan. Jika Anda sangat khawatir dengan perbaikan keamanan, Anda selalu dapat menggunakan perintah kontainer dan mengatur cron untuk menjalankan pembaruan yum - keamanan di beberapa periode waktu tertentu.

Anda juga dapat memanfaatkan API EB untuk mengubah konfigurasi EB, atau mengotomatiskan penciptaan lingkungan EB baru, Anda kemudian dapat bertukar ke itu setelah dan siap, diikuti dengan mematikan yang lama. Ini dijelaskan di sini: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html

Seperti AWS lainnya, ada cara untuk secara terprogram mengakses dan mengontrol setiap fitur non SaaS, jadi tidak ada yang menghentikan Anda membuat AMI yang ditambal, yang kemudian digunakan untuk membuat lingkungan EB baru, dan meluncurkannya. EB tidak akan memaksakan spesifikasi konfigurasi pada Anda, juga tidak memberikan Anda grup administrasi sistem untuk mempertahankan infrastruktur.

Pada April 2016, Elastic Beanstalk mendukung pembaruan platform otomatis:

https://aws.amazon.com/about-aws/whats-new/2016/04/aws-elastic-beanstalk-introduces-managed-platform-updates/

Semua aplikasi dan lingkungan Beanstalk dapat dikonfigurasi melalui file EBEXTENSIONS yang dikemas dengan paket penerapan aplikasi Anda (misalnya file WAR untuk aplikasi Java) dengan konfigurasi berbasis YAML untuk memperbarui atau mengkonfigurasi ulang setiap bagian dari aplikasi, wadah, OS, dll. Beanstalk adalah PaaS karena itu adalah platform yang memungkinkan Anda untuk menyebarkan aplikasi tanpa harus khawatir tentang IaaS yang mendasarinya. Semua penyedia PaaS pada akhir hari mengaburkan IaaS yang mendasarinya melalui beberapa bentuk otomatisasi. Namun karena ini adalah ilmu komputer yang kita bicarakan tidak ada satu keadaan optimal untuk semua aplikasi dan tanpa kemampuan untuk men-tweak IaaS di bawah PaaS, Anda berada di bawah kekuasaan penyedia layanan PaaS untuk memastikan Anda bahwa aplikasi Anda berjalan dengan lancar, cepat dan aman.

Heroku berjalan di atas AWS menggunakan lapisan manajemen berbeda. Namun itu menjadi menyebalkan ketika Anda harus melakukan hal-hal seperti mengamankan aplikasi Anda. Meskipun mereka melakukan upaya terbaik untuk mengelola solusi mereka secara efisien dan menjaga keamanan dll. Mereka tidak dapat dan tidak akan mengambil risiko dan konsekuensi dari kerentanan dalam aplikasi Anda pada akhirnya. Mereka ingin membuat layanan mereka sebagai pemotong kue mungkin.

Kemampuan untuk men-tweak IaaS yang mendasari platform adalah kekuatan dan daya tarik Beanstalk IMO.