Hej Habr!
Në realitetin modern, për shkak të rolit në rritje të kontejnerizimit në proceset e zhvillimit, çështja e sigurimit të sigurisë së fazave dhe subjekteve të ndryshme që lidhen me kontejnerët nuk është çështja më pak e rëndësishme. Kryerja e kontrolleve manuale kërkon shumë kohë, ndaj do të ishte ide e mirë të ndërmerrni të paktën hapat fillestarë drejt automatizimit të këtij procesi.
Në këtë artikull, unë do të ndaj skriptet e gatshme për zbatimin e disa shërbimeve të sigurisë Docker dhe udhëzimet se si të vendosni një stendë të vogël demo për të testuar këtë proces. Ju mund t'i përdorni materialet për të eksperimentuar se si të organizoni procesin e testimit të sigurisë së imazheve dhe udhëzimeve të Dockerfile. Është e qartë se infrastruktura e zhvillimit dhe zbatimit të secilit është e ndryshme, kështu që më poshtë do të jap disa opsione të mundshme.
Shërbimet e kontrollit të sigurisë
Ka një numër të madh aplikacionesh dhe skriptesh ndihmëse të ndryshme që kryejnë kontrolle në aspekte të ndryshme të infrastrukturës Docker. Disa prej tyre janë përshkruar tashmë në artikullin e mëparshëm (), dhe në këtë material do të doja të përqendrohesha në tre prej tyre, të cilat mbulojnë pjesën më të madhe të kërkesave të sigurisë për imazhet Docker të ndërtuara gjatë procesit të zhvillimit. Përveç kësaj, unë do të tregoj gjithashtu një shembull se si këto tre shërbime mund të lidhen në një tubacion për të kryer kontrolle sigurie.
Hadolint
Një mjet mjaft i thjeshtë i konsolës që ndihmon, si përafrim i parë, të vlerësojë korrektësinë dhe sigurinë e udhëzimeve të Dockerfile (për shembull, duke përdorur vetëm regjistra të autorizuar të imazheve ose duke përdorur sudo).
Dockle
Një mjet konsole që punon me një imazh (ose me një arkiv tar të ruajtur të një imazhi), i cili kontrollon korrektësinë dhe sigurinë e një imazhi të caktuar si i tillë, duke analizuar shtresat dhe konfigurimin e tij - cilët përdorues janë krijuar, cilat udhëzime përdoren, cilat vëllimet janë montuar, prania e një fjalëkalimi bosh, etj. d. Deri tani numri i kontrolleve nuk është shumë i madh dhe bazohet në disa nga kontrollet dhe rekomandimet tona për Docker.
I parëndësishëm
Ky mjet ka për qëllim gjetjen e dy llojeve të dobësive - problemet me ndërtimet e OS (mbështetur nga Alpine, RedHat (EL), CentOS, Debian GNU, Ubuntu) dhe problemet me varësitë (Gemfile.lock, Pipfile.lock, composer.lock, paketa -lock.json , fije.bllokoj, kargo.blloqe). Trivy mund të skanojë si një imazh në depo ashtu edhe një imazh lokal, dhe gjithashtu mund të skanojë bazuar në skedarin .tar të transferuar me imazhin Docker.
Opsionet për zbatimin e shërbimeve
Për të provuar aplikacionet e përshkruara në një mjedis të izoluar, unë do të jap udhëzime për instalimin e të gjitha shërbimeve në një proces disi të thjeshtuar.
Ideja kryesore është të demonstroni se si mund të zbatoni verifikimin automatik të përmbajtjes së Dockerfiles dhe imazheve Docker që krijohen gjatë zhvillimit.
Kontrolli në vetvete përbëhet nga hapat e mëposhtëm:
- Kontrollimi i korrektësisë dhe sigurisë së udhëzimeve të Dockerfile duke përdorur një mjet linter Hadolint
- Kontrollimi i korrektësisë dhe sigurisë së imazheve përfundimtare dhe të ndërmjetme duke përdorur një mjet Dockle
- Kontrollimi i pranisë së dobësive të njohura publikisht (CVE) në imazhin bazë dhe një sërë varësish - duke përdorur programin I parëndësishëm
Më vonë në artikull do të jap tre opsione për zbatimin e këtyre hapave:
E para është duke konfiguruar tubacionin CI/CD duke përdorur GitLab si shembull (me një përshkrim të procesit të ngritjes së një shembulli testimi).
E dyta është përdorimi i një skripti shell.
E treta përfshin ndërtimin e një imazhi Docker për të skanuar imazhet Docker.
Ju mund të zgjidhni opsionin që ju përshtatet më shumë, ta transferoni atë në infrastrukturën tuaj dhe ta përshtatni atë sipas nevojave tuaja.
Të gjithë skedarët e nevojshëm dhe udhëzimet shtesë gjenden gjithashtu në depo:
Integrimi në GitLab CI/CD
Në opsionin e parë, ne do të shikojmë se si mund të zbatoni kontrollet e sigurisë duke përdorur sistemin e depove GitLab si shembull. Këtu do të kalojmë nëpër hapat dhe do të kuptojmë se si të instalojmë një mjedis testimi me GitLab nga e para, të krijojmë një proces skanimi dhe të nisim shërbimet për kontrollimin e Dockerfile-it të testit dhe një imazh të rastësishëm - aplikacionin JuiceShop.
Instalimi i GitLab
1. Instaloni Docker:
sudo apt-get update && sudo apt-get install docker.io2. Shtoni përdoruesin aktual në grupin docker në mënyrë që të mund të punoni me docker pa përdorur sudo:
sudo addgroup <username> docker3. Gjeni IP-në tuaj:
ip addr4. Instaloni dhe nisni GitLab në kontejner, duke zëvendësuar adresën IP në emrin e hostit me tuajën:
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:latestNe presim derisa GitLab të përfundojë të gjitha procedurat e nevojshme të instalimit (ju mund ta monitoroni procesin përmes daljes së skedarit log: docker logs -f gitlab).
5. Hapni IP-në tuaj lokale në shfletues dhe shihni një faqe që ju kërkon të ndryshoni fjalëkalimin për përdoruesin rrënjë:
Vendosni një fjalëkalim të ri dhe shkoni te GitLab.
6. Krijoni një projekt të ri, për shembull cicd-test dhe inicializoni atë me skedarin startues LEXONI.md:
7. Tani duhet të instalojmë GitLab Runner: një agjent që do të ekzekutojë të gjitha operacionet e nevojshme sipas kërkesës.
Shkarkoni versionin më të fundit (në këtë rast, për Linux 64-bit):
sudo curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd648. Bëjeni atë të ekzekutueshëm:
sudo chmod +x /usr/local/bin/gitlab-runner9. Shtoni një përdorues të OS për Runner dhe filloni shërbimin:
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 startDuhet të duket diçka si kjo:
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. Tani ne e regjistrojmë Runner-in në mënyrë që të mund të ndërveprojë me shembullin tonë GitLab.
Për ta bërë këtë, hapni faqen Settings-CI/CD (http://OUR_IP_ADDRESS/root/cicd-test/-/settings/ci_cd) dhe në skedën Runners gjeni URL-në dhe shenjën e regjistrimit:
11. Regjistrohu Runner duke zëvendësuar URL-në dhe tokenin e Regjistrimit:
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"Si rezultat, marrim një GitLab të gatshëm të punës, në të cilin duhet të shtojmë udhëzime për të nisur shërbimet tona. Në këtë demonstrim nuk kemi hapat për të ndërtuar aplikacionin dhe për ta kontejneruar atë, por në një mjedis real këto do t'i paraprijnë hapave të skanimit dhe do të gjenerojnë imazhe dhe një Dockerfile për analizë.
konfigurimi i tubacionit
1. Shtoni skedarë në depo mydockerfile.df (ky është një Dockerfile provë që do ta kontrollojmë) dhe skedari i konfigurimit të procesit GitLab CI/CD .gitlab-cicd.yml, i cili rendit udhëzimet për skanerët (vini re pikën në emrin e skedarit).
Skedari i konfigurimit YAML përmban udhëzime për të ekzekutuar tre shërbime (Hadolint, Dockle dhe Trivy) që do të analizojnë skedarin e zgjedhur Docker dhe imazhin e specifikuar në variablin DOCKERFILE. Të gjithë skedarët e nevojshëm mund të merren nga depoja:
Fragment nga mydockerfile.df (ky është një skedar abstrakt me një grup udhëzimesh arbitrare vetëm për të demonstruar funksionimin e programit). Lidhje direkte me skedarin:
Përmbajtja e mydockerfile.df
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 rootKonfigurimi YAML duket kështu (vetë skedari mund të gjendet përmes lidhjes direkte këtu: ):
Përmbajtja e .gitlab-ci.yml
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.htmlNëse është e nevojshme, mund të skanoni edhe imazhet e ruajtura në formën e një arkivi .tar (megjithatë, do t'ju duhet të ndryshoni parametrat e hyrjes për shërbimet në skedarin YAML)
NB: Trivy kërkon instalim rpm и git. Përndryshe, ai do të gjenerojë gabime gjatë skanimit të imazheve të bazuara në RedHat dhe marrjen e përditësimeve në bazën e të dhënave të cenueshmërisë.
2. Pas shtimit të skedarëve në depo, sipas udhëzimeve në skedarin tonë të konfigurimit, GitLab do të fillojë automatikisht procesin e ndërtimit dhe skanimit. Në skedën CI/CD → Pipelines mund të shihni ecurinë e udhëzimeve.
Si rezultat, ne kemi katër detyra. Tre prej tyre merren drejtpërdrejt me skanimin dhe i fundit (Raporti) mbledh një raport të thjeshtë nga skedarët e shpërndarë me rezultate skanimi.
Si parazgjedhje, Trivy ndalon së funksionuari nëse zbulohen dobësi KRITIKE në imazh ose varësi. Në të njëjtën kohë, Hadolint kthen gjithmonë një kod Suksesi sepse gjithmonë rezulton në komente, gjë që bën që ndërtimi të ndalojë.
Në varësi të kërkesave tuaja specifike, mund të konfiguroni një kod daljeje në mënyrë që kur këto shërbime të zbulojnë probleme të një kritike të caktuar, të ndalojnë gjithashtu procesin e ndërtimit. Në rastin tonë, ndërtimi do të ndalet vetëm nëse Trivy zbulon një cenueshmëri me kritikën që kemi specifikuar në variablin SHOWSTOPPER në .gitlab-ci.yml.
Rezultati i çdo mjeti mund të shihet në regjistrin e secilës detyrë skanimi, direkt në skedarët json në seksionin e objekteve ose në një raport të thjeshtë HTML (më shumë për këtë më poshtë):
3. Për të paraqitur raportet e shërbimeve në një formë pak më të lexueshme nga njeriu, një skrip i vogël Python përdoret për të kthyer tre skedarë JSON në një skedar HTML me një tabelë defektesh.
Ky skrip niset nga një detyrë e veçantë Raporti dhe artifakti i tij përfundimtar është një skedar HTML me një raport. Burimi i skriptit është gjithashtu në depo dhe mund të përshtatet për t'iu përshtatur nevojave, ngjyrave, etj.
Skenari i guaskës
Opsioni i dytë është i përshtatshëm për rastet kur duhet të kontrolloni imazhet e Docker jashtë sistemit CI/CD ose duhet të keni të gjitha udhëzimet në një formë që mund të ekzekutohet direkt në host. Ky opsion mbulohet nga një skrip shell i gatshëm që mund të ekzekutohet në një makinë të pastër virtuale (ose edhe reale). Skripti ekzekuton të njëjtat udhëzime si gitlab-runner i përshkruar më sipër.
Që skripti të funksionojë me sukses, Docker duhet të instalohet në sistem dhe përdoruesi aktual duhet të jetë në grupin docker.
Vetë skenari mund të gjendet këtu:
Në fillim të skedarit, variablat përcaktojnë se cili imazh duhet të skanohet dhe cilat defekte kritike do të bëjnë që programi Trivy të dalë me kodin e specifikuar të gabimit.
Gjatë ekzekutimit të skriptit, të gjitha shërbimet do të shkarkohen në drejtori docker_tools, rezultatet e punës së tyre janë në drejtori docker_tools/json, dhe HTML me raportin do të jetë në skedar rezultatet.html.
Shembull i daljes së skriptit
~/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.htmlImazhi i dokerit me të gjitha shërbimet
Si një alternativë e tretë, unë përpilova dy skedarë të thjeshtë Docker për të krijuar një imazh me shërbimet e sigurisë. Një Dockerfile do të ndihmojë në ndërtimin e një grupi për skanimin e një imazhi nga një depo, i dyti (Dockerfile_tar) do të ndihmojë në ndërtimin e një grupi për skanimin e një skedari tar me një imazh.
1. Merrni skedarin përkatës Docker dhe skriptet nga depoja .
2. E nisim për montim:
docker build -t dscan:image -f docker_security.df .
3. Pasi të përfundojë montimi, ne krijojmë një enë nga imazhi. Në të njëjtën kohë, ne kalojmë variablin e mjedisit DOCKERIMAGE me emrin e imazhit që na intereson dhe montojmë Dockerfile që duam të analizojmë nga makina jonë në skedar. /Dockerfile (vini re se rruga absolute për këtë skedar kërkohet):
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.htmlGjetjet
Ne shikuam vetëm një grup bazë të shërbimeve për skanimin e objekteve Docker, i cili, për mendimin tim, mbulon në mënyrë shumë efektive një pjesë të mirë të kërkesave të sigurisë së imazhit. Ekzistojnë gjithashtu një numër i madh mjetesh me pagesë dhe falas që mund të kryejnë të njëjtat kontrolle, të nxjerrin raporte të bukura ose të punojnë thjesht në modalitetin e konsolës, të mbulojnë sistemet e menaxhimit të kontejnerëve, etj. Një përmbledhje e këtyre mjeteve dhe mënyra e integrimit të tyre mund të shfaqet pak më vonë .
E mira e grupit të mjeteve të përshkruara në këtë artikull është se ato janë të gjitha me burim të hapur dhe ju mund të eksperimentoni me to dhe mjete të tjera të ngjashme për të gjetur atë që i përshtatet nevojave dhe infrastrukturës suaj. Natyrisht, të gjitha dobësitë që gjenden duhet të studiohen për zbatueshmëri në kushte specifike, por kjo është një temë për një artikull të madh në të ardhmen.
Shpresoj se ky udhëzues, skriptet dhe shërbimet do t'ju ndihmojnë dhe do të bëhet një pikënisje për krijimin e një infrastrukture më të sigurt në fushën e kontejnerizimit.
Burimi: www.habr.com