Wadah hari ini tidak akan mengejutkan siapa pun. Anda akan terkejut dengan pertanyaan tentang keamanan kontainer. Sangat menarik untuk bertanya kepada kolega yang menggunakan wadah dan layanan mikro dalam produksi dengan serius tentang hal ini: sering saya melihat wajah terkejut dan pertanyaan bingung, mereka berkata, "Apa, mengapa ini"? Ternyata kita sudah tahu tentang teknologi (dan bagaimana kita tidak bisa tahu: tampaknya bahkan anak sekolah akan segera dapat membangun kluster Kubernetes secara keseluruhan dalam pelajaran teknologi), tetapi mereka belum belajar bagaimana melindungi komponen-komponennya. Mungkin tidak ada yang mengajar.
Dalam artikel ini dan di
DevOops , kami akan memiliki pembicara yang memakan seekor anjing tentang topik solusi keamanan ramah wadah. Kami mendatangi mereka untuk menjawab pertanyaan keamanan cloud paling sederhana. Apakah perlu untuk memulai pendidikan mandiri dengan sesuatu?
Peserta:
Seth Vargo menjalankan Advokasi Pengembang di Google. Dia sebelumnya bekerja di HashiCorp, Chef Software, CustomInk, dan beberapa startup lain di Pittsburgh. Dia adalah penulis Learning Chef dan pendukung untuk mengurangi kesenjangan teknologi.
Liz Rice adalah penginjil teknis di Aqua Security, solusi keamanan penyebaran aplikasi berbasis cloud dan perusahaan kontainer. Liz adalah orang yang sangat terkenal di komunitas, ketua Kubeon-s .
Oleg Chirukhin, editor Grup JUG.ru
Mari kita mulai dengan pertanyaan yang akan menentukan diskusi kita selanjutnya. Apa arti DevOps bagi Anda? Apa bedanya dengan SRE yang kurang dikenal?
Misalnya, dalam pekerjaan sebelumnya, ketika saya diminta untuk "mengimplementasikan DevOps", saya hanya berjalan di sekitar daftar isi SRE Book , mengambil ide dan menerapkannya satu per satu. Ya, atau setidaknya saya mencoba menyampaikannya kepada orang lain. Apa yang Anda katakan - apakah ini pendekatan yang tepat?
Jika kita berbicara tentang DevOps, kita berbicara tentang menghindari jurang maut, dari celah yang biasanya antara proses pengembangan kode (Dev) dan pemeliharaan selanjutnya (Ops). Bayangkan kita memiliki tembok tinggi, di satu sisi tempat pengembang duduk, dia membuat kode, melemparkannya ke dinding. Di sisi lain tembok ada orang yang mendukung. Mereka menangkap aplikasi yang ditransfer dan mulai meluncurkan dan memelihara. Dan orang-orang ini tahu detail yang dibutuhkan selama operasi. Misalnya, port mana dan di mana akan dialokasikan dan dibuka.
Alih-alih memiliki dua kelompok orang yang berbeda dengan minat yang berbeda, saya ingin membuat mereka berkomunikasi satu sama lain, memutuskan apa yang harus dilakukan selanjutnya, bersama-sama menentukan tujuan apa yang akan mereka capai bersama selama hari kerja. Jadi DevOps adalah perubahan dalam budaya komunikasi yang membantu kolega di berbagai tim teknis bekerja untuk kebaikan bersama: menciptakan nilai untuk bisnis, menyebarkan perangkat lunak, dan membuatnya tetap berfungsi. Saya pikir ini adalah perubahan yang sangat penting, dan mereka membawa alat terkait baru: jika Anda tidak memiliki budaya komunikasi, maka tidak ada gunanya memperkenalkan proses CI / CD yang sama.
Sering ada kebingungan dengan konsep DevOps dan SRE. Beberapa orang berpikir bahwa SRE bersaing dengan DevOps, yang lain menganggap mereka benar-benar berbeda, konsep yang tumpang tindih. Menurut saya, mereka bukan pesaing, tetapi teman dekat. Pikirkan tentang pendekatan yang mendasari DevOps - mengurangi biaya organisasi, memperlakukan kegagalan sebagai bagian normal dari alur kerja, secara bertahap memperkenalkan perubahan, mengotomatisasi dan mengimplementasikan alat yang diperlukan untuk ini, dan menggunakan metrik untuk mengevaluasi proses. Seperti yang Anda lihat, semua ini sangat abstrak: DevOps tidak memberi tahu kami cara mengurangi biaya organisasi atau memperkenalkan perubahan bertahap, itu hanya memberi tahu Anda bahwa alangkah baiknya jika diterapkan.
Sekarang mari kita lihat SRE. Meskipun pendekatan SRE telah berkembang secara independen dari pendekatan DevOps, SRE adalah, bisa dikatakan, implementasi prinsip-prinsip DevOps: jika Anda membayangkan DevOps sebagai kelas abstrak atau antarmuka dalam pemrograman, SRE akan menjadi kelas konkret yang mengimplementasikan antarmuka ini. SRE secara jelas mendefinisikan pendekatan terhadap sejumlah hal dan konsep: kepemilikan bersama, berbagi risiko, post-mortem, pengumpulan dan akumulasi nilai-nilai metrik dan banyak lagi. Oleh karena itu, lebih mudah bagi organisasi untuk berbicara tentang adopsi SRE karena adanya proses dan entitas yang sangat dimengerti.
Apakah Anda pikir istilah "insinyur DevOps" benar? Bisakah itu diganti dengan cara tertentu?
Saya pribadi tidak percaya bahwa konsep "insinyur DevOps" ada. Anda dapat membaca lebih detail di artikel saya "10 mitos DevOps" bahwa "DevOps" sebenarnya adalah ideologi: lebih banyak komunikasi dan kerja sama antara unit organisasi yang berbeda, tetapi pada dasarnya terhubung. Meskipun hari ini terlihat cukup kuat dan akrab, pada awalnya pendekatan semacam itu menimbulkan pujian dan kritik keras. Sejak itu, banyak organisasi, termasuk Etsy, Facebook, dan Flick, secara mengejutkan berhasil menerapkan prinsip-prinsip DevOps.
Jadi, tidak satu pun dari organisasi ini yang merekrut "insinyur DevOps". Keberhasilan implementasi dapat dikaitkan dengan kerja sama internal yang muncul dari tim dan kemauan untuk mengubah proses dan prosedur yang ada untuk mencapai tujuan bersama. Peran yang disebut "insinyur DevOps" adalah untuk mendorong kolaborasi antar kelompok dan untuk memastikan bahwa unit organisasi secara teratur bertukar ide dan tujuan. Sebenarnya, kita sudah memiliki orang-orang ini hari ini, dan kita menyebut mereka "manajer."
Saya akan menambahkan satu saat lagi. Ketika kita menunjuk seseorang ke posisi atau peran tertentu, kita mulai mengharapkan hal dan tindakan yang sangat spesifik darinya, jadi memilih jabatan itu penting. Tetapi nama-nama pos yang tepat mungkin berbeda karena realitas dan tradisi setempat yang diadopsi oleh organisasi, jadi yang penting bukan nama seperti itu, melainkan keseimbangan antara jabatan semua orang yang bekerja di perusahaan.
Belum lama ini saya berbicara dengan seseorang yang bekerja di organisasi yang agak besar, dan mereka menciptakan tim yang terdiri dari beberapa karyawan dan menyebutnya, katakanlah, tim infrastruktur. Kemudian tim ini diubah namanya menjadi sesuatu yang lain, dan setelah beberapa saat tim lain dibuat, dan sekarang disebut tim infrastruktur - sebagai hasilnya, semua orang hanya bingung: siapa yang merupakan "spesialis infrastruktur" dan apa peran mereka.
Menurut pendapat saya, yang terpenting bukanlah keberadaan tim atau posisi dengan nama tertentu, tetapi keberadaan dalam organisasi pemahaman yang jelas tentang siapa yang bertanggung jawab atas apa. Tidak masalah apakah mereka memanggil mereka SRE atau DevOps: yang terpenting adalah memahami apa arti nama spesifik untuk organisasi khusus ini.
Liz, Anda berkonsultasi, bagaimana Anda menjelaskan prinsip-prinsip DevOps kepada perusahaan klien? Kedengarannya abstrak dan agak sulit dijelaskan. Atau mungkin Anda telah mengembangkan semacam pendekatan yang memungkinkan Anda untuk menyampaikan ide-ide ini kepada pelanggan?
Itu tergantung tujuannya. Banyak orang dan perusahaan yang berkomunikasi dengan saya sebagai bagian dari konsultasi datang kepada kami dan mengatakan bahwa mereka ingin menggunakan Kubernet dan wadah. Tetapi sebelum berbicara tentang teknologi, Anda perlu memahami mengapa mereka mencoba mengambil langkah-langkah seperti itu. Dan ternyata manfaat perubahan yang diharapkan sering datang ke keinginan untuk menjadi lebih fleksibel. Karenanya gerakan ke arah bahwa tim teknis dapat merilis hasil pekerjaan mereka lebih cepat, sesuatu seperti itu, menjelaskan "dengan jari". Pada titik ini, penting untuk mengalihkan pembicaraan ke sisi bahwa masalah kurangnya budaya (kebiasaan, jika Anda suka) komunikasi antara anggota tim tidak akan terbantu dengan "melempar" teknologi baru, bahwa komunikasi adalah sumber daya yang paling penting.
Selain itu, karena saya sering menemukan diri saya terlibat dalam meningkatkan keamanan solusi, percakapan kami bergeser ke arah "Dev - ** Sec ** - Ops", dan ternyata sistem harus dibangun sehingga keamanan dijaga oleh sebagian besar pada tahap awal proses, dan tidak hanya mendekati pertanyaan dengan cara lama: pertama kita menulis kode aplikasi, kemudian kita menyebarkannya, kemudian kita meneruskannya ke layanan pemeliharaan, dan hanya pada akhirnya seseorang mulai berpikir tentang keamanan yang berjalan.
Faktanya, banyak masalah keamanan lebih murah dan lebih mudah untuk dipecahkan pada awal proses, tetapi Anda harus meletakkan banyak poin dalam proyek sejak awal. Misalnya, jika Anda bermaksud bekerja dengan wadah, Anda perlu khawatir bahwa gambar dikumpulkan dengan cara yang cukup aman. Mungkin bermanfaat untuk memindai kerentanan mereka untuk setidaknya menghindari penggunaan perangkat lunak dengan masalah keamanan yang sudah diketahui. Mungkin Anda akan mencoba untuk mengkonfigurasi wadah sehingga perangkat lunak di dalamnya tidak mulai secara default dengan root (seperti sering demi kesederhanaan, tanpa kebutuhan khusus, mereka dilakukan ketika merakit wadah). Jika Anda mengambil langkah-langkah ini, pada akhirnya Anda akan menerima peningkatan keamanan aplikasi Anda, dan Anda dapat, dalam konteks semua DevOps ini, berbicara tentang budaya SecOps.
Namun, ini berarti bahwa pengembang, pada kenyataannya tidak menjadi pakar keamanan aplikasi, dipaksa untuk tidak hanya memikirkan kode aplikasi, tetapi juga membuat sistem keamanan mereka sendiri. Kalau begitu, menurut Anda, apa yang harus set keterampilan minimum untuk pengembang perangkat lunak modern atau insinyur operasi?
Anda dan saya, suka atau tidak suka, terus-menerus melihat munculnya peraturan dan persyaratan baru yang pada beberapa titik ternyata perlu dipenuhi dan dipatuhi: ambil GDPR yang sama sebagai contoh. Munculnya dan keberadaan peraturan ini berarti bahwa semakin banyak orang harus memiliki rasa aman. Misalnya, hari ini Anda tidak lagi dapat menyimpan nama pengguna dan kata sandi dalam bentuk plaintext di bidang basis data - ini tidak lagi dianggap setidaknya dapat ditoleransi. Saya akan mengatakan bahwa dalam industri sudah cukup jelas bagi semua orang persyaratan untuk "kebersihan".
Pembuat alat dan infrastruktur sendiri memiliki dampak signifikan pada proses ini, mencoba mendesain dan mengubah sistem sehingga pengguna dapat membangun aplikasi dan sistem yang lebih aman sejak awal. Sebagai contoh, di Kubernetes selama setahun terakhir, banyak pengaturan default dan nilai parameter telah berubah ke arah keamanan yang lebih besar, dan ini benar-benar sangat keren. Sebelumnya, secara default, server API terbuka untuk akses anonim - ini tidak seperti yang Anda harapkan “out of the box”. Sekarang hal-hal seperti kontrol akses berbasis peran telah muncul, jadi kami sekarang memiliki izin (ya, "di luar kotak"), dan ketika Anda pertama kali memulai Kubernet Anda tidak terbuka untuk seluruh dunia, Anda dilindungi secara default. Saya pikir ini adalah cara yang baik untuk membuat keamanan tersedia untuk semua orang dalam proses proses yang akrab, karena kita tidak harus terus-menerus mengubah nilai default menjadi yang aman (yang, terlebih lagi, harus selalu diingat).
Secara pribadi, saya percaya bahwa setiap insinyur perangkat lunak harus memiliki setidaknya pemahaman dasar tentang keamanan. Hal-hal seperti pendekatan OWASP (Open Security Application Project) datang untuk menyelamatkan, tetapi pada akhirnya para insinyur perlu dididik sendiri. Tidak mungkin bahwa setiap insinyur memiliki gelar Ph.D dalam kriptografi, tetapi jika kita ingin rekan kita menganggap keamanan dengan serius, kita harus membuatnya lebih mudah bagi mereka untuk membuat keputusan yang tepat. Di sinilah alat seperti Vault dapat membantu - dan tim keamanan dan profesional dapat membuat keputusan serta memberikan "keamanan sebagai API".
Jika saya mengerti dengan benar, ada kecenderungan untuk mengubah semuanya menjadi kode. Semuanya Sebagai Kode. Infrastruktur sebagai kode, memproses sebagai kode, kode sebagai kode. Apa implikasinya?
Sebelum kita berbicara tentang konsekuensinya, kita perlu membicarakan manfaatnya. Kode ini sudah ada sejak lama. Aplikasi selalu menjadi "kode", dan selama ini ekosistem yang luas dari alat dan proses telah dibuat untuk mendukung dan meningkatkan proses pengembangan aplikasi (CI / CD, linting, alat untuk pengembangan bersama, dll.). Setelah menggambarkan infrastruktur sebagai kode, proses sebagai kode, keamanan sebagai kode, kita dapat menggunakan ekosistem yang sama, tanpa membayar apa pun tambahan untuk ini. Anda dapat bersama-sama mengembangkan perubahan infrastruktur, melakukan tinjauan kebijakan, dll. Anda dapat menguji perubahan infrastruktur sebelum menerapkannya. Ini hanya beberapa manfaat yang datang dengan menerjemahkan sesuatu ke dalam kode.
Saya pikir konsekuensi terbesar adalah waktu dan kompleksitas. Ketika Anda bekerja dengan sesuatu "seperti dengan kode" (misalnya, melalui Terraform, Vault, CloudFormation, Deployment Manager, dll.), Kadang-kadang Anda harus menemukan perbedaan antara apa yang tertulis dalam kode dan apa yang sebenarnya terjadi di awan. Membuat model hubungan yang kompleks kadang-kadang sulit dilakukan secara visual, terutama mengingat penskalaan. Selain itu, kami mungkin mengalami ketidaktepatan abstraksi - misalnya, skrip yang bekerja melalui API mungkin tidak memahami kondisi terkini seperti yang ditampilkan kepada pengguna melalui antarmuka web. Namun, seiring waktu, kompleksitas berkurang dan fleksibilitas kembali.
Kode dan model formal lainnya adalah bidang yang cocok untuk analisis mesin dan pembelajaran mesin. Kapan tepatnya robot akan menggantikan kita? Bagaimana seharusnya kita merespons?
Bisakah robot mengkonfigurasi Kubernetes tanpa manusia? Secara khusus, mungkin terjadi bahwa beberapa profesi (seperti administrator sistem atau penguji perangkat lunak dengan interaktivitas tingkat tinggi - kata yang dapat diterima secara sosial untuk "penguji manual") hilang begitu saja?
Saya tidak berpikir bahwa orang akan menghilang, tetapi saya curiga bahwa beberapa pekerjaan yang kita miliki saat ini tidak akan diselamatkan di masa depan. Saya tinggal di Pittsburgh, ibu kota dunia sistem kontrol mobil otonom, dan saya melihat mobil self-driving setiap hari. Di masa depan, tentu saja, pengemudi taksi akan digantikan oleh teknologi mengemudi robot. Mungkin tidak langsung, tetapi setelah 10 tahun atau lebih, tetapi masa depan ini pasti akan datang. Namun, saya pikir supir taksi tidak akan hilang. Kemanusiaan terus-menerus menciptakan kembali dirinya.
Saya percaya bahwa hal yang sama dapat dikatakan tentang pembelajaran mesin di bidang manajemen. Saya berharap lebih banyak AI untuk membuat sistem kami lebih stabil dan tangguh, dan saya pikir kami bisa memutuskan untuk melawan pendekatan ini - atau menerimanya. Peran administrator sistem tradisional dapat digantikan oleh seseorang yang mengendalikan sistem AI, tetapi ini tidak berarti bahwa orang itu sendiri akan menghilang. Kami mengalami perubahan yang sama di beberapa industri di mana teknologi dan inovasi memberikan kecepatan dan akurasi yang lebih tinggi daripada orang, tetapi pada akhirnya, seseorang harus mengikuti robot :).
Bayangkan bahwa tim pengembangan reguler membuat aplikasi web, menempatkannya di kluster Kubernetes. Bagaimana kita memastikan aplikasi itu aman? Pekerjakan seorang hacker atau spesialis blackhat yang mencoba menemukan kelemahan keamanan, atau adakah cara yang tidak rumit?
Kami di Aqua Security baru-baru ini merilis alat sumber terbuka yang disebut kube-hunter . Ia mampu menguji Kubernet untuk peretasan atau penetrasi - menjadikannya sebuah tes yang cukup sederhana. Anda dapat mengambil alat ini dan menguji cluster Anda sendiri, dan Anda hampir pasti akan belajar sesuatu yang menarik untuk diri Anda sendiri, terutama jika instalasi Anda didasarkan pada versi Kubernetes lama, di mana pengaturan default kurang aman - mungkin Anda miliki, misalnya, port terbuka.
Kami semua mendengar cerita tentang orang-orang yang "lupa" untuk menutup panel kontrol cluster mereka dari akses gratis ke seluruh Internet, jadi tujuan membuat pemburu kubus adalah untuk memeriksa sistem kami sendiri dan memastikan bahwa itu dilindungi. Menurut pendapat kami, peretas telah lama memindai host di Internet untuk sumber daya dan porta terbuka yang terkenal, sehingga panel kontrol Kubernet Anda, yang kebetulan tidak dilindungi (dan karenanya terbuka untuk semua orang), mungkin tidak terlalu sulit ditemukan, terutama dengan alat yang mereka terbiasa menggunakan.
Kami ingin pemburu untuk membantu administrator Kubernetes yang biasa memahami dengan lebih baik jika ada masalah konfigurasi dalam penyebaran mereka, sehingga ia dirancang khusus untuk Kubernetes dan melaporkan bahwa ia ditemukan dalam bahasa yang dimengerti pengguna Kubernetes. Jadi kami akan memberi tahu Anda bahwa Anda belum membuka port 6443, tetapi, katakanlah, akses ke komponen khusus Kubernetes ini. Dengan cara ini, lebih mudah bagi orang untuk menentukan apakah apa yang mereka temukan adalah masalah dengan konfigurasi pelemahan keamanan dan apakah layak untuk segera memperbaikinya - tanpa menjadi pakar keamanan Kubernetes. Kami ingin mencoba membuat cek ini tersedia kapan saja, tanpa perlu ahli luar.
Ada pengamatan: banyak yang tidak lagi tertarik dengan apa yang ada di dalam wadah yang mereka luncurkan.
Ya, dan mereka tidak tahu ketergantungan apa yang dibangun dalam wadah ini. Meskipun, jika Anda membuat rencana untuk menggunakan pendekatan wadah untuk menyebarkan layanan, tampaknya masuk akal untuk mengetahui jenis perangkat lunak apa yang ada di dalam gambar ini atau itu. Tapi ini bukan masalah pendekatan wadah itu sendiri, itu hanya sikap terhadap keamanan di pihak mereka yang menggunakan pendekatan itu.
Tidak begitu sulit untuk melakukan semuanya dengan benar dan andal. Katakanlah, ketika Anda pindah ke dunia cloud, Anda harus mulai menggunakan alat tambahan - yang hampir pasti akan menambah tingkat keamanan tambahan.
Awan memiliki kekhasan masing-masing. Sebagai contoh, saya sering menemui kesalahpahaman bahwa di dunia cloud, alat yang digunakan orang di masa lalu akan secara otomatis melakukan semua yang mereka butuhkan. Dalam beberapa hal, mereka benar: katakanlah Anda dapat menggunakan daftar pengaturan firewall yang biasa (dan selalu berfungsi), dan ini akan meningkatkan keamanan, tetapi beberapa alat lama tidak lagi cocok hari ini. Misalnya, jika Anda menggunakan gambar kontainer dan menggunakan alat lama yang dikenal untuk memindai kerentanan, maka jika pemindai tidak tahu cara melihat ke dalam gambar, itu tidak akan menemukan apa-apa, dan Anda akan (mungkin salah) percaya bahwa semuanya beres.
Saya sangat suka itu ketika Anda beralih ke arsitektur microservices, Anda mendapatkan sejumlah besar fungsi kecil yang ditata dalam wadah (isinya ada di telapak tangan Anda) dan Anda dapat melihat lalu lintas di antara mereka. Masing-masing wadah dapat dianggap sebagai semacam kotak hitam, yang darinya tindakan yang ditentukan sangat diharapkan. Dan segera setelah wadah ini atau itu mulai berperilaku dengan cara yang tidak terduga atau untuk menghasilkan hasil yang aneh, menjadi mungkin untuk menanggapi ini. Semakin baik gambar spesifik wadah dirakit dan dikonfigurasikan, semakin dapat dimengerti apakah itu berfungsi dengan baik.
Dan bagaimana cara menangkap anomali? Gunakan sesuatu seperti heuristik antivirus, jaringan saraf?
Sepanjang siklus hidup perangkat lunak, kami menggunakan berbagai alat keamanan. runtime enforcer — , , . «», , , nginx, , nginx . , , «» , . , , . : , , .
. Serverless , , . . « »? , ?
, severless , , , . serverless — . severless-, «», . , «- ». severless. serverless- . «» , ( «» ) .
serverless – « ». serverless- pub/sub, , Redis . , , - () .
severless- , . , , , serverless- . - . , , , . serverless, - .
, serverless- . , , . ?
, , — , , , DevOps. , , , , .
, , : YAML. , Kubernetes Kubernetes, YAML. , 30 000 YAML. , , , 30 000 YAML, , , .
, Kubernetes . , , ?
Kubernetes , . , , , , - , . , , YAML- , , Kubernetes . , . , .
, Kubernetes — , . . , Kubernetes CNCF graduated, , , , , CNCF .
, : YAML, , . , YAML Kubernetes.
, YAML, , , , YAML. , , , - YAML .
, Kubernetes, , ?
Pertanyaan yang bagus , , , , . – Istio ( service mesh), 1.0. , , , «».
, - , .
, ?
C . , , , , !
! , : — .
DevOops 2018 «Modern security with microservices and the cloud» , «Practical steps for securing your container deployment» . .