部署一個安全的kubernetes應用建議有哪些

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

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

確保鏡像沒有漏洞

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

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

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

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

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

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

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

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

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

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

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

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

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

例如，以下策略允許“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)建資源配額策略并關(guān)聯(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

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

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

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

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

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

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

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

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和容器使用安全上下文

在設(shè)計容器和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

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

每個地方都記錄日志

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

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