Nei prossimi paragrafi vedremo alcuni suggerimenti e trucchi su come evitare le falle di sicurezza pi\u00f9 comuni e come ottimizzare le dimensioni delle nostre immagini Docker.<\/p>\n\n\n\n
Ma prima dobbiamo capire uno dei concetti chiave di Docker: il sistema di layering.<\/p>\n\n\n\n
Il Dockerfile \u00e8 il file principale che definisce il modo in cui un\u2019immagine Docker \u00e8 costruita. In esso viene definita l\u2019immagine di base da cui partire, il modo in cui l\u2019applicativo viene pacchettizzato e come viene eseguito.<\/p>\n\n\n\n
Quando avviamo il processo di build a partire da un Dockerfile, il motore di Docker crea una serie di layer, uno per ciascun comando nel Dockerfile. Ogni volta che eseguiamo un comando all\u2019interno del Dockerfile, un nuovo layer viene creato al di sopra del precedente. Il motore di Docker esegue i comandi in modo sequenziale e infine unisce tutti i layer per creare l\u2019immagine finale.<\/p>\n\n\n\n
Come posso ridurre le dimensioni?<\/h2>\n\n\n\nUsa un\u2019immagine di base piccola. Alpine \u00e8 una buona scelta<\/strong><\/h3>\n\n\n\nGeneralmente, avere un\u2019immagine piccola velocizza la fase di build, deploy ed esecuzione. Per ottenere questo, una buona idea \u00e8 partire da un\u2019immagine di base che \u00e8 essa stessa piccola. Puoi usare `alpine:3.15` che \u00e8 di circa 5.6 MB invece di `ubuntu:20.04` che \u00e8 (al momento di scrittura di questo articolo) di 72 MB.<\/p>\n\n\n\n
Alpine<\/a> \u00e8 una distribuzione Linux costruita con musl libc e BusyBox che punta alla semplicit\u00e0, sicurezza e all\u2019efficienza delle risorse. Essa contiene soltanto i pacchetti assolutamente necessari perch\u00e9\u2026 se una cosa non c\u2019\u00e8, non pu\u00f2 rompersi<\/em>.<\/p>\n\n\n\nBisogna tenere in mente che ha anche alcuni svantaggi. Per esempio, visto che Alpine \u00e8 basata sulla libreria C musl, invece che sulla libreria pi\u00f9 diffusa GNU C Library, ci possono essere problemi con alcune dipendenze in C.<\/p>\n\n\n\n
Usa i Dockerfile multi-stage<\/strong><\/h3>\n\n\n\nOltre a usare Alpine come immagine di base, un altro metodo per ridurre le dimensioni delle immagini Docker \u00e8 l\u2019uso delle build multistage. Una build multistage consiste in un unico Dockerfile in cui definiamo pi\u00f9 istruzioni FROM, ed ognuna di esse \u00e8 uno stage.<\/p>\n\n\n\n
In ogni FROM possiamo partire da uno stage precedente per trarre vantaggio dagli artefatti di build in cache oppure possiamo partire da un\u2019immagine di base totalmente diversa e copiare solamente alcuni artefatti dallo stage precedente.<\/p>\n\n\n\n
Vediamo un veloce esempio:<\/p>\n\n\n\n
# Base image with dependencies\nFROM node:17.3.0-alpine3.12 AS base\nWORKDIR \/app\n# Copy package.json and package-lock.json\nCOPY package*.json .\/\n# Install dependencies\nRUN npm install\n \n \n# Build Stage\nFROM base AS build\nWORKDIR \/app\nCOPY . .\/\n# Build and bundle static files\nRUN npm run build\n \n \n# Release Stage\nFROM node:17.3.0-alpine3.12 AS release\nWORKDIR \/app\nCOPY --from=base \/app\/package.json .\/\n# Install app dependencies\nRUN npm install --only=production\nCOPY --from=build \/app\/dist\/ .\/\nCMD [ \"npm\", \"run\", \"start\" ]<\/code><\/pre>\n\n\n\nIn questo Dockerfile multistage abbiamo creato un\u2019immagine di base che ha tutte le dipendenze della nostra applicazione, abbiamo creato uno stage per fare la build dell\u2019applicazione e infine, per l\u2019immagine di runtime, abbiamo usato un\u2019immagine di base pulita, ci abbiamo installato le dipendenze di produzione e copiato gli artefatti necessari.<\/p>\n\n\n\n
Di default vengono costruiti tutti gli stage ma possiamo specificarne uno in particolare con il flag `–target <stage-name>`<\/p>\n\n\n\n
`docker build –target release –tag image .`<\/p>\n\n\n\n
Puoi fare riferimento alla documentazione<\/a> ufficiale per ulteriori dettagli.<\/p>\n\n\n\nSfrutta il caching<\/strong><\/h3>\n\n\n\nPer trarre pieno vantaggio dal caching dei layer, scrivi il Dockerfile in modo tale che i comandi che non cambiano spesso vengano eseguiti prima degli altri. In questo modo i layer che vengono creati prima saranno tenuti in cache e riutilizzati. Sebbene questo non cambi la dimensione finale dell\u2019immagine, far\u00e0 in modo che le build siano pi\u00f9 veloci.<\/p>\n\n\n\n
Usa .dockerignore <\/strong><\/h3>\n\n\n\nAggiungi i file temporanei, gli artefatti di build intermedi, i file di sviluppo locale e le informazioni sensibili nel .dockerignore per escluderli. La prossima volta che farai partire una build sar\u00e0 pi\u00f9 veloce perch\u00e8 il `build context` di Docker sar\u00e0 pi\u00f9 piccolo.<\/p>\n\n\n\n
Comunque non dovresti avere informazioni sensibili nella tua repository \ud83d\ude42<\/p>\n\n\n\n
Tieni un occhio sui layer \u2013 Dive<\/h2>\n\n\n\n
Dive<\/a> \u00e8 uno strumento a linea di comando che ti permette di ispezionare il contenuto di ciascun layer in un\u2019immagine Docker. Pu\u00f2 essere molto utile vedere cosa \u00e8 cambiato ad ogni step nel Dockerfile, perch\u00e8 in questo modo puoi vedere se ci sono ridondanze o file non necessari nell\u2019immagine.<\/p>\n\n\n\nPer vederlo in azione esegui `dive <image-name>`<\/p>\n\n\n\n
<\/p>\n\n\n\n
![\"Dive](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2022\/01\/unnamed-2022-01-03T161442.444-1024x527.png\")
<\/figure><\/div>\n\n\n\n<\/p>\n\n\n\n
Le feature principali di Dive sono:<\/p>\n\n\n\n
Mostrare il contenuto di ciascun layer: <\/strong>Fornisce una vista ad albero di tutto il contenuto dell\u2019immagine in uno specifico layer.<\/p>\n\n\n\nFiltra per file nuovi, modificati, rimossi:<\/strong> con i comodi shortcut puoi abilitare\/disabilitare la visualizzazione di specifici file.<\/p>\n\n\n\nStimare l\u2019efficienza dell\u2019immagine:<\/strong> Una feature sperimentale che ti mostra quanto spazio viene sprecato.<\/p>\n\n\n\nBonus: automa<\/strong>tizziamo!<\/h2>\n\n\n\nPuoi mettere la variabile di ambiente `CI=true` per disabilitare la visualizzazione interattiva e integrare Dive con una pipeline CI\/CD.<\/p>\n\n\n\n
Puoi creare un file .dive-ci file per personalizzare 3 parametri per l\u2019accettazione dei test:<\/p>\n\n\n\n
`lowestEfficiency`, `highestWastedBytes` e `highestUserWastedPercent`.<\/p>\n\n\n\n
.dive-ci file:<\/p>\n\n\n\n
rules:\n # Lowest allowed efficiency percentage (value range between 0-1).\n lowestEfficiency: 0.95\n \n # If the amount of wasted space is at least X or larger than X, mark as failed.\n # Expressed in B, KB, MB, and GB.\n highestWastedBytes: 20MB\n \n # If the amount of wasted space makes up for X% or more of the image, mark as failed.\n # Note: the base image layer is NOT included in the total image size.\n # Expressed as a ratio between 0-1; fails if the threshold is met or crossed.\n highestUserWastedPercent: 0.10\n \n \n<\/code><\/pre>\n\n\n\n![\"Dive](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2022\/01\/unnamed-2022-01-03T161641.570-1024x630.png\")
<\/figure><\/div>\n\n\n\n<\/p>\n\n\n\n
Regole di base per la sicurezza<\/h2>\n\n\n\n
Una regola del pollice base \u00e8 partire dalla versione stabile pi\u00f9 recente<\/strong> dell\u2019immagine.<\/p>\n\n\n\nIn questo modo, sarai sicuro di avere le ultime patch di sicurezza per gli strumenti e le librerie native. La stessa regola \u00e8 applicabile anche alle dipendenze a livello di applicazione.<\/p>\n\n\n\n
Un’altra regola di base \u00e8 ridurre al minimo la superficie di attacco<\/strong> assicurandoti di avere esclusivamente il set minimo e strettamente necessario di strumenti e librerie per eseguire l\u2019applicazione. Per far ci\u00f2, puoi iniziare da un’immagine di base molto piccola (qualcosa come Alpine) e, quindi, installare le dipendenze applicative su di essa.<\/p>\n\n\n\nUn’altra buona pratica consiste nel sfruttare gli strumenti di scansione delle vulnerabilit\u00e0<\/strong> per verificare la presenza di criticit\u00e0 note nelle immagini Docker. Per farlo AWS mette a disposizione il servizio Elastic Container Registry, il quale consente di scansionare le immagini senza costi aggiuntivi!<\/p>\n\n\n\nAWS ECR Scan<\/h2>\n\n\n\n
Amazon’s Elastic Container Registry (ECR) \u00e8 un registro di container completamente gestito che, tra le numerose feature, offre la possibilit\u00e0 di identificare vulnerabilit\u00e0 attraverso la scansione delle immagini.<\/p>\n\n\n\n
Amazon ECR offre due opzioni di scansione<\/p>\n\n\n\n
Basic scanning<\/strong><\/h3>\n\n\n\nQuesta opzione, completamente gratuita, permette la scansione sia automatica, che manuale delle immagini basandosi sul database Common Vulnerabilities and Exposures (CVEs) del progetto open-source Clair<\/em>.<\/p>\n\n\n\nEnhanced scanning<\/strong><\/h3>\n\n\n\nIntegrandosi con il servizio Amazon Inspector, Amazon ECR \u00e8 in grado di scansionare in modo automatico i repository, in modo che le immagini dei container vengano continuamente analizzate. In caso di nuove vulnerabilit\u00e0 rilevate, Amazon Inspector ci notificher\u00e0 attraverso il servizio Amazon EventBridge.<\/p>\n\n\n\n
\u00c8 anche possibile scansionare manualmente un\u2019immagine direttamente dalla console AWS, oppure eseguendo il seguente comando da CLI:<\/p>\n\n\n\n
aws ecr start-image-scan --repository-name nginx-test --image-id imageTag=base\n{\n\t\"registryId\": \"424242424242\",\n\t\"repositoryName\": \"nginx-test\",\n\t\"imageId\": {\n \t\"imageDigest\": \"sha256:61191087790c31e43eb37caa10de1135b002f10c09fdda7fa8a5989db74033aa\",\n \t\"imageTag\": \"base\"\n\t},\n\t\"imageScanStatus\": {\n \t\"status\": \"IN_PROGRESS\"\n\t}\n}\n\n\nEseguiamo poi il seguente comando per verificare lo stato della scansione:\n\naws ecr describe-image-scan-findings --repository-name nginx-test --image-id imageTag=base\n{\n\t\"imageScanFindings\": {\n \t\"findings\": [...],\n \t\"imageScanCompletedAt\": \"2021-12-22T11:44:55+01:00\",\n \t\"vulnerabilitySourceUpdatedAt\": \"2021-12-22T01:26:43+01:00\",\n \t\"findingSeverityCounts\": {\n \t\"HIGH\": 8,\n \t\"MEDIUM\": 41,\n \t\"LOW\": 23,\n \t\"UNDEFINED\": 1,\n \t\"INFORMATIONAL\": 67\n \t}\n\t},\n\t\"registryId\": \"4242424242424242\",\n\t\"repositoryName\": \"nginx-test\",\n\t\"imageId\": {\n \t\"imageDigest\": \"sha256:61191087790c31e43eb37caa10de1135b002f10c09fdda7fa8a5989db74033aa\",\n \t\"imageTag\": \"base\"\n\t},\n\t\"imageScanStatus\": {\n \t\"status\": \"COMPLETE\",\n \t\"description\": \"The scan was completed successfully.\"\n\t}\n}\n<\/code><\/pre>\n\n\n\nScan on push<\/h2>\n\n\n\n
Puoi configurare una repository per eseguire la scansione delle immagini al momento del push attivando la feature `ScanOnPush`. In alternativa puoi abilitare questa feature su tutti i repository attraverso questo settaggio sulla Console:<\/p>\n\n\n\n
`Amazon ECR > Private registry > Scanning configuration > Basic scanning`<\/p>\n\n\n\n
Abilitando questa funzione si potr\u00e0 beneficiare anche dell\u2019Integrazione con Amazon EventBridge: dato che ogni scansione triggerer\u00e0 un evento, questo potr\u00e0 essere facilmente intercettato utilizzando EventBridge. Saremo cos\u00ec in grado di costruire un sistema di notifica event-driven in grado di avvisarci ogniqualvolta venga rilevata una criticit\u00e0 di sicurezza nelle immagini.<\/p>\n\n\n\n
In conclusione<\/h1>\n\n\n\n
In questo articolo abbiamo analizzato le fasi fondamentali del processo di build in Docker fornendo consigli e best practices per ottimizzare la creazione e il mantenimento delle immagini, con particolare attenzione a performance, costi e sicurezza.<\/p>\n\n\n\n
Per quanto riguarda la dimensione delle immagini e la durata del processo di build, abbiamo svelato alcuni trucchi e suggerimenti relativi ai Dockerfile. <\/p>\n\n\n\n
Abbiamo poi visto come utilizzare Dive per ispezionare i layer e come integrarlo in una pipeline. <\/p>\n\n\n\n
Infine, ci siamo focalizzati sul servizio Amazon ECR per automatizzare la scansione delle nostre immagini.<\/p>\n\n\n\n
Se siete ancora curiosi sull\u2019argomento e volete approfondire ulteriormente uno o pi\u00f9 punti trattati nell\u2019articolo, ecco alcuni link utili:<\/p>\n\n\n\n
Alpine Linux<\/a><\/p>\n\n\n\nAWS ECR<\/a><\/p>\n\n\n\nDocker Multi Stage Build<\/a><\/p>\n\n\n\n
Generalmente, avere un\u2019immagine piccola velocizza la fase di build, deploy ed esecuzione. Per ottenere questo, una buona idea \u00e8 partire da un\u2019immagine di base che \u00e8 essa stessa piccola. Puoi usare `alpine:3.15` che \u00e8 di circa 5.6 MB invece di `ubuntu:20.04` che \u00e8 (al momento di scrittura di questo articolo) di 72 MB.<\/p>\n\n\n\n
Alpine<\/a> \u00e8 una distribuzione Linux costruita con musl libc e BusyBox che punta alla semplicit\u00e0, sicurezza e all\u2019efficienza delle risorse. Essa contiene soltanto i pacchetti assolutamente necessari perch\u00e9\u2026 se una cosa non c\u2019\u00e8, non pu\u00f2 rompersi<\/em>.<\/p>\n\n\n\n Bisogna tenere in mente che ha anche alcuni svantaggi. Per esempio, visto che Alpine \u00e8 basata sulla libreria C musl, invece che sulla libreria pi\u00f9 diffusa GNU C Library, ci possono essere problemi con alcune dipendenze in C.<\/p>\n\n\n\n Oltre a usare Alpine come immagine di base, un altro metodo per ridurre le dimensioni delle immagini Docker \u00e8 l\u2019uso delle build multistage. Una build multistage consiste in un unico Dockerfile in cui definiamo pi\u00f9 istruzioni FROM, ed ognuna di esse \u00e8 uno stage.<\/p>\n\n\n\n In ogni FROM possiamo partire da uno stage precedente per trarre vantaggio dagli artefatti di build in cache oppure possiamo partire da un\u2019immagine di base totalmente diversa e copiare solamente alcuni artefatti dallo stage precedente.<\/p>\n\n\n\n Vediamo un veloce esempio:<\/p>\n\n\n\n In questo Dockerfile multistage abbiamo creato un\u2019immagine di base che ha tutte le dipendenze della nostra applicazione, abbiamo creato uno stage per fare la build dell\u2019applicazione e infine, per l\u2019immagine di runtime, abbiamo usato un\u2019immagine di base pulita, ci abbiamo installato le dipendenze di produzione e copiato gli artefatti necessari.<\/p>\n\n\n\n Di default vengono costruiti tutti gli stage ma possiamo specificarne uno in particolare con il flag `–target <stage-name>`<\/p>\n\n\n\n `docker build –target release –tag image .`<\/p>\n\n\n\n Puoi fare riferimento alla documentazione<\/a> ufficiale per ulteriori dettagli.<\/p>\n\n\n\n Per trarre pieno vantaggio dal caching dei layer, scrivi il Dockerfile in modo tale che i comandi che non cambiano spesso vengano eseguiti prima degli altri. In questo modo i layer che vengono creati prima saranno tenuti in cache e riutilizzati. Sebbene questo non cambi la dimensione finale dell\u2019immagine, far\u00e0 in modo che le build siano pi\u00f9 veloci.<\/p>\n\n\n\n Aggiungi i file temporanei, gli artefatti di build intermedi, i file di sviluppo locale e le informazioni sensibili nel .dockerignore per escluderli. La prossima volta che farai partire una build sar\u00e0 pi\u00f9 veloce perch\u00e8 il `build context` di Docker sar\u00e0 pi\u00f9 piccolo.<\/p>\n\n\n\n Comunque non dovresti avere informazioni sensibili nella tua repository \ud83d\ude42<\/p>\n\n\n\n Dive<\/a> \u00e8 uno strumento a linea di comando che ti permette di ispezionare il contenuto di ciascun layer in un\u2019immagine Docker. Pu\u00f2 essere molto utile vedere cosa \u00e8 cambiato ad ogni step nel Dockerfile, perch\u00e8 in questo modo puoi vedere se ci sono ridondanze o file non necessari nell\u2019immagine.<\/p>\n\n\n\n Per vederlo in azione esegui `dive <image-name>`<\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n Le feature principali di Dive sono:<\/p>\n\n\n\n Mostrare il contenuto di ciascun layer: <\/strong>Fornisce una vista ad albero di tutto il contenuto dell\u2019immagine in uno specifico layer.<\/p>\n\n\n\n Filtra per file nuovi, modificati, rimossi:<\/strong> con i comodi shortcut puoi abilitare\/disabilitare la visualizzazione di specifici file.<\/p>\n\n\n\n Stimare l\u2019efficienza dell\u2019immagine:<\/strong> Una feature sperimentale che ti mostra quanto spazio viene sprecato.<\/p>\n\n\n\n Puoi mettere la variabile di ambiente `CI=true` per disabilitare la visualizzazione interattiva e integrare Dive con una pipeline CI\/CD.<\/p>\n\n\n\n Puoi creare un file .dive-ci file per personalizzare 3 parametri per l\u2019accettazione dei test:<\/p>\n\n\n\n `lowestEfficiency`, `highestWastedBytes` e `highestUserWastedPercent`.<\/p>\n\n\n\n .dive-ci file:<\/p>\n\n\n\n <\/p>\n\n\n\n In questo modo, sarai sicuro di avere le ultime patch di sicurezza per gli strumenti e le librerie native. La stessa regola \u00e8 applicabile anche alle dipendenze a livello di applicazione.<\/p>\n\n\n\n Un’altra regola di base \u00e8 ridurre al minimo la superficie di attacco<\/strong> assicurandoti di avere esclusivamente il set minimo e strettamente necessario di strumenti e librerie per eseguire l\u2019applicazione. Per far ci\u00f2, puoi iniziare da un’immagine di base molto piccola (qualcosa come Alpine) e, quindi, installare le dipendenze applicative su di essa.<\/p>\n\n\n\n Un’altra buona pratica consiste nel sfruttare gli strumenti di scansione delle vulnerabilit\u00e0<\/strong> per verificare la presenza di criticit\u00e0 note nelle immagini Docker. Per farlo AWS mette a disposizione il servizio Elastic Container Registry, il quale consente di scansionare le immagini senza costi aggiuntivi!<\/p>\n\n\n\n Amazon’s Elastic Container Registry (ECR) \u00e8 un registro di container completamente gestito che, tra le numerose feature, offre la possibilit\u00e0 di identificare vulnerabilit\u00e0 attraverso la scansione delle immagini.<\/p>\n\n\n\n Amazon ECR offre due opzioni di scansione<\/p>\n\n\n\n Questa opzione, completamente gratuita, permette la scansione sia automatica, che manuale delle immagini basandosi sul database Common Vulnerabilities and Exposures (CVEs) del progetto open-source Clair<\/em>.<\/p>\n\n\n\n Integrandosi con il servizio Amazon Inspector, Amazon ECR \u00e8 in grado di scansionare in modo automatico i repository, in modo che le immagini dei container vengano continuamente analizzate. In caso di nuove vulnerabilit\u00e0 rilevate, Amazon Inspector ci notificher\u00e0 attraverso il servizio Amazon EventBridge.<\/p>\n\n\n\n \u00c8 anche possibile scansionare manualmente un\u2019immagine direttamente dalla console AWS, oppure eseguendo il seguente comando da CLI:<\/p>\n\n\n\n Puoi configurare una repository per eseguire la scansione delle immagini al momento del push attivando la feature `ScanOnPush`. In alternativa puoi abilitare questa feature su tutti i repository attraverso questo settaggio sulla Console:<\/p>\n\n\n\n `Amazon ECR > Private registry > Scanning configuration > Basic scanning`<\/p>\n\n\n\n Abilitando questa funzione si potr\u00e0 beneficiare anche dell\u2019Integrazione con Amazon EventBridge: dato che ogni scansione triggerer\u00e0 un evento, questo potr\u00e0 essere facilmente intercettato utilizzando EventBridge. Saremo cos\u00ec in grado di costruire un sistema di notifica event-driven in grado di avvisarci ogniqualvolta venga rilevata una criticit\u00e0 di sicurezza nelle immagini.<\/p>\n\n\n\n In questo articolo abbiamo analizzato le fasi fondamentali del processo di build in Docker fornendo consigli e best practices per ottimizzare la creazione e il mantenimento delle immagini, con particolare attenzione a performance, costi e sicurezza.<\/p>\n\n\n\n Per quanto riguarda la dimensione delle immagini e la durata del processo di build, abbiamo svelato alcuni trucchi e suggerimenti relativi ai Dockerfile. <\/p>\n\n\n\n Abbiamo poi visto come utilizzare Dive per ispezionare i layer e come integrarlo in una pipeline. <\/p>\n\n\n\n Infine, ci siamo focalizzati sul servizio Amazon ECR per automatizzare la scansione delle nostre immagini.<\/p>\n\n\n\n Se siete ancora curiosi sull\u2019argomento e volete approfondire ulteriormente uno o pi\u00f9 punti trattati nell\u2019articolo, ecco alcuni link utili:<\/p>\n\n\n\n Alpine Linux<\/a><\/p>\n\n\n\n AWS ECR<\/a><\/p>\n\n\n\n Docker Multi Stage Build<\/a><\/p>\n\n\n\nUsa i Dockerfile multi-stage<\/strong><\/h3>\n\n\n\n
# Base image with dependencies\nFROM node:17.3.0-alpine3.12 AS base\nWORKDIR \/app\n# Copy package.json and package-lock.json\nCOPY package*.json .\/\n# Install dependencies\nRUN npm install\n \n \n# Build Stage\nFROM base AS build\nWORKDIR \/app\nCOPY . .\/\n# Build and bundle static files\nRUN npm run build\n \n \n# Release Stage\nFROM node:17.3.0-alpine3.12 AS release\nWORKDIR \/app\nCOPY --from=base \/app\/package.json .\/\n# Install app dependencies\nRUN npm install --only=production\nCOPY --from=build \/app\/dist\/ .\/\nCMD [ \"npm\", \"run\", \"start\" ]<\/code><\/pre>\n\n\n\nSfrutta il caching<\/strong><\/h3>\n\n\n\n
Usa .dockerignore <\/strong><\/h3>\n\n\n\n
Tieni un occhio sui layer \u2013 Dive<\/h2>\n\n\n\n
<\/figure><\/div>\n\n\n\nBonus: automa<\/strong>tizziamo!<\/h2>\n\n\n\n
rules:\n # Lowest allowed efficiency percentage (value range between 0-1).\n lowestEfficiency: 0.95\n \n # If the amount of wasted space is at least X or larger than X, mark as failed.\n # Expressed in B, KB, MB, and GB.\n highestWastedBytes: 20MB\n \n # If the amount of wasted space makes up for X% or more of the image, mark as failed.\n # Note: the base image layer is NOT included in the total image size.\n # Expressed as a ratio between 0-1; fails if the threshold is met or crossed.\n highestUserWastedPercent: 0.10\n \n \n<\/code><\/pre>\n\n\n\n<\/figure><\/div>\n\n\n\nRegole di base per la sicurezza<\/h2>\n\n\n\n
Una regola del pollice base \u00e8 partire dalla versione stabile pi\u00f9 recente<\/strong> dell\u2019immagine.<\/p>\n\n\n\nAWS ECR Scan<\/h2>\n\n\n\n
Basic scanning<\/strong><\/h3>\n\n\n\n
Enhanced scanning<\/strong><\/h3>\n\n\n\n
aws ecr start-image-scan --repository-name nginx-test --image-id imageTag=base\n{\n\t\"registryId\": \"424242424242\",\n\t\"repositoryName\": \"nginx-test\",\n\t\"imageId\": {\n \t\"imageDigest\": \"sha256:61191087790c31e43eb37caa10de1135b002f10c09fdda7fa8a5989db74033aa\",\n \t\"imageTag\": \"base\"\n\t},\n\t\"imageScanStatus\": {\n \t\"status\": \"IN_PROGRESS\"\n\t}\n}\n\n\nEseguiamo poi il seguente comando per verificare lo stato della scansione:\n\naws ecr describe-image-scan-findings --repository-name nginx-test --image-id imageTag=base\n{\n\t\"imageScanFindings\": {\n \t\"findings\": [...],\n \t\"imageScanCompletedAt\": \"2021-12-22T11:44:55+01:00\",\n \t\"vulnerabilitySourceUpdatedAt\": \"2021-12-22T01:26:43+01:00\",\n \t\"findingSeverityCounts\": {\n \t\"HIGH\": 8,\n \t\"MEDIUM\": 41,\n \t\"LOW\": 23,\n \t\"UNDEFINED\": 1,\n \t\"INFORMATIONAL\": 67\n \t}\n\t},\n\t\"registryId\": \"4242424242424242\",\n\t\"repositoryName\": \"nginx-test\",\n\t\"imageId\": {\n \t\"imageDigest\": \"sha256:61191087790c31e43eb37caa10de1135b002f10c09fdda7fa8a5989db74033aa\",\n \t\"imageTag\": \"base\"\n\t},\n\t\"imageScanStatus\": {\n \t\"status\": \"COMPLETE\",\n \t\"description\": \"The scan was completed successfully.\"\n\t}\n}\n<\/code><\/pre>\n\n\n\nScan on push<\/h2>\n\n\n\n
In conclusione<\/h1>\n\n\n\n