Mengapa Anda harus menghindari rahasia tertutup dalam penerapan GitOps Anda | Oleh Danielson N.

Programming

[ad_1]
Selamat datang Gaes di suratpembaca.web.id. Hari ini kita akan membahas tentang Linux yakni Mengapa Anda harus menghindari rahasia tertutup dalam penerapan GitOps Anda | Oleh Danielson N.

.

Semoga artikel mengenai Mengapa Anda harus menghindari rahasia tertutup dalam penerapan GitOps Anda | Oleh Danielson N.

bisa memberikan faedah untuk Teman-teman semua. Yuk baca postingan ini
sampai selesai.

Masalah dan alternatif untuk latihan GitOps umum ini saat memindahkan penerapan Anda ke produksi.

Foto oleh Praveen Thirumurugan di Unsplash

GitOps adalah praktik menampilkan konfigurasi sistem dalam repositori Git dan kemudian menggunakan alur kerja Git untuk mengelola perubahan dalam konfigurasi dan pembaruan sistem tersebut.

Proses menampilkan konfigurasi sistem dalam repositori pada awalnya sederhana, mengonfigurasi file, menyalin permintaan deklarasi dari dokumen produk, dan mungkin bahkan terkadang dengan urutan skrip.

Pada awalnya, Anda merasa bahwa kemajuan tidak dapat dihindari, dan kesuksesan menunggu beberapa komitmen di tikungan, lalu ketuk foil GitOps terakhir: Rahasia.

Mengapa rahasia yang jelas itu buruk

Meskipun mungkin bukan ide terbaik untuk meletakkan kredensial sederhana di repositori Git, itu masih layak dilakukan karena bermasalah, jangan sampai ada yang merasa bahwa kompromi mungkin dapat diterima saat menggunakan repositori pribadi:

Orang yang bekerja dengan repositori GitOps mungkin bukan orang yang sama yang diizinkan untuk mengelola lingkungan target.

Misalkan Anda menyetujui permintaan traksi dan memerlukan spesialis jaringan tetap untuk memeriksa perubahan firewall. Tidak menyadari bahwa kredensial disimpan dalam teks biasa di repositori, Anda meminta manajer repositori untuk menambahkan pakar tersebut ke daftar pengguna. Tiba-tiba seorang ahli jaringan mengakses database klien yang penuh dengan data pribadi. Jika orang tersebut belum diizinkan untuk tingkat akses tersebut, Anda meninjau dokumen dan langkah-langkah koreksi untuk memutar dan membuat kredensial baru.

Sekarang, mari kita asumsikan skenario yang lebih baik, di mana Anda mengetahui kredensial dalam repositori, sehingga Anda menghindari pengungkapan yang tidak disengaja: Anda sekarang harus keluar dari permintaan alur kerja untuk melibatkan orang itu dalam proses peninjauan.

Ketika skenario yang lebih baik adalah inefisiensi dan skenario terburuk seperti memanipulasi penutup mata, Anda tahu inilah saatnya untuk beralih ke latihan yang lebih baik.

Administrator panik dengan kata sandi di repositori Git.

Solusi tertutup

Gagasan rahasia yang disegel GitOps adalah untuk mengenkripsi rahasia sebelum menambahkannya ke repositori, dan membagikan kunci enkripsi pribadi dengan mereka yang perlu menggunakan rahasia itu. Biasanya, kunci enkripsi ini ditempatkan pada sistem target dan digunakan oleh agen lokal untuk mendekripsi kredensial dan menempatkannya di mana pun diperlukan di lingkungan.

Teknik ini memungkinkan orang untuk bekerja dengan repositori tanpa risiko mengungkapkan kredit secara tidak sengaja, dan ini lebih baik daripada menyimpan kredit yang terlihat.

Ini adalah pendekatan yang cerdas, dan saya cukup tertarik dengannya di awal perjalanan GitOps saya. Pengaturan awal agak mudah, repositori belum banyak digunakan setiap hari, dan mudah untuk menemukan orang lain pada tahap penerimaan yang sama untuk pendekatan ini, sehingga Anda juga dapat menemukan dukungan di komunitas.

Meninggalkan tahap awal di belakang dan pindah ke penyebaran yang lebih besar dan lebih permanen, kesederhanaan ini memberi jalan pada keterbatasan dan bahaya, dan saya meninggalkan latihan sama sekali. Di bagian berikut, saya akan menyoroti alasan utama mengapa Anda mungkin harus melewatkannya.

Alasan No. 1Kunci lingkungan yang mana?

Misalkan Anda memiliki saluran instalasi dengan pengembangan lingkungan “dev”, “test”, “stage” dan “production”. Setiap lingkungan perangkat lunak berjalan sama, tetapi jika Anda menggunakan metode SecOps yang baik, mereka akan menggunakan set kredensial yang berbeda.

Beberapa repositori GitOps dirancang untuk memiliki subpohon di setiap lingkungan target, sementara yang lain dirancang dengan pohon parameter tunggal yang digunakan di lingkungan yang berbeda.

Dalam kasus pohon folder di setiap lingkungan target, repositori git harus memiliki lokasi terpisah untuk kunci di setiap lingkungan. Saat bekerja dengan kluster Kubernetes di organisasi, Anda akan berurusan dengan sumber daya individual “rahasia” yang tersebar di beberapa ruang email, membuat perluasan folder dan file tak terhindarkan.

Jika kita melihat pohon parametrik, situasinya menjadi sedikit lebih baik dan semua rahasia untuk setiap lingkungan terkonsentrasi dalam satu file di setiap lingkungan.

Terlepas dari bagaimana repositori GitOps dirancang, penggunaan rahasia yang disegel menghasilkan lebih banyak folder dan file, yang meningkatkan jumlah informasi yang perlu diserap orang, dan jumlah artefak yang perlu dikelola oleh pipeline pengiriman.

Alasan No.2: Rahasia … ini dia.

Ya, mereka dienkripsi, dan untuk mendapatkan kredensial nyata, kunci enkripsi diperlukan, tetapi mereka masih berada di tangan aktor yang berpotensi jahat. Bayangkan memberi tahu seseorang betapa validnya basis data mereka bagi dunia, dan kemudian menghilangkan kecemasan mereka dengan menjelaskan betapa aktor jahat belum memiliki kuncinya.

Anda dapat menelepon di bagian komentar dan menjelaskan alasan teknis untuk ketakutan yang tidak berdasar ini, tetapi siapa pun yang bekerja di bidang keamanan akan memberi tahu Anda bahwa aspek psikologis juga merupakan bagian dari menciptakan rasa aman pada pelanggan dengan pilihan mereka.

Tarik pedang Excalibur di atas batu.
Rahasia yang disegel mengikuti pendekatan “Excalibur”, di mana siapa pun dapat mengakses rahasia (terenkripsi), tetapi hanya pengguna yang memiliki hak istimewa yang dapat mendekripsinya.

Secara lebih teknis, saya telah berdebat dengan orang-orang bahwa menyegel rahasia di luar ruangan tidak berbeda dengan menggunakan pasangan kunci publik untuk mengenkripsi lalu lintas, tetapi ini adalah pasangan kunci asimetris yang harus Anda gunakan. Tidak pernah Berikan kunci pribadi secara publik, terenkripsi, dll.

Akhirnya, sementara rahasia itu sendiri dienkripsi, metadata di sekitarnya dienkripsi. Aktor jahat dapat mengumpulkan informasi dari komposer untuk membuat eksploitasi rekayasa sosial, menyimpulkan kebijakan rotasi untuk komponen infrastruktur, menentukan apakah rahasia digunakan kembali di seluruh lingkungan, dan banyak petunjuk lain yang dapat berkontribusi pada serangan terhadap lingkungan target.

Penarikan semua garis pertahanan terhadap serangan dunia maya dan menutup semua harapan untuk mempertahankan titik kekalahan adalah titik awal yang buruk untuk sistem yang aman.

Alasan No.3: Kunci untuk mengamankan semua kunci masih kunci.

Siklus hidup rahasia di dalam tangki dapat bervariasi tergantung pada seberapa amannya mereka. Validitas basis data dapat kedaluwarsa setiap 30 hari, sedangkan validitas klaster dapat kedaluwarsa setiap 60 hari.

Bagaimana dengan kunci enkripsi asli untuk rahasia yang disegel itu sendiri? Kebijakan keamanan pada akhirnya memaksa Anda untuk memutar kunci master, yang memerlukan proses terpisah untuk mendistribusikan kunci baru dengan aman di semua lingkungan target.

Tapi tunggu! Kurangnya proses terpisah untuk mendistribusikan kunci di lingkungan target adalah alasan Anda pertama kali menyegel rahasia di repositori Git. Orang mungkin berpendapat bahwa mengelola satu rahasia lebih baik daripada mengelola banyak rahasia, tetapi biaya mengelola satu atau lebih kunci hampir sama, dengan tantangan tambahan untuk mengelola rahasia tertutup Anda sendiri dan masih memerlukan semacam pengelola kata sandi. . Dan bagikan kunci utama.

Alasan No.4: Ada solusi yang lebih baik.

Repositori Git tidak dirancang dengan manajemen kunci. Mereka tidak memiliki dukungan untuk rotasi kunci, tidak ada dukungan untuk memberikan rahasia sebagai referensi simbolis, tidak ada cara untuk menggunakan audit, tidak ada dukungan untuk tingkat akses yang berbeda ke administrator, dan seterusnya.

Solusi manajemen kunci dirancang untuk mengatasi semua persyaratan ini, mengurangi tingkat potensi kebocoran, dan menyediakan jalur mitigasi jika kunci disusupi.

Pengurangan level ini sangat penting, karena jika kunci tidak pernah keluar, Anda tidak dapat secara tidak sengaja mengungkapkan atau kehilangannya. Misalnya, di dunia Kubernetes, cluster selalu berada di halaman layanan yang sama yang berisi beberapa solusi manajemen utama. Adalah umum bagi penyedia IaaS untuk menawarkan integrasi internal antara layanan di mana nilai-nilai kunci tidak pernah harus meninggalkan lingkungan.

Misalnya, Kubernetes, di mana Anda mungkin menggunakan ArgoCD atau Flux untuk tindakan GitOps Anda, saat ini tidak memiliki integrasi asli dengan layanan manajemen utama, tetapi untuk mencapai integrasi ini, mereka mengungkapkan poin pengembangan. Misalnya, dokumen ArgoCD mengatakan: “Argo CD tidak tahu bagaimana mengelola rahasia”Tapi kemudian terus memberikan daftar panjang solusi untuk integrasi dengan layanan khusus.

Robot yang menggantikan nama kunci simbolis dengan nilai sebenarnya dari kotak kunci dan menerapkan sumber daya yang dihasilkan ke pusat data.
Nama rahasia “Tautan terlambat” ke nilai tersembunyi saat penerapan.

Pendekatan yang lebih menjanjikan dimulai dengan proyek Operator Rahasia Asing, yang menyinkronkan rahasia dari berbagai layanan manajemen kunci dengan rahasia lokal di kluster Kubernetes (Saya menghargai rekan saya Carlos Santana untuk referensi itu).

(Diperbarui pada 16/03) Thomas Burger berbicara di bagian komentar tentang alternatif lain untuk rahasia yang disegel: Menggunakan SOPS dengan Flux dan Argo.

Mungkin ada alasan kuat untuk menggunakan rahasia yang disegel. Namun, saya belum melihat salah satu dari rahasia ini cukup baik. Saya jarang melihat perdebatan masuk ke dalam pertimbangan hal lain yang terlibat dalam menangani rahasia-rahasia itu.

Saya tidak ragu tentang keterampilan teknik dari mereka yang ingin meniru layanan manajemen kunci dengan file teks dalam repositori kode, tetapi saya mempertanyakan efektivitas biaya dari pendekatan ini. Populasi DIY harus menggunakan kombinasi penempatan file di git repo, merencanakan siklus rotasi kunci untuk permintaan git pull, dan instrumentasi pipeline penerapan berkelanjutan dengan kunci dekripsi untuk mengurai konten repositori. Dan jika Anda bertanya-tanya bagaimana mengelola penekanan tombol tersebut, Anda mungkin menemukan diri Anda dalam siklus konstan cara kreatif untuk membuat Git berfungsi sebagai layanan manajemen kunci.

Itu selalu dapat diperdebatkan mendukung pendekatan berorientasi pertumbuhan, tetapi itu menempatkan rahasia tertutup sebagai batu loncatan untuk menggunakan layanan manajemen kunci, dan tidak. Mencoba untuk “menumbuhkan” penggunaan rahasia yang disegel berarti mengubah konten GitOps yang dipilih dan operasi pelatihan ulang untuk sepenuhnya mengubah cara penanganan kredensial. Tidak ada perbaikan alami, cukup bayar dua kali untuk hasil yang sama.

Hindari rahasia tertutup, mulai latihan GitOps Anda segera, dan gunakan layanan kunci terkelola.

(Update on 5/23: If you like this topic, I wrote a new story including a couple of other things to avoid.)

Demikian materi mengenai Mengapa Anda harus menghindari rahasia tertutup dalam penerapan GitOps Anda | Oleh Danielson N.

, terimakasih telah berkunjung di website saya, mudah-mudahan informasinya ada manfaatnya ya.

[ad_2]

Source link

Tinggalkan Balasan

Alamat email Anda tidak akan dipublikasikan.