本篇內(nèi)容主要講解“部署一個安全的kubernetes應用建議有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“部署一個安全的kubernetes應用建議有哪些”吧!

在陽曲等地區(qū)，都構建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務理念，為客戶提供網(wǎng)站制作、做網(wǎng)站 網(wǎng)站設計制作定制設計,公司網(wǎng)站建設,企業(yè)網(wǎng)站建設,高端網(wǎng)站設計,網(wǎng)絡營銷推廣,外貿(mào)網(wǎng)站建設,陽曲網(wǎng)站建設費用合理。

kubernetes提供了許多能有效提升你的應用安全性的規(guī)則。配置這些規(guī)則需要你精通kubernetes，并且明確部署的安全需求。此處我們強調(diào)的最佳實踐指的是容器的生命周期管理：構建，打包和運行，并且特指kubernetes的部署。

確保鏡像沒有漏洞

用有漏洞的鏡像來跑容器會使你的環(huán)境面臨更容易被攻破的風險。確保你的所有軟件都沒有已知漏洞，就能減少很多攻擊。

• 進行持續(xù)的安全漏洞掃描——容器可能包含那些過期的攜帶已知漏洞的包。漏洞掃描不能只是個一次性過程，因為新的漏洞每天都在發(fā)布。一個持續(xù)評估鏡像安全性的過程，對確保一個必要的安全態(tài)勢是至關重要的。

• 定期對環(huán)境進行安全更新——一旦運行中的容器發(fā)現(xiàn)了漏洞，你必須更新源鏡像并重新部署容器。盡量避免直接更新運行中的容器（如使用 apt-update），因為這會破壞鏡像和容器的關系。使用 kubernetes 的 rolling update 特性來升級容器是相當簡單的，它允許逐步更新運行中的應用，通過更新鏡像到最新版本。

確保環(huán)境中只使用授權的鏡像

如果不能確保只允許附帶組織策略的鏡像運行，那么該組織將冒著運行有漏洞甚至是惡意容器的風險。從未知源下載并運行鏡像是危險的。這相當于在生產(chǎn)環(huán)境服務器上運行未知供應商提供的軟件。千萬不要這么做。

使用私有倉庫來存儲你的認證過的鏡像，并確保只上傳認證過的鏡像到這些私有倉庫。單單這條就已經(jīng)縮小范圍了，它從成千上萬的公開可用的鏡像中減少到只剩一部分潛在的鏡像可以進入到你的流水線。構建一條 CI 流水線來集成安全評估（比如漏洞掃描），使它成為構建過程的一部分。

CI 流水線必須確保只有評審過的代碼（允許上生產(chǎn)環(huán)境）才能用來構建鏡像。一旦鏡像構建好，它必須掃描安全漏洞，并且只有當沒發(fā)現(xiàn)問題時，這個鏡像才能被上傳到私有倉庫，從該倉庫中部署到生產(chǎn)環(huán)境就完成了。安全評估中的失敗應該在流水線中創(chuàng)建一個失敗，從而阻止差的安全質(zhì)量的鏡像上傳到鏡像倉庫。

Kubernetes 的鏡像認證插件正在完工中（期望在 Kubernetes 1.4 中完工），它將允許阻止未認證的鏡像打包。
 

限制對 Kubernetes 節(jié)點的直接訪問。

你應該限制對 kubernetes 節(jié)點的 SSH 訪問，減少主機資源未認證就被訪問的風險。相應的，你應該要求用戶使用 kubectl exex 命令來訪問，它將提供對容器環(huán)境的直接訪問，而不涉及對主機的訪問。

你可以使用 Kubernetes 的授權插件來進一步控制用戶的資源訪問權限。它允許對特定的命名空間，容器和操作定義細粒度訪問的控制規(guī)則。

資源之間創(chuàng)建管理邊界

限制用戶權限的范圍可以減少誤操作或者惡意操作的影響。kubernetes 的命令空間允許你將已創(chuàng)建的資源劃分成邏輯命名組。一個命名空間內(nèi)創(chuàng)建的資源可以和其它命名空間隔離開。默認情況下，用戶在Kubernetes集群中創(chuàng)建的每個資源都在default命名空間下。你可以創(chuàng)建額外的命名空間并將資源和用戶掛到該空間下。你可以通過kubernetes的授權插件（Authorization plugins）創(chuàng)建策略，隔離不同用戶對空間下的資源的訪問權限。

例如，以下策略允許“alice”讀取命名空間“fronto”下的 pods。

{   "apiVersion": "abac.authorization.kubernetes.io/v1beta1",   "kind": "Policy",   "spec": {       "user": "alice",       "namespace": "fronto",       "resource": "pods",       "readonly": true   } }

定義資源配額

運行資源不受限的容器會使你的系統(tǒng)面臨DoS或者“吵鬧的鄰居（noisy neighbor）”的風險。為了阻止或者最小化這些風險，你應該定義資源配額。默認情況下，kubernetes集群中創(chuàng)建的所有資源都不限制CPU和內(nèi)存。你可以創(chuàng)建資源配額策略并關聯(lián)到命名空間下，以限制pod對CPU和內(nèi)存的消耗。

以下是命名空間下資源配額定義的例子，它限制了該命令空間下，pod數(shù)量為4，總的CPU使用為1到2個，總的內(nèi)存為1到2G。

compute-resources.yaml:

apiVersion: v1 kind: ResourceQuota metadata:   name: compute-resources spec:   hard:     pods: "4"     requests.cpu: "1"     requests.memory: 1Gi     limits.cpu: "2"     limits.memory: 2Gi

將資源配額關聯(lián)到命名空間方法如下：

kubectl create -f ./compute-resources.yaml --namespace=myspace

實現(xiàn)網(wǎng)絡分割

不同的應用都運行在同一個kubernetes集群中，會面臨一個缺乏抵抗力的應用攻擊它的鄰居應用的風險。網(wǎng)絡分割對確保容器只能和那些它們允許訪問的容器交流來說就很重要。

kubernetes部署中的其中一個挑戰(zhàn)就是在pod，服務和容器間創(chuàng)建網(wǎng)絡分割。說它是挑戰(zhàn)，是因為容器網(wǎng)絡標識（IPs）的“動態(tài)”本質(zhì)，以及另一個事實，即容器可以在同一節(jié)點和不同節(jié)點間通信。

谷歌云平臺的用戶受益于平臺的自動防火墻規(guī)則，可以阻止跨集群的通信。使用網(wǎng)絡防火墻或者SDN方案，我們也可以在本地部署一個相似的實現(xiàn)。kubernetes的網(wǎng)絡SIG正在該領域做相關工作，它能明顯改善pod和pod間通信的策略。一個新的網(wǎng)絡策略API應該滿足用戶的需求，在pod間創(chuàng)建防火墻規(guī)則，以限制容器間的網(wǎng)絡訪問。

以下是個網(wǎng)絡策略的例子，它控制"backend"pod的網(wǎng)絡，只允許“frontend”pod 的網(wǎng)絡訪問。
 

POST /apis/net.alpha.kubernetes.io/v1alpha1/namespaces/tenant-a/networkpolicys { "kind": "NetworkPolicy", "metadata": { "name": "pol1" }, "spec": { "allowIncoming": {  "from": [{    "pods": { "segment": "frontend" }  }],  "toPorts": [{    "port": 80,    "protocol": "TCP"  }] }, "podSelector": {  "segment": "backend" } } }

給pod和容器使用安全上下文

在設計容器和pod的時候，請確保為你的pod，容器和volumes配置了安全的上下文。一個安全的上下文是部署yaml中定義的一個屬性。它控制了將賦給pod/容器/volume的安全參數(shù)。某些重要參數(shù)如下：
 

Security Context Setting                                  Description SecurityContext->runAsNonRoot                    Indicates that containers should run as non-root user SecurityContext->Capabilities                         Controls the Linux capabilities assigned to the container. SecurityContext->readOnlyRootFilesystem    Controls whether a container will be able to write into the root filesystem. PodSecurityContext->runAsNonRoot             Prevents running a container with ‘root’ user as part of the pod

以下是一個帶安全上下文參數(shù)的pod定義例子：

apiVersion: v1 kind: Pod metadata: name: hello-world spec: containers: # specification of the pod’s containers # ... securityContext: readOnlyRootFilesystem: true runAsNonRoot: true

當你要用提升的權限（--privileged）來運行容器的時候，你應該考慮使用“DenyEscalatingExec”接入控制。這個控制拒絕 exec 和 attach 命令發(fā)到 pod ，那些pod用提升權限在運行，允許主機訪問。這些pod包括以特權運行的，對主機IPC命名空間有訪問權限的，以及對主機PID命名空間有訪問權限的。

每個地方都記錄日志

kubernetes提供基于集群的日志，允許記錄容器活動到一個中央日志倉庫。當一個集群創(chuàng)建的時候，每個容器的標準輸出和標準錯誤輸出都可以通過一個運行在每個節(jié)點上的Fluentd代理獲取到，這些輸出被輸入到谷歌Stackdriver日志系統(tǒng)或者Elasticsearch，并通過Kibana來查看。

到此，相信大家對“部署一個安全的kubernetes應用建議有哪些”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關內(nèi)容可以進入相關頻道進行查詢，關注我們，繼續(xù)學習！

分享題目：部署一個安全的kubernetes應用建議有哪些
轉(zhuǎn)載來源：http://jinyejixie.com/article46/peoceg.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供標簽優(yōu)化、網(wǎng)頁設計公司、ChatGPT、用戶體驗、小程序開發(fā)、網(wǎng)站內(nèi)鏈

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)