資訊專欄INFORMATION COLUMN
摘要：今天的文章由來自的和撰寫，在不同用戶案例中搜集到的數(shù)據(jù)基礎(chǔ)上，描述了的安全最佳實(shí)踐。在谷歌上，我們的用來部署我們的服務(wù)。實(shí)施連續(xù)安全缺陷掃描容器可能包含過時(shí)的已知缺陷的程序包。谷歌云平臺的用戶能夠從自動(dòng)防火墻規(guī)則中受益，避免跨集群交流。
今天的文章由來自 Aqua Security 的 Amir Jerbl 和 Micheal Chemy 撰寫，在不同用戶案例中搜集到的數(shù)據(jù)基礎(chǔ)上，描述了 Kubernetes Deployment 的安全最佳實(shí)踐。
Kubernetes 提供了很多配置來提升應(yīng)用程序的安全性。但是配置這些需要深入了解 Kubernetes 的初始知識以及一些安全的需求。我們在這里要強(qiáng)調(diào)的最佳實(shí)踐跟容器的生命周期相匹配：創(chuàng)建，運(yùn)送以及運(yùn)行，以及為 Kubernetes 特別定制。在谷歌 GCE 上，我們的用 Kubernetes 來部署我們的 SaaS 服務(wù) 。
對于部署安全的 Kubernetes 應(yīng)用程序，我們推薦以下：
確認(rèn)鏡像是沒有缺陷運(yùn)行沒有缺陷的容器會(huì)使你的環(huán)境面臨輕易妥協(xié)的威脅。很多攻擊都可以簡單地通過確認(rèn)軟件組件沒有缺陷來減輕。
實(shí)施連續(xù)安全缺陷掃描
容器可能包含過時(shí)的已知缺陷的程序包（CVEs）。而且每天都有缺點(diǎn)被暴露出來，所以這并不是一個(gè)“一次性”進(jìn)程。作為一個(gè)連續(xù)評估鏡像不間斷的程序，這個(gè)程序?qū)τ诖_保所需安全狀態(tài)非常重要。
你的環(huán)境需要定期申請安全更新
一旦運(yùn)行中的容器被發(fā)現(xiàn)有缺陷，你需要做的就是更新資源鏡像，重新部署容器。嘗試避免直接更新到運(yùn)行的容器，因?yàn)檫@樣可能會(huì)破壞鏡像跟容器之間的關(guān)系。有了 Kubernetes 的滾動(dòng)升級功能，升級容器變得十分容易——這個(gè)功能可以通過升級鏡像到最新版本來慢慢更新運(yùn)行的應(yīng)用程序。
如果沒有程序來確認(rèn)只有鏡像依附在組織機(jī)構(gòu)的策略上，那么組織機(jī)構(gòu)就容易受到有缺陷或者是惡意的容器的攻擊。
從未知的資源里下載運(yùn)行鏡像是十分危險(xiǎn)的。這就相當(dāng)于在生產(chǎn)環(huán)境的服務(wù)器上運(yùn)行一個(gè)未知軟件提供商的產(chǎn)品一樣。所以，不要那么做。
使用私有庫來存儲規(guī)定鏡像——確保你只 push 規(guī)定的鏡像到這些庫。這已經(jīng)把運(yùn)行的領(lǐng)域縮小了，減少了可進(jìn)入管道的數(shù)量。
創(chuàng)建集成安全評估（比如漏洞掃描）的 CI 管道，使之成為創(chuàng)建進(jìn)程的一部分。
CI 管道要確保代碼被審查過才能夠用來創(chuàng)建鏡像。鏡像創(chuàng)建好了，就要掃描有沒有安全缺陷，如果沒有的話，那么鏡像就會(huì)被 push 到一個(gè)私有庫，在這個(gè)私有庫，部署到產(chǎn)品就完成了。安全評估要是失敗的話，管道也會(huì)相應(yīng)失敗，這樣就避免了安全質(zhì)量不好的鏡像被 push 到鏡像倉庫。
在 Kubernetes 中還有很多需要為鏡像授權(quán)插件做的工作（期望在 Kubernetes1.4中能夠完成），這就避免了運(yùn)送未授權(quán)的鏡像。
需要限制 SSH 訪問 Kubernetes 節(jié)點(diǎn)，減少未授權(quán)訪問主機(jī)資源的風(fēng)險(xiǎn)。同時(shí)要求用戶使用“kubectl exec”，它可以直接訪問容器環(huán)境，而不需要訪問主機(jī)。
可以使用 Kubernetes 授權(quán)插件來遠(yuǎn)程控制用戶訪問資源。這也就意味著要為特定的 namespace，容器和操作來定義細(xì)粒度訪問控制規(guī)則。
在資源間創(chuàng)建管理的邊界限制用戶權(quán)限的范圍能夠控制錯(cuò)誤或者惡意活動(dòng)的發(fā)生。Kubernetes 的 namespace 允許把創(chuàng)建的資源分割成邏輯的 group。在一個(gè) namespace 中創(chuàng)建的資源在其它的 namespace 中不可見。默認(rèn)設(shè)置下，每個(gè)由 Kubernetes 集群用戶創(chuàng)建的資源都運(yùn)行在一個(gè)默認(rèn) namespace 中，名為 default。你可以創(chuàng)建額外的 namespace，并在該 namespace 中創(chuàng)建資源，然后使用這些資源。你也可以使用 Kubernetes 授權(quán)插件來創(chuàng)建策略，來隔離訪問不同用戶間的 namespace 資源。
比如：以下就是策略允許“alice”從 namespace“fronto”閱讀 pods。
定義資源配額運(yùn)行資源未裝訂的容器，你的系統(tǒng)可能面臨陷入 DoS 或者“noisy neighbor”場景的風(fēng)險(xiǎn)。為了避免，或者說是將這些風(fēng)險(xiǎn)最小化，你需要定義資源配額。默認(rèn)設(shè)置下，所有在 Kubernetes 集群中的資源都是用 unbounded 的 CPU 和內(nèi)存要求／限制來創(chuàng)建的。為了限制 Pod 允許使用的 cpu 和 memory 資源，你可以創(chuàng)建資源配額策略，并把這個(gè)策略應(yīng)用到 Kubernetes 的 namespace 上。
以下是 namespace 資源配額定義的一個(gè)例子，它限制 namespace 中 pod 的數(shù)量不能超過4個(gè)，限制他們的 CPU 請求在1到2個(gè)之間，內(nèi)存請求在1GB 到2GB 之間。
compute-resource.yaml:
分配 resource 配額到 namespace：
實(shí)施網(wǎng)絡(luò)分割在同一個(gè) Kubernetes 集群上運(yùn)行不同的程序會(huì)有風(fēng)險(xiǎn)，就是應(yīng)用程序可能會(huì)受到損壞，然后攻擊相鄰的程序。容器只能夠跟確認(rèn)的容器進(jìn)行交流，所以網(wǎng)絡(luò)分割顯得很重要。
Kubernetes 部署面臨的一個(gè)挑戰(zhàn)就是，在 pod，service 和容器間創(chuàng)建分割。這個(gè)挑戰(zhàn)的原因就是容器網(wǎng)絡(luò)身份（IPs）的動(dòng)態(tài)特性，當(dāng)然，容器既可以在同一個(gè)節(jié)點(diǎn)中交流，也可以在不同節(jié)點(diǎn)間交流。
谷歌云平臺的用戶能夠從自動(dòng)防火墻規(guī)則中受益，避免跨集群交流?？梢允褂镁W(wǎng)絡(luò)防火墻或者 SDN 解決方法在內(nèi)部部署相似的實(shí)施。Kubernetes 的 Network SIG（興趣組）在這方面的做了一些工作，很大程度上提升了 pod 之間的交流的策略。新的網(wǎng)絡(luò)策略 API 應(yīng)該在 pods 周圍處理創(chuàng)建防火墻規(guī)則，限制容器化的網(wǎng)絡(luò)訪問。
以下的例子就是，為“backend”pods 控制網(wǎng)絡(luò)的網(wǎng)絡(luò)策略，只允許本地網(wǎng)絡(luò)訪問“frontend”pods：
為你的 pods 和容器申請安全環(huán)境當(dāng)設(shè)計(jì)你的容器和 pods 的時(shí)候，需要確認(rèn)給你的 pods，容器和數(shù)據(jù)卷配置了SecurityGroup。SecurityGroup 可以在 yaml 文件中定義。它控制分配到 pod/container/volume 的安全參數(shù)。一些重要的參數(shù)如下圖所示：
下圖是 pod 定義的一個(gè)例子：
如果允許有提升權(quán)限（--privilege）的容器，你應(yīng)該考慮使用“DenyEscalatingExec”這個(gè) Admission Controller。這個(gè) Controller 拒絕在 Pod 上運(yùn)行 exec 和 attach 命令，并且在提升 Pod 的權(quán)限時(shí)，只允許該 Pod 在宿主機(jī)上訪問。包括那些以特權(quán)模式運(yùn)行的 Pod，能夠訪問主機(jī) IPC namespace 的 Pod，以及能夠訪問主機(jī) PID namespace 的 Pod。
日志記錄Kubernetes 提供基于集群的日志，支持把日志推送到一個(gè)中心化的 log hub。創(chuàng)建完集群的時(shí)候，使用 Fluentd 代理來收集每個(gè)容器的標(biāo)準(zhǔn)輸出，標(biāo)準(zhǔn)錯(cuò)誤輸出。
當(dāng)集群創(chuàng)建成功以后，每個(gè)容器產(chǎn)生的日志（標(biāo)準(zhǔn)輸出和標(biāo)準(zhǔn)錯(cuò)誤輸出）就可以被每個(gè)節(jié)點(diǎn)上的 Fluent Agent 采集，然后推送到 GoogleStackDriver Logging 或者 Elasticsearch，然后用戶可以用 Kibana 來看這些日志。
Kubernetes 提供很多選擇來創(chuàng)建安全部署。但是并不存在一個(gè)對策解決所有問題這樣的好事，所以需要對這些選項(xiàng)有一定的熟悉，同樣，也要理解他們是如何提高你的程序的安全性的。
我們推薦實(shí)施本文中強(qiáng)調(diào)的最佳實(shí)踐，并且使用 Kubernetes 中靈活的配置功能將安全加工到連續(xù)的整合管道，將整個(gè)進(jìn)程用無縫安全進(jìn)行自動(dòng)化。
原文鏈接
轉(zhuǎn)載請聯(lián)系我們 －3-
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://specialneedsforspecialkids.com/yun/32493.html
摘要：京東云集群最佳實(shí)踐容器是的基石，它們之間的關(guān)系不言而喻。因此我們今天的文章將會(huì)和大家分享關(guān)于京東云集群的部分最佳實(shí)踐。京東云集群采用管理節(jié)點(diǎn)全托管的方式，為用戶提供簡單易用高可靠功能強(qiáng)大的容器管理服務(wù)。 京東云Kubernetes集群最佳實(shí)踐 容器是Cloud Native的基石，它們之間的關(guān)系不言而喻。了解容器對于學(xué)習(xí)Cloud Native也是十分重要的。近期，京東云Cloud N...
摘要：京東云集群最佳實(shí)踐容器是的基石，它們之間的關(guān)系不言而喻。因此我們今天的文章將會(huì)和大家分享關(guān)于京東云集群的部分最佳實(shí)踐。京東云集群采用管理節(jié)點(diǎn)全托管的方式，為用戶提供簡單易用高可靠功能強(qiáng)大的容器管理服務(wù)。 京東云Kubernetes集群最佳實(shí)踐 容器是Cloud Native的基石，它們之間的關(guān)系不言而喻。了解容器對于學(xué)習(xí)Cloud Native也是十分重要的。近期，京東云Cloud N...
摘要：擴(kuò)展性好當(dāng)集群的資源嚴(yán)重不足而導(dǎo)致排隊(duì)等待時(shí)，可以很容易的添加一個(gè)到集群中，從而實(shí)現(xiàn)擴(kuò)展。用法，選擇盡可能使用這個(gè)節(jié)點(diǎn)鏡像，填寫，這個(gè)容器鏡像是我們的運(yùn)行環(huán)境。更新文件，這里我們只是將中的鏡像更換成最新構(gòu)建出的鏡像?；贘enkins的CI/CD實(shí)踐[TOC]一、概要提到K8S環(huán)境下的CI/CD，可以使用的工具有很多，比如Jenkins、Gitlab CI、新興的drone等，考慮到大多公司...
摘要：我們通過阿里云容器服務(wù)控制臺創(chuàng)建一個(gè)集群，這里以創(chuàng)建臺節(jié)點(diǎn)集群為例。全方位監(jiān)控集群接入層的監(jiān)控是必不可少的，您可以通過阿里云容器服務(wù)監(jiān)控以及阿里云云監(jiān)控對和進(jìn)行全方位監(jiān)控。 摘要： 在Kubernetes集群中，Ingress作為集群流量接入層，Ingress的高可靠性顯得尤為重要，今天我們主要探討如何部署一套高性能高可靠的Ingress接入層。 簡介 在Kubernetes集群中，I...
摘要：集成測試完成后，由運(yùn)維同學(xué)從發(fā)起一個(gè)到分支，此時(shí)會(huì)會(huì)運(yùn)行單元測試，構(gòu)建鏡像，并發(fā)布到預(yù)發(fā)布環(huán)境測試人員在預(yù)發(fā)布環(huán)境下再次驗(yàn)證功能，團(tuán)隊(duì)做上線前的其他準(zhǔn)備工作運(yùn)維同學(xué)合并，將為本次發(fā)布的代碼及鏡像自動(dòng)打上版本號并書寫，同時(shí)發(fā)布到生產(chǎn)環(huán)境。 云原生 (Cloud Native) 是伴隨的容器技術(shù)發(fā)展出現(xiàn)的的一個(gè)詞，最早出自 Pivotal 公司（即開發(fā)了 Spring 的公司）的一本技術(shù)小...
閱讀 731·2023-04-25 19:28
閱讀 1391·2021-09-10 10:51
閱讀 2390·2019-08-30 15:55
閱讀 3408·2019-08-26 13:55
閱讀 2996·2019-08-26 13:24
閱讀 3325·2019-08-26 11:46
閱讀 2751·2019-08-23 17:10
閱讀 1415·2019-08-23 16:57
