欧美黄色一级片免费看,九色蝌蚪9l视频蝌蚪9l视频,国产精品夜夜,艹逼胖子网站免费视频,免费欧美一级,国产一级a毛一级a做免费图,76人少妇精品导航,色婷婷在线视频精品导航

這篇文章出人意料地登上了黑客新聞的頭版，并在那里引發(fā)了一場(chǎng)富有成效的討論。我將試著總結(jié)一下主要的要點(diǎn)：

漏洞掃描器往往有很多誤報(bào)

一些報(bào)告的發(fā)現(xiàn)已經(jīng)可以在上游和后端修復(fù)
有些可能完全不相關(guān)，因?yàn)樗鼈兲囟ㄓ谀承┥願(yuàn)W的架構(gòu)

在鏡像倉庫（例如Docker Hub）中，官方基礎(chǔ)鏡像從不（或很少）更新
隨著容器使用的增加，為操作系統(tǒng)打補(bǔ)丁的負(fù)擔(dān)實(shí)際上從管理員和操作人員轉(zhuǎn)移到了開發(fā)人員身上
但并不是每個(gè)開發(fā)者都意識(shí)到這一點(diǎn)

有些人建議在每個(gè)Dockerfile的開頭添加RUN apt-get update &&?apt-get -y upgrade，我嘗試了一下，在完全成熟的Debian 10發(fā)行版中，它提供了非常小的效果
但其他人反駁說，這會(huì)導(dǎo)致不可復(fù)制的構(gòu)建，以及由于反向端口改變依賴的默認(rèn)行為而導(dǎo)致的潛在風(fēng)險(xiǎn)
這導(dǎo)致了一個(gè)公平的控制源存儲(chǔ)庫的建議
當(dāng)然，這會(huì)讓事情變得更復(fù)雜
這就是為什么最典型的解決方案似乎是簡(jiǎn)單的，忽略了這個(gè)問題

盡管掃描結(jié)果很好，但Alpine鏡像并不總是很好

因?yàn)閾?jù)報(bào)道m(xù)usl libc比glibc慢，并不是每個(gè)依賴庫都為這個(gè)平臺(tái)提供構(gòu)建

以下是原文。

我最近在破解容器時(shí)注意到，Docker開始在構(gòu)建輸出中突出Docker掃描命令。我已經(jīng)忽略它的存在有一段時(shí)間了，所以是時(shí)候嘗試一下了。

掃描官方Python鏡像

Docker掃描命令使用一個(gè)第三方工具，稱為Snyk Container。顯然，這是某種漏洞掃描器。所以，我決定，主要是為了好玩，掃描我的一個(gè)鏡像。這是一件非常基本的事情：

#?latest?stable?at?the?time
FROM?python:3.9

RUN?pip?install?Flask

COPY?server.py?server.py

ENV?FLASK_APP=server.py
ENV?FLASK_RUN_PORT=5000
ENV?FLASK_RUN_HOST=0.0.0.0

EXPOSE?5000

CMD?["flask",?"run"]

我運(yùn)行docker build -t python-flask，然后容器掃描python-flask。令我非常驚訝的是，產(chǎn)生大量的輸出！下面是一段摘錄：

Testing?python-flask...

??Low?severity?vulnerability?found?in?unbound/libunbound8
??Description:?Improper?Input?Validation
??Info:?https://snyk.io/vuln/SNYK-DEBIAN10-UNBOUND-534899
??Introduced?through:?mysql-defaults/[email protected]
??From:?mysql-defaults/[email protected]?>?mariadb-10.3/libmariadb-dev-compat@1:10.3.27-0+deb10u1?>?mariadb-10.3/libmariadb-dev@1:10.3.27-0+deb10u1?>?gnutls28/[email protected]+deb10u6?>?gnutls28/[email protected]+deb10u6?>?unbound/[email protected]+deb10u2

??Low?severity?vulnerability?found?in?tiff/libtiff5
??Description:?Out-of-Bounds
??Info:?https://snyk.io/vuln/SNYK-DEBIAN10-TIFF-1079067
??Introduced?through:?imagemagick@8:6.9.10.23+dfsg-2.1+deb10u1,?imagemagick/libmagickcore-dev@8:6.9.10.23+dfsg-2.1+deb10u1
??From:?imagemagick@8:6.9.10.23+dfsg-2.1+deb10u1?>?imagemagick/imagemagick-6.q16@8:6.9.10.23+dfsg-2.1+deb10u1?>?imagemagick/libmagickcore-6.q16-6@8:6.9.10.23+dfsg-2.1+deb10u1?>?tiff/[email protected]+git191117-2~deb10u2
??From:?imagemagick/libmagickcore-dev@8:6.9.10.23+dfsg-2.1+deb10u1?>?imagemagick/libmagickcore-6.q16-dev@8:6.9.10.23+dfsg-2.1+deb10u1?>?tiff/[email protected]+git191117-2~deb10u2?>?tiff/[email protected]+git191117-2~deb10u2
??From:?imagemagick/libmagickcore-dev@8:6.9.10.23+dfsg-2.1+deb10u1?>?imagemagick/libmagickcore-6.q16-dev@8:6.9.10.23+dfsg-2.1+deb10u1?>?tiff/[email protected]+git191117-2~deb10u2?>?tiff/[email protected]+git191117-2~deb10u2?>?tiff/[email protected]+git191117-2~deb10u2
??and?3?more...

...

??High?severity?vulnerability?found?in?gcc-8
??Description:?Insufficient?Entropy
??Info:?https://snyk.io/vuln/SNYK-DEBIAN10-GCC8-469413
??Introduced?through:?gcc-defaults/g++@4:8.3.0-1,[email protected],?imagemagick@8:6.9.10.23+dfsg-2.1+deb10u1,?meta-common-packages@meta
??From:?gcc-defaults/g++@4:8.3.0-1?>[email protected]
??From:[email protected]?>[email protected]
??From:?gcc-defaults/g++@4:8.3.0-1?>?gcc-8/[email protected]?>[email protected]
??and?23?more...

??High?severity?vulnerability?found?in?djvulibre/libdjvulibre21
??Description:?NULL?Pointer?Dereference
??Info:?https://snyk.io/vuln/SNYK-DEBIAN10-DJVULIBRE-481572
??Introduced?through:?imagemagick/libmagickcore-dev@8:6.9.10.23+dfsg-2.1+deb10u1
??From:?imagemagick/libmagickcore-dev@8:6.9.10.23+dfsg-2.1+deb10u1?>?imagemagick/libmagickcore-6.q16-dev@8:6.9.10.23+dfsg-2.1+deb10u1?>?djvulibre/[email protected]?>?djvulibre/[email protected]
??From:?imagemagick/libmagickcore-dev@8:6.9.10.23+dfsg-2.1+deb10u1?>?imagemagick/libmagickcore-6.q16-dev@8:6.9.10.23+dfsg-2.1+deb10u1?>?imagemagick/libmagickcore-6.q16-6-extra@8:6.9.10.23+dfsg-2.1+deb10u1?>?djvulibre/[email protected]
??From:?imagemagick/libmagickcore-dev@8:6.9.10.23+dfsg-2.1+deb10u1?>?imagemagick/libmagickcore-6.q16-dev@8:6.9.10.23+dfsg-2.1+deb10u1?>?djvulibre/[email protected]
??and?1?more...

??High?severity?vulnerability?found?in?bluez/libbluetooth3
??Description:?Double?Free
??Info:?https://snyk.io/vuln/SNYK-DEBIAN10-BLUEZ-1018718
??Introduced?through:?bluez/[email protected]~deb10u1
??From:?bluez/[email protected]~deb10u1?>?bluez/[email protected]~deb10u1
??From:?bluez/[email protected]~deb10u1



Package?manager:???deb
Project?name:??????docker-image|python-flask
Docker?image:??????python-flask
Platform:??????????linux/amd64

Tested?431?dependencies?for?known?vulnerabilities,?found?358?vulnerabilities.

For?more?free?scans?that?keep?your?images?secure,?sign?up?to?Snyk?at?https://dockr.ly/3ePqVcp

共發(fā)現(xiàn)漏洞358個(gè)，其中高級(jí)別54個(gè)，中級(jí)別48個(gè)。

仔細(xì)查看掃描報(bào)告后，我發(fā)現(xiàn)的大部分漏洞可能與Debian有關(guān)（參見信息：https://snyk.io/vuln/SNYK-DEBIAN10-…稍高一點(diǎn)，報(bào)告中很多項(xiàng)目都有）。

顯然，python:3.9鏡像是基于成熟的Debian 10發(fā)行版。

114MB的潛在安全漏洞

老實(shí)說，這是令人興奮的！我知道容器越厚，潛在的攻擊面就越高。但無論如何，我沒想到會(huì)有這么大的規(guī)模。

好的，讓我們?cè)囍宴R像瘦身……

FROM?python:3.9-slim

RUN?pip?install?Flask

COPY?server.py?server.py

ENV?FLASK_APP=server.py
ENV?FLASK_RUN_PORT=5000
ENV?FLASK_RUN_HOST=0.0.0.0

EXPOSE?5000

CMD?["flask",?"run"]

掃描python:3.9-slim的鏡像給了我更好的結(jié)果：

Package?manager:???deb
Project?name:??????docker-image|python-flask-slim
Docker?image:??????python-flask-slim
Platform:??????????linux/amd64

Tested?94?dependencies?for?known?vulnerabilities,?found?69?vulnerabilities.

共發(fā)現(xiàn)69個(gè)漏洞，其中高級(jí)別14個(gè)，中級(jí)別8個(gè)。

基礎(chǔ)鏡像每兆字節(jié)有一個(gè)漏洞……

我們能做得更好嗎？讓我們嘗試python: 3.9-alpine：

FROM?python:3.9-alpine

RUN?pip?install?Flask

COPY?server.py?server.py

ENV?FLASK_APP=server.py
ENV?FLASK_RUN_PORT=5000
ENV?FLASK_RUN_HOST=0.0.0.0

EXPOSE?5000

CMD?["flask",?"run"]

終于，0已知的漏洞！

Package?manager:???apk
Project?name:??????docker-image|python-flask-alpine
Docker?image:??????python-flask-alpine
Platform:??????????linux/amd64

??Tested?37?dependencies?for?known?issues,?no?vulnerable?paths?found.

5.6 MB Alpine！

掃描無發(fā)布的Python鏡像

另一個(gè)可能解決膨脹容器問題的方案是谷歌所謂的“非發(fā)行版”Docker鏡像。項(xiàng)目描述說它是“語言聚焦Docker鏡像，減去操作系統(tǒng)”。盡管這在Python的情況下很難實(shí)現(xiàn)，因?yàn)樗臉?biāo)準(zhǔn)庫依賴于一些高級(jí)操作系統(tǒng)功能。

我花了一段時(shí)間才想出一個(gè)可以工作的非發(fā)行版Python鏡像。大多數(shù)示例都展示了如何使用一些簡(jiǎn)單的腳本。然而，安裝Flask（或任何其他依賴項(xiàng)）比我預(yù)期的要困難得多。由于gcr，Python的無發(fā)行版容器需要多階段的構(gòu)建過程。gcr.io/distroless/python3鏡像既沒有PIP，也沒有easy_install。首先，我試圖利用構(gòu)建鏡像中的虛擬環(huán)境，然后將其復(fù)制到運(yùn)行時(shí)鏡像中，并修改PATH變量。但它并沒有很好地工作，因?yàn)榛镜姆前l(fā)行版鏡像在文件系統(tǒng)布局上做了一些自以為是的布局：

預(yù)料之中的是，Linux distr仍然存在，但是它比debian還要薄

所以，我最終得到了以下Dockerfile，允許我在非發(fā)行版的Python鏡像中安裝Flask：

#?Build?image
FROM?python:3.7-slim?AS?build-env

RUN?python?-m?pip?install?Flask

#?Runtime?image
FROM?gcr.io/distroless/python3

COPY?--from=build-env?/usr/local/bin/flask?/usr/local/bin/flask
COPY?--from=build-env?/usr/local/lib/python3.7/site-packages?/usr/local/lib/python3.7/site-packages

WORKDIR?/app

COPY?server.py?server.py

#?Important?line!
ENV?PYTHONPATH=/usr/local/lib/python3.7/site-packages

ENV?FLASK_APP=server.py
ENV?FLASK_RUN_PORT=5000
ENV?FLASK_RUN_HOST=0.0.0.0

EXPOSE?5000

CMD?["/usr/local/bin/flask",?"run"]

掃描它與Docker掃描輸出以下結(jié)果：

Package?manager:???deb
Project?name:??????docker-image|python-flask-distroless
Docker?image:??????python-flask-distroless
Platform:??????????linux/amd64

Tested?25?dependencies?for?known?vulnerabilities,?found?37?vulnerabilities.

所以，只有37個(gè)漏洞：6個(gè)嚴(yán)重程度高，8個(gè)中等。聽起來好像比原始的python:3.9鏡像減少了90%！它甚至比python:3.9-slim中的漏洞更少。

因此，我們的基于Alpine的Python鏡像是一個(gè)贏家！

掃描Go鏡像

我喜歡完全從零開始構(gòu)建容器鏡像的想法，避免將任何distr內(nèi)容放入其中。但為此，你需要一種對(duì)靜態(tài)構(gòu)建有深刻支持的語言，例如Go：

FROM?scratch

COPY?hello?/
CMD?["/hello"]

得出以下結(jié)果……沒錯(cuò)，這就是它！

Testing?go-scratch...

Package?manager:???linux
Project?name:??????docker-image|go-scratch
Docker?image:??????go-scratch
Platform:??????????linux/amd64

??Tested?go-scratch?for?known?vulnerabilities,?no?vulnerable?paths?found.

沒有distr并不意味著沒有漏洞。但它確實(shí)降低了攻擊的可能性。

相反的結(jié)論

根據(jù)我的經(jīng)驗(yàn)，膨脹的鏡像通常是使用默認(rèn)的From bloated_base，或者因?yàn)槿藗優(yōu)榱藢淼恼{(diào)試/故障排除故意將額外的工具放入鏡像的結(jié)果。

第一種可能是Docker過去大規(guī)模營銷活動(dòng)的結(jié)果。為了普及容器，你需要給人們一些看起來很酷和方便的東西。而且能夠在一秒鐘內(nèi)從你的開發(fā)機(jī)器上啟動(dòng)一個(gè)成熟的Linux distr（某種程度上），即使在今天看起來也很酷。一些本地的修補(bǔ)和/或?qū)嶒?yàn)從docker run -it ubuntu中獲益良多。然而，我希望它從來沒有被用于生產(chǎn)。但是從一個(gè)成熟的Debian，CentOS，或者Ubuntu開始，Dockerfile的例子實(shí)在是太多了，至少要避免將其中一些滲透到我們的生產(chǎn)環(huán)境中。

第二個(gè)原因看起來更合理。但我有一種感覺，這只是第一眼看到的感覺。理想情況下，應(yīng)該有另一種方法來調(diào)試你的容器化服務(wù)。這種方法不需要將所有潛在需要的工具打包到一個(gè)容器中。最近添加的kubectl調(diào)試功能很好地證明了這一假設(shè)。它允許將臨時(shí)容器注入運(yùn)行中的Pod中，這樣的容器可以擁有調(diào)試所需的所有東西。

更小的容器不僅僅意味著更快的構(gòu)建和更小的磁盤和網(wǎng)絡(luò)利用率，它們還意味著更安全。

原文鏈接：https://iximiuz.com/en/posts/thick-container-vulnerabilities/

推薦閱讀

五款免費(fèi)又好用的Docker容器GUI工具

福利

我為大家整理了一份從入門到進(jìn)階的Go學(xué)習(xí)資料禮包，包含學(xué)習(xí)建議：入門看什么，進(jìn)階看什么。關(guān)注公眾號(hào) 「polarisxu」，回復(fù)?ebook?獲?。贿€可以回復(fù)「進(jìn)群」，和數(shù)萬 Gopher 交流學(xué)習(xí)。

為什么你需要更小巧的容器？