Menetelmiä ja esimerkkejä apuohjelmien toteuttamisesta Dockerin suojauksen tarkistamiseen

Menetelmiä ja esimerkkejä apuohjelmien toteuttamisesta Dockerin suojauksen tarkistamiseen
Hei Habr!

Nykytodellisuudessa konttien kasvavan roolin vuoksi kehitysprosesseissa kontteihin liittyvien eri vaiheiden ja kokonaisuuksien turvallisuuden varmistaminen ei ole vähiten tärkeä kysymys. Manuaalisten tarkastusten tekeminen on aikaa vievää, joten olisi hyvä idea ottaa ainakin ensimmäiset askeleet tämän prosessin automatisoimiseksi.

Tässä artikkelissa jaan valmiita komentosarjoja useiden Docker-tietoturvaapuohjelmien toteuttamiseen ja ohjeet kuinka ottaa käyttöön pieni esittelyteline tämän prosessin testaamiseksi. Materiaalien avulla voit kokeilla, miten Dockerfile-kuvien ja -ohjeiden turvallisuuden testausprosessi järjestetään. On selvää, että jokaisen kehitys- ja toteutusinfrastruktuuri on erilainen, joten annan alla useita mahdollisia vaihtoehtoja.

Turvatarkastuksen apuohjelmat

On olemassa suuri määrä erilaisia ​​apusovelluksia ja komentosarjoja, jotka tarkistavat Docker-infrastruktuurin eri näkökohtia. Jotkut niistä on jo kuvattu edellisessä artikkelissa (https://habr.com/ru/company/swordfish_security/blog/518758/#docker-security), ja tässä materiaalissa haluan keskittyä kolmeen niistä, jotka kattavat suurimman osan kehitysprosessin aikana rakennettujen Docker-kuvien turvallisuusvaatimuksista. Lisäksi näytän myös esimerkin siitä, kuinka nämä kolme apuohjelmaa voidaan yhdistää yhdeksi putkeksi turvatarkastuksia varten.

Hadolint
https://github.com/hadolint/hadolint

Melko yksinkertainen konsoliapuohjelma, joka auttaa ensimmäisenä likiarvona arvioimaan Dockerfile-ohjeiden oikeellisuutta ja turvallisuutta (esim. käyttämällä vain valtuutettuja kuvarekistereitä tai käyttämällä sudoa).

Menetelmiä ja esimerkkejä apuohjelmien toteuttamisesta Dockerin suojauksen tarkistamiseen

Dockle
https://github.com/goodwithtech/dockle

Konsoliapuohjelma, joka toimii kuvan kanssa (tai kuvan tallennetun tar-arkiston kanssa), joka tarkistaa tietyn kuvan oikeellisuuden ja turvallisuuden sellaisenaan analysoiden sen tasoja ja konfiguraatiota - mitä käyttäjiä luodaan, mitä ohjeita käytetään, mitkä volyymit on asennettu, tyhjän salasanan olemassaolo jne. d. Toistaiseksi tarkistusten määrä ei ole kovin suuri ja perustuu useisiin omiin tarkistuksiin ja suosituksiin CIS (Center for Internet Security) -vertailu Dockerille.
Menetelmiä ja esimerkkejä apuohjelmien toteuttamisesta Dockerin suojauksen tarkistamiseen

Trivy
https://github.com/aquasecurity/trivy

Tämän apuohjelman tarkoituksena on löytää kahdenlaisia ​​haavoittuvuuksia - ongelmia käyttöjärjestelmän koontiversioissa (tuet Alpine, RedHat (EL), CentOS, Debian GNU, Ubuntu) ja ongelmia riippuvuuksissa (Gemfile.lock, Pipfile.lock, composer.lock, paketti). -lock.json , yarn.lock, cargo.lock). Trivy voi skannata sekä arkistossa olevan kuvan että paikallisen kuvan ja voi myös skannata siirretyn .tar-tiedoston perusteella Docker-kuvan kanssa.

Menetelmiä ja esimerkkejä apuohjelmien toteuttamisesta Dockerin suojauksen tarkistamiseen

Vaihtoehdot apuohjelmien toteuttamiseen

Jotta voisin kokeilla kuvattuja sovelluksia eristetyssä ympäristössä, annan ohjeet kaikkien apuohjelmien asentamiseen hieman yksinkertaistetussa prosessissa.

Pääideana on esitellä, kuinka voit toteuttaa automaattisen sisällöntarkistuksen Docker-tiedostoille ja Docker-kuville, jotka luodaan kehityksen aikana.

Itse tarkistus koostuu seuraavista vaiheista:

  1. Dockerfile-ohjeiden oikeellisuuden ja turvallisuuden tarkistaminen linteriapuohjelmalla Hadolint
  2. Lopullisten ja välikuvien oikeellisuuden ja turvallisuuden tarkistaminen apuohjelmalla Dockle
  3. Tarkista, onko peruskuvassa julkisesti tunnettuja haavoittuvuuksia (CVE) ja useita riippuvuuksia - apuohjelman avulla Trivy

Myöhemmin artikkelissa annan kolme vaihtoehtoa näiden vaiheiden toteuttamiseksi:
Ensimmäinen on konfiguroimalla CI/CD-liukuhihna käyttämällä esimerkkinä GitLabia (ja kuvauksen testiesiintymän nostamisprosessista).
Toinen käyttää shell-skriptiä.
Kolmas sisältää Docker-kuvan rakentamisen Docker-kuvien skannaamiseksi.
Voit valita itsellesi parhaiten sopivan vaihtoehdon, siirtää sen infrastruktuuriisi ja mukauttaa tarpeisiisi.

Kaikki tarvittavat tiedostot ja lisäohjeet sijaitsevat myös arkistossa: https://github.com/Swordfish-Security/docker_cicd

Integrointi GitLab CI/CD:hen

Ensimmäisessä vaihtoehdossa tarkastellaan, kuinka voit toteuttaa turvatarkastuksia käyttämällä esimerkkinä GitLab-arkistojärjestelmää. Täällä käymme läpi vaiheet ja selvitämme kuinka asentaa testiympäristö GitLabin avulla tyhjästä, luoda skannausprosessi ja käynnistää apuohjelmat testi-Dockerfilen ja satunnaisen kuvan tarkistamiseksi - JuiceShop-sovelluksen.

GitLabin asennus
1. Asenna Docker:

sudo apt-get update && sudo apt-get install docker.io

2. Lisää nykyinen käyttäjä Docker-ryhmään, jotta voit työskennellä Dockerin kanssa ilman sudoa:

sudo addgroup <username> docker

3. Etsi IP:si:

ip addr

4. Asenna ja käynnistä GitLab säilössä korvaamalla isäntänimessä oleva IP-osoite omallasi:

docker run --detach 
--hostname 192.168.1.112 
--publish 443:443 --publish 80:80 
--name gitlab 
--restart always 
--volume /srv/gitlab/config:/etc/gitlab 
--volume /srv/gitlab/logs:/var/log/gitlab 
--volume /srv/gitlab/data:/var/opt/gitlab 
gitlab/gitlab-ce:latest

Odotamme, kunnes GitLab suorittaa kaikki tarvittavat asennustoimenpiteet (voit seurata prosessia lokitiedoston lähdön kautta: docker logs -f gitlab).

5. Avaa paikallinen IP-osoitteesi selaimessa ja näet sivun, joka pyytää sinua vaihtamaan pääkäyttäjän salasanan:
Menetelmiä ja esimerkkejä apuohjelmien toteuttamisesta Dockerin suojauksen tarkistamiseen
Aseta uusi salasana ja siirry GitLabiin.

6. Luo uusi projekti, esimerkiksi cicd-test ja alusta se aloitustiedostolla README.md:
Menetelmiä ja esimerkkejä apuohjelmien toteuttamisesta Dockerin suojauksen tarkistamiseen
7. Nyt meidän on asennettava GitLab Runner: agentti, joka suorittaa kaikki tarvittavat toiminnot pyynnöstä.
Lataa uusin versio (tässä tapauksessa 64-bittiselle Linuxille):

sudo curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64

8. Tee siitä suoritettava:

sudo chmod +x /usr/local/bin/gitlab-runner

9. Lisää käyttöjärjestelmäkäyttäjä Runnerille ja käynnistä palvelu:

sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
sudo gitlab-runner start

Sen pitäisi näyttää suunnilleen tältä:

local@osboxes:~$ sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
Runtime platform arch=amd64 os=linux pid=8438 revision=0e5417a3 version=12.0.1
local@osboxes:~$ sudo gitlab-runner start
Runtime platform arch=amd64 os=linux pid=8518 revision=0e5417a3 version=12.0.1

10. Nyt rekisteröimme Runnerin, jotta se voi olla vuorovaikutuksessa GitLab-instanssimme kanssa.
Voit tehdä tämän avaamalla Settings-CI/CD-sivun (http://OUR_IP_ADDRESS/root/cicd-test/-/settings/ci_cd) ja etsimällä Runners-välilehdeltä URL-osoitteen ja rekisteröintitunnisteen:
Menetelmiä ja esimerkkejä apuohjelmien toteuttamisesta Dockerin suojauksen tarkistamiseen
11. Rekisteröi juoksija korvaamalla URL-osoite ja rekisteröintitunnus:

sudo gitlab-runner register 
--non-interactive 
--url "http://<URL>/" 
--registration-token "<Registration Token>" 
--executor "docker" 
--docker-privileged 
--docker-image alpine:latest 
--description "docker-runner" 
--tag-list "docker,privileged" 
--run-untagged="true" 
--locked="false" 
--access-level="not_protected"

Tuloksena saamme valmiin toimivan GitLabin, johon meidän on lisättävä ohjeet apuohjelmien käynnistämiseksi. Tässä esittelyssä meillä ei ole vaiheita sovelluksen rakentamiseen ja sen säilyttämiseen, mutta todellisessa ympäristössä ne edeltävät skannausvaiheita ja luovat kuvia ja Docker-tiedoston analysointia varten.

putkilinjan kokoonpano

1. Lisää tiedostoja arkistoon mydockerfile.df (tämä on Docker-testitiedosto, jonka tarkistamme) ja GitLab CI/CD -prosessin määritystiedosto .gitlab-cicd.yml, jossa luetellaan ohjeet skannereita varten (huomaa piste tiedoston nimessä).

YAML-määritystiedosto sisältää ohjeet kolmen apuohjelman (Hadolint, Dockle ja Trivy) suorittamiseen, jotka analysoivat valitun Docker-tiedoston ja DOCKERFILE-muuttujassa määritetyn kuvan. Kaikki tarvittavat tiedostot voidaan ottaa arkistosta: https://github.com/Swordfish-Security/docker_cicd/

Ote kohteesta mydockerfile.df (tämä on abstrakti tiedosto, jossa on joukko mielivaltaisia ​​ohjeita vain apuohjelman toiminnan havainnollistamiseksi). Suora linkki tiedostoon: mydockerfile.df

Tiedoston mydockerfile.df sisältö

FROM amd64/node:10.16.0-alpine@sha256:f59303fb3248e5d992586c76cc83e1d3700f641cbcd7c0067bc7ad5bb2e5b489 AS tsbuild
COPY package.json .
COPY yarn.lock .
RUN yarn install
COPY lib lib
COPY tsconfig.json tsconfig.json
COPY tsconfig.app.json tsconfig.app.json
RUN yarn build
FROM amd64/ubuntu:18.04@sha256:eb70667a801686f914408558660da753cde27192cd036148e58258819b927395
LABEL maintainer="Rhys Arkins <[email protected]>"
LABEL name="renovate"
...
COPY php.ini /usr/local/etc/php/php.ini
RUN cp -a /tmp/piik/* /var/www/html/
RUN rm -rf /tmp/piwik
RUN chown -R www-data /var/www/html
ADD piwik-cli-setup /piwik-cli-setup
ADD reset.php /var/www/html/
## ENTRYPOINT ##
ADD entrypoint.sh /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]
USER root

YAML-kokoonpano näyttää tältä (itse tiedosto löytyy suoran linkin kautta täältä: .gitlab-ci.yml):

Tiedoston .gitlab-ci.yml sisältö

variables:
    DOCKER_HOST: "tcp://docker:2375/"
    DOCKERFILE: "mydockerfile.df" # name of the Dockerfile to analyse   
    DOCKERIMAGE: "bkimminich/juice-shop" # name of the Docker image to analyse
    # DOCKERIMAGE: "knqyf263/cve-2018-11235" # test Docker image with several CRITICAL CVE
    SHOWSTOPPER_PRIORITY: "CRITICAL" # what level of criticality will fail Trivy job
    TRIVYCACHE: "$CI_PROJECT_DIR/.cache" # where to cache Trivy database of vulnerabilities for faster reuse
    ARTIFACT_FOLDER: "$CI_PROJECT_DIR"
 
services:
    - docker:dind # to be able to build docker images inside the Runner
 
stages:
    - scan
    - report
    - publish
 
HadoLint:
    # Basic lint analysis of Dockerfile instructions
    stage: scan
    image: docker:git
 
    after_script:
    - cat $ARTIFACT_FOLDER/hadolint_results.json
 
    script:
    - export VERSION=$(wget -q -O - https://api.github.com/repos/hadolint/hadolint/releases/latest | grep '"tag_name":' | sed -E 's/.*"v([^"]+)".*/1/')
    - wget https://github.com/hadolint/hadolint/releases/download/v${VERSION}/hadolint-Linux-x86_64 && chmod +x hadolint-Linux-x86_64
     
    # NB: hadolint will always exit with 0 exit code
    - ./hadolint-Linux-x86_64 -f json $DOCKERFILE > $ARTIFACT_FOLDER/hadolint_results.json || exit 0
 
    artifacts:
        when: always # return artifacts even after job failure       
        paths:
        - $ARTIFACT_FOLDER/hadolint_results.json
 
Dockle:
    # Analysing best practices about docker image (users permissions, instructions followed when image was built, etc.)
    stage: scan   
    image: docker:git
 
    after_script:
    - cat $ARTIFACT_FOLDER/dockle_results.json
 
    script:
    - export VERSION=$(wget -q -O - https://api.github.com/repos/goodwithtech/dockle/releases/latest | grep '"tag_name":' | sed -E 's/.*"v([^"]+)".*/1/')
    - wget https://github.com/goodwithtech/dockle/releases/download/v${VERSION}/dockle_${VERSION}_Linux-64bit.tar.gz && tar zxf dockle_${VERSION}_Linux-64bit.tar.gz
    - ./dockle --exit-code 1 -f json --output $ARTIFACT_FOLDER/dockle_results.json $DOCKERIMAGE   
     
    artifacts:
        when: always # return artifacts even after job failure       
        paths:
        - $ARTIFACT_FOLDER/dockle_results.json
 
Trivy:
    # Analysing docker image and package dependencies against several CVE bases
    stage: scan   
    image: docker:git
 
    script:
    # getting the latest Trivy
    - apk add rpm
    - export VERSION=$(wget -q -O - https://api.github.com/repos/knqyf263/trivy/releases/latest | grep '"tag_name":' | sed -E 's/.*"v([^"]+)".*/1/')
    - wget https://github.com/knqyf263/trivy/releases/download/v${VERSION}/trivy_${VERSION}_Linux-64bit.tar.gz && tar zxf trivy_${VERSION}_Linux-64bit.tar.gz
     
    # displaying all vulnerabilities w/o failing the build
    - ./trivy -d --cache-dir $TRIVYCACHE -f json -o $ARTIFACT_FOLDER/trivy_results.json --exit-code 0 $DOCKERIMAGE    
    
    # write vulnerabilities info to stdout in human readable format (reading pure json is not fun, eh?). You can remove this if you don't need this.
    - ./trivy -d --cache-dir $TRIVYCACHE --exit-code 0 $DOCKERIMAGE    
 
    # failing the build if the SHOWSTOPPER priority is found
    - ./trivy -d --cache-dir $TRIVYCACHE --exit-code 1 --severity $SHOWSTOPPER_PRIORITY --quiet $DOCKERIMAGE
         
    artifacts:
        when: always # return artifacts even after job failure
        paths:
        - $ARTIFACT_FOLDER/trivy_results.json
 
    cache:
        paths:
        - .cache
 
Report:
    # combining tools outputs into one HTML
    stage: report
    when: always
    image: python:3.5
     
    script:
    - mkdir json
    - cp $ARTIFACT_FOLDER/*.json ./json/
    - pip install json2html
    - wget https://raw.githubusercontent.com/shad0wrunner/docker_cicd/master/convert_json_results.py
    - python ./convert_json_results.py
     
    artifacts:
        paths:
        - results.html

Tarvittaessa voit myös skannata tallennettuja kuvia .tar-arkiston muodossa (sinun on kuitenkin muutettava YAML-tiedoston apuohjelmien syöttöparametreja)

HUOM: Trivy vaatii asennuksen rpm и mennä. Muuten se tuottaa virheitä skannattaessa RedHat-pohjaisia ​​kuvia ja vastaanotettaessa päivityksiä haavoittuvuustietokantaan.

2. Kun tiedostot on lisätty arkistoon, GitLab aloittaa automaattisesti rakennus- ja tarkistusprosessin määritystiedostomme ohjeiden mukaisesti. CI/CD → Pipelines-välilehdellä näet ohjeiden etenemisen.

Tämän seurauksena meillä on neljä tehtävää. Kolme niistä käsittelee suoraan skannausta, ja viimeinen (Raportti) kerää hajallaan olevista tiedostoista yksinkertaisen raportin tarkistustuloksineen.
Menetelmiä ja esimerkkejä apuohjelmien toteuttamisesta Dockerin suojauksen tarkistamiseen
Oletusarvoisesti Trivy lopettaa toiminnan, jos kuvassa tai riippuvuuksissa havaitaan KRIITTINEN haavoittuvuus. Samanaikaisesti Hadolint palauttaa aina onnistumiskoodin, koska se johtaa aina kommentteihin, mikä saa koontiversion pysähtymään.

Erityisvaatimuksistasi riippuen voit määrittää poistumiskoodin niin, että kun nämä apuohjelmat havaitsevat tietyn kriittiset ongelmat, ne myös pysäyttävät rakennusprosessin. Meidän tapauksessamme rakentaminen pysähtyy vain, jos Trivy havaitsee haavoittuvuuden, jonka kriittisyyttä määritimme SHOWSTOPPER-muuttujassa .gitlab-ci.yml.
Menetelmiä ja esimerkkejä apuohjelmien toteuttamisesta Dockerin suojauksen tarkistamiseen

Kunkin apuohjelman tulosta voi tarkastella kunkin skannaustehtävän lokissa, suoraan artefaktiosiossa olevissa json-tiedostoissa tai yksinkertaisessa HTML-raportissa (lisätietoja alla):
Menetelmiä ja esimerkkejä apuohjelmien toteuttamisesta Dockerin suojauksen tarkistamiseen

3. Jotta apuohjelmaraportit esitetään hieman luettavammassa muodossa, pienellä Python-skriptillä muunnetaan kolme JSON-tiedostoa yhdeksi HTML-tiedostoksi, jossa on virhetaulukko.
Tämä komentosarja käynnistyy erillisellä Raportti-tehtävällä, ja sen lopullinen artefakti on HTML-tiedosto, jossa on raportti. Skriptilähde on myös arkistossa ja sitä voidaan muokata tarpeidesi, värien jne. mukaan.
Menetelmiä ja esimerkkejä apuohjelmien toteuttamisesta Dockerin suojauksen tarkistamiseen

Shell-käsikirjoitus

Toinen vaihtoehto sopii tilanteisiin, joissa sinun on tarkistettava Docker-kuvat CI/CD-järjestelmän ulkopuolelta tai sinulla on oltava kaikki ohjeet muodossa, joka voidaan suorittaa suoraan isännässä. Tämä vaihtoehto on peitetty valmiilla shell-skriptillä, joka voidaan suorittaa puhtaalla virtuaalisella (tai jopa todellisella) koneella. Skripti suorittaa samat ohjeet kuin yllä kuvattu gitlab-runner.

Jotta komentosarja toimisi onnistuneesti, Docker on asennettava järjestelmään ja nykyisen käyttäjän on oltava telakointiryhmässä.

Itse käsikirjoitus löytyy täältä: docker_sec_check.sh

Tiedoston alussa muuttujat määrittävät, mikä kuva on tarkistettava ja mitkä kriittisyyden viat saavat Trivy-apuohjelman poistumaan määritetyllä virhekoodilla.

Komentosarjan suorittamisen aikana kaikki apuohjelmat ladataan hakemistoon docker_tools, heidän työnsä tulokset ovat hakemistossa docker_tools/json, ja raportin HTML-koodi on tiedostossa tulokset.html.

Esimerkki skriptitulosta

~/docker_cicd$ ./docker_sec_check.sh

[+] Setting environment variables
[+] Installing required packages
[+] Preparing necessary directories
[+] Fetching sample Dockerfile
2020-10-20 10:40:00 (45.3 MB/s) - ‘Dockerfile’ saved [8071/8071]
[+] Pulling image to scan
latest: Pulling from bkimminich/juice-shop
[+] Running Hadolint
...
Dockerfile:205 DL3015 Avoid additional packages by specifying `--no-install-recommends`
Dockerfile:248 DL3002 Last USER should not be root
...
[+] Running Dockle
...
WARN    - DKL-DI-0006: Avoid latest tag
        * Avoid 'latest' tag
INFO    - CIS-DI-0005: Enable Content trust for Docker
        * export DOCKER_CONTENT_TRUST=1 before docker pull/build
...
[+] Running Trivy
juice-shop/frontend/package-lock.json
=====================================
Total: 3 (UNKNOWN: 0, LOW: 1, MEDIUM: 0, HIGH: 2, CRITICAL: 0)

+---------------------+------------------+----------+---------+-------------------------+
|       LIBRARY       | VULNERABILITY ID | SEVERITY | VERSION |             TITLE       |
+---------------------+------------------+----------+---------+-------------------------+
| object-path         | CVE-2020-15256   | HIGH     | 0.11.4  | Prototype pollution in  |
|                     |                  |          |         | object-path             |
+---------------------+------------------+          +---------+-------------------------+
| tree-kill           | CVE-2019-15599   |          | 1.2.2   | Code Injection          |
+---------------------+------------------+----------+---------+-------------------------+
| webpack-subresource | CVE-2020-15262   | LOW      | 1.4.1   | Unprotected dynamically |
|                     |                  |          |         | loaded chunks           |
+---------------------+------------------+----------+---------+-------------------------+

juice-shop/package-lock.json
============================
Total: 20 (UNKNOWN: 0, LOW: 1, MEDIUM: 6, HIGH: 8, CRITICAL: 5)

...

juice-shop/package-lock.json
============================
Total: 5 (CRITICAL: 5)

...
[+] Removing left-overs
[+] Making the output look pretty
[+] Converting JSON results
[+] Writing results HTML
[+] Clean exit ============================================================
[+] Everything is done. Find the resulting HTML report in results.html

Docker-kuva kaikilla apuohjelmilla

Kolmantena vaihtoehtona kokosin kaksi yksinkertaista Docker-tiedostoa luodakseni kuvan suojausapuohjelmilla. Yksi Dockerfile auttaa rakentamaan sarjan kuvan skannaamiseksi arkistosta, toinen (Dockerfile_tar) auttaa rakentamaan joukon tar-tiedoston skannaamiseen kuvan kanssa.

1. Ota vastaava Docker-tiedosto ja komentosarjat arkistosta https://github.com/Swordfish-Security/docker_cicd/tree/master/Dockerfile.
2. Käynnistämme sen kokoonpanoa varten:

docker build -t dscan:image -f docker_security.df .

3. Kun kokoonpano on valmis, luomme kuvasta säiliön. Samanaikaisesti välitämme DOCKERIMAGE-ympäristömuuttujan sen kuvan nimellä, josta olemme kiinnostuneita, ja liitämme Docker-tiedoston, jonka haluamme analysoida koneeltamme tiedostoon. /Docker-tiedosto (huomaa, että absoluuttinen polku tähän tiedostoon vaaditaan):

docker run --rm -v $(pwd)/results:/results -v $(pwd)/docker_security.df:/Dockerfile -e DOCKERIMAGE="bkimminich/juice-shop" dscan:image


[+] Setting environment variables
[+] Running Hadolint
/Dockerfile:3 DL3006 Always tag the version of an image explicitly
[+] Running Dockle
WARN    - DKL-DI-0006: Avoid latest tag
        * Avoid 'latest' tag
INFO    - CIS-DI-0005: Enable Content trust for Docker
        * export DOCKER_CONTENT_TRUST=1 before docker pull/build
INFO    - CIS-DI-0006: Add HEALTHCHECK instruction to the container image
        * not found HEALTHCHECK statement
INFO    - DKL-LI-0003: Only put necessary files
        * unnecessary file : juice-shop/node_modules/sqlite3/Dockerfile
        * unnecessary file : juice-shop/node_modules/sqlite3/tools/docker/architecture/linux-arm64/Dockerfile
        * unnecessary file : juice-shop/node_modules/sqlite3/tools/docker/architecture/linux-arm/Dockerfile
[+] Running Trivy
...
juice-shop/package-lock.json
============================
Total: 20 (UNKNOWN: 0, LOW: 1, MEDIUM: 6, HIGH: 8, CRITICAL: 5)
...
[+] Making the output look pretty
[+] Starting the main module ============================================================
[+] Converting JSON results
[+] Writing results HTML
[+] Clean exit ============================================================
[+] Everything is done. Find the resulting HTML report in results.html

Tulokset

Tarkastelimme vain yhtä perusapuohjelmaa Docker-artefaktien skannaamiseen, mikä mielestäni kattaa erittäin tehokkaasti kunnon osan kuvan suojausvaatimuksista. On myös suuri määrä maksullisia ja ilmaisia ​​työkaluja, jotka voivat suorittaa samoja tarkistuksia, tehdä kauniita raportteja tai työskennellä puhtaasti konsolitilassa, peittää kontinhallintajärjestelmät jne. Yleiskatsaus näistä työkaluista ja niiden integroimisesta saattaa ilmestyä hieman myöhemmin. .

Hyvä puoli artikkelissa kuvatuissa työkaluissa on, että ne kaikki on rakennettu avoimeen lähdekoodiin ja voit kokeilla niitä ja muita vastaavia työkaluja löytääksesi tarpeisiisi ja infrastruktuuriominaisuuksiisi sopivan. Tietysti kaikki löydetyt haavoittuvuudet tulisi tutkia soveltuvuuden varalta tietyissä olosuhteissa, mutta tämä on tulevaisuuden suuren artikkelin aihe.

Toivon, että tämä opas, komentosarjat ja apuohjelmat auttavat sinua ja niistä tulee lähtökohta turvallisemman infrastruktuurin luomiselle konttien alueella.

Lähde: will.com

Lisää kommentti