- Cos\u2019\u00e8 GitOps?<\/a><\/li>
- GitOps in Kubernetes: attenzione alla sicurezza<\/a><\/li><\/ol><\/div><\/div><\/p>[vc_row type=”in_container” full_screen_row_position=”middle” column_margin=”default” column_direction=”default” column_direction_tablet=”default” column_direction_phone=”default” scene_position=”center” text_color=”dark” text_align=”left” row_border_radius=”none” row_border_radius_applies=”bg” overflow=”visible” overlay_strength=”0.3″ gradient_direction=”left_to_right” shape_divider_position=”bottom” bg_image_animation=”none”][vc_column column_padding=”no-extra-padding” column_padding_tablet=”inherit” column_padding_phone=”inherit” column_padding_position=”all” column_element_spacing=”default” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” column_border_radius=”none” column_link_target=”_self” column_position=”default” gradient_direction=”left_to_right” overlay_strength=”0.3″ width=”1\/1″ tablet_width_inherit=”default” tablet_text_alignment=”default” phone_text_alignment=”default” animation_type=”default” bg_image_animation=”none” border_type=”simple” column_border_width=”none” column_border_style=”solid”][vc_column_text]In sistemi IT complessi come quelli a microservizi \u00e8 necessario prevedere una strategia DevOps e GitOps<\/strong> che permetta di orchestrare in modo organico non solo il deploy dei singoli applicativi, ma anche tutta l\u2019infrastruttura che li ospita. Kubernetes<\/strong><\/a> \u00e8 la piattaforma che facilita l\u2019implementazione di questo tipo di strategia, ma che allo stesso tempo porta a galla nuovi aspetti di sicurezza<\/strong> che \u00e8 importante affrontare.<\/p>\n
Cos\u2019\u00e8 GitOps?<\/h2>\n
Partiamo nel capire cosa differenzia DevOps da GitOps. Pur presentando alcuni principi comuni, DevOps<\/strong> \u00e8 una metodologia che prevede che i team operativi e di sviluppo collaborino al fine di ottimizzare e rendere sicuro il ciclo di implementazione delle applicazioni. GitOps<\/strong> invece eredita da DevOps gli strumenti e le tecnologie tipicamente applicate allo sviluppo software e li applica alla gestione dell\u2019infrastruttura applicativa<\/strong>.<\/p>\n
A una prima impressione, GitOps potrebbe ricordare l\u2019approccio Infrastructure as Code<\/em> (IaC), che prevede di versionare lo stato desiderato dell\u2019infrastruttura (Configurazioni, Risorse Hardware, Policy di Sicurezza, Regole Network, etc.) e averne quindi chiara l\u2019evoluzione nel tempo. GitOps, essendo per definizione una serie di procedure per la gestione delle configurazioni di applicazioni e infrastrutture<\/strong>, pu\u00f2 essere considerato un\u2019evoluzione dell\u2019IaC, a cui aggiunge alcune importanti caratteristiche:<\/p>\n
- \n
- separare il codice<\/strong> delle applicazioni da quello che descrive configurazioni e infrastruttura;<\/li>\n
- definire il processo approvativo<\/strong> (Code Review\/Pull Request) per tutte le modifiche all\u2019infrastruttura. L\u2019utilizzo di un Git Repository Manager (GitLab, BitBucket, GitHub) consente anche di definire i ruoli e i permessi a seconda del tipo di configurazioni da applicare;<\/li>\n
- adottare degli strumenti che applichino in automatico<\/strong> le modifiche approvate all\u2019infrastruttura. Questa applicazione pu\u00f2 solitamente avvenire direttamente dalle pipeline di Continuous Delivery (modalit\u00e0 push), oppure installando degli agenti all\u2019interno del sistema che monitorino continuamente le modifiche Git e le applichino in autonomia (modalit\u00e0 pull).<\/li>\n<\/ul>\n
GitOps in Kubernetes: attenzione alla sicurezza<\/h2>\n
Proprio grazie alla natura dichiarativa, Kubernetes<\/a> rappresenta la soluzione ideale per implementare la propria strategia GitOps<\/strong>.<\/p>\n
Kubernetes \u00e8 un sistema di orchestrazione di container<\/strong> \u2013 ossia \u2018pacchetti\u2019 autoconsistenti che raccolgono tutte le dipendenze necessarie a un\u2019applicazione per funzionare \u2013 in cui \u00e8 possibile definire regole di sicurezza, configurazioni di rete e policy<\/strong> che regolano il modo in cui i container interagiscono tra loro.
\nPer garantire la massima sicurezza<\/strong> queste configurazioni devono essere gestite, modificate e applicate solo da utenti con i permessi e le competenze adeguate. I flussi DevOps e GitOps devono essere quindi adattati per garantire una governance efficace<\/strong> e far fronte ad alcuni nuovi potenziali rischi<\/strong>: vediamo come.<\/p>\n1. Container Vulnerability Scanning<\/h3>\n
Il Container Vulnerability Scanning aiuta a identificare subito potenziali falle di sicurezza<\/strong> all\u2019interno dei container applicativi, sia nel sistema operativo<\/strong> che costituisce le fondamenta del container, sia nelle dipendenze applicative<\/strong> utilizzate per costruire l\u2019applicazione: l\u2019individuazione delle vulnerabilit\u00e0 pu\u00f2 essere effettuata anche durante la fase di costruzione del container tramite strumenti open source come Trivy<\/strong>.
\nInoltre, \u00e8 fondamentale che anche il container registry<\/strong> che ospita le immagini possa effettuare gli scan di sicurezza per identificare eventuali vulnerabilit\u00e0 emerse in una fase successive alla build<\/em>: per esempio, Harbor<\/a> \u00e8 un container registry open source che supporta l\u2019integrazione con questi strumenti.<\/p>\n2. Kubernetes Policy Manager<\/h3>\n
Un cluster Kubernetes ospita potenzialmente centinaia di microservizi, scritti e configurati da persone diverse. \u00c8 compito degli amministratori assicurarsi che tutte le risorse configurate all\u2019interno di Kubernetes siano conformi alle policy di sicurezza e alle best practice aziendali<\/strong>. Un amministratore, ad esempio, ha bisogno di:<\/p>\n
- \n
- evitare che un container utilizzi pi\u00f9 risorse di quelle previste;<\/li>\n
- evitare che vengano installate immagini da container registry non censiti;<\/li>\n
- evitare la privilege escalation all\u2019interno dei container;<\/li>\n
- evitare la comunicazione tra container, quando non prevista.<\/li>\n<\/ul>\n
Per automatizzare questi controlli ci si pu\u00f2 affidare a dei motori di policy come, ad esempio, Kyverno<\/strong>: le policy che utilizza impediscono che all\u2019interno del cluster vengano istanziati container e risorse che non sono conformi alle regole definite dagli amministratori del sistema.<\/p>\n
Adottare una strategia GitOps<\/strong> permette di avere maggiore controllo sull\u2019evoluzione del proprio ecosistema. Un primo livello di sicurezza \u00e8 dato da un utilizzo corretto del repository manager Git<\/strong>, del suo workflow approvativo e della sua gestione di ruoli e permessi. Un secondo livello di sicurezza pu\u00f2 essere dato dalla scelta di un tool di sync<\/strong> (push o pull) che decide chi e su quali ambienti pu\u00f2 installare applicazioni e configurazioni approvate in una prima fase. Container Vulnerability Scanning e Policy Manager<\/strong> garantiscono che, nonostante l\u2019elevato livello di automazione portato da DevOps e GitOps, non vengano installati applicativi e configurazioni non conformi agli standard di sicurezza e alle policy aziendali.<\/p>\n
Abbiamo parlato di come rendere sicuro tutto il ciclo di sviluppo del software su Kubernetes all\u2019evento Headless & API Date<\/a> del 25 novembre 2021: guarda la registrazione on demand per scoprire di pi\u00f9.<\/p>\n
- definire il processo approvativo<\/strong> (Code Review\/Pull Request) per tutte le modifiche all\u2019infrastruttura. L\u2019utilizzo di un Git Repository Manager (GitLab, BitBucket, GitHub) consente anche di definire i ruoli e i permessi a seconda del tipo di configurazioni da applicare;<\/li>\n
- GitOps in Kubernetes: attenzione alla sicurezza<\/a><\/li><\/ol><\/div><\/div><\/p>[vc_row type=”in_container” full_screen_row_position=”middle” column_margin=”default” column_direction=”default” column_direction_tablet=”default” column_direction_phone=”default” scene_position=”center” text_color=”dark” text_align=”left” row_border_radius=”none” row_border_radius_applies=”bg” overflow=”visible” overlay_strength=”0.3″ gradient_direction=”left_to_right” shape_divider_position=”bottom” bg_image_animation=”none”][vc_column column_padding=”no-extra-padding” column_padding_tablet=”inherit” column_padding_phone=”inherit” column_padding_position=”all” column_element_spacing=”default” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” column_border_radius=”none” column_link_target=”_self” column_position=”default” gradient_direction=”left_to_right” overlay_strength=”0.3″ width=”1\/1″ tablet_width_inherit=”default” tablet_text_alignment=”default” phone_text_alignment=”default” animation_type=”default” bg_image_animation=”none” border_type=”simple” column_border_width=”none” column_border_style=”solid”][vc_column_text]In sistemi IT complessi come quelli a microservizi \u00e8 necessario prevedere una strategia DevOps e GitOps<\/strong> che permetta di orchestrare in modo organico non solo il deploy dei singoli applicativi, ma anche tutta l\u2019infrastruttura che li ospita. Kubernetes<\/strong><\/a> \u00e8 la piattaforma che facilita l\u2019implementazione di questo tipo di strategia, ma che allo stesso tempo porta a galla nuovi aspetti di sicurezza<\/strong> che \u00e8 importante affrontare.<\/p>\n
![\"\"](\"https:\/\/www.intesys.it\/journal\/wp-content\/uploads\/sites\/13\/2021\/10\/HAPI-2021_rec-banner.png\")
<\/a><\/p>\n