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

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

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

確保鏡像沒有漏洞

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

• 進(jìn)行持續(xù)的安全漏洞掃描——容器可能包含那些過期的攜帶已知漏洞的包。漏洞掃描不能只是個(gè)一次性過程，因?yàn)樾碌穆┒疵刻於荚诎l(fā)布。一個(gè)持續(xù)評(píng)估鏡像安全性的過程，對(duì)確保一個(gè)必要的安全態(tài)勢(shì)是至關(guān)重要的。

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

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

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

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

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

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

限制對(duì) Kubernetes 節(jié)點(diǎn)的直接訪問。

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

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

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

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

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

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

定義資源配額

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

以下是命名空間下資源配額定義的例子，它限制了該命令空間下，pod數(shù)量為4，總的CPU使用為1到2個(gè)，總的內(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

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

不同的應(yīng)用都運(yùn)行在同一個(gè)kubernetes集群中，會(huì)面臨一個(gè)缺乏抵抗力的應(yīng)用攻擊它的鄰居應(yīng)用的風(fēng)險(xiǎn)。網(wǎng)絡(luò)分割對(duì)確保容器只能和那些它們?cè)试S訪問的容器交流來說就很重要。

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

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

以下是個(gè)網(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è)計(jì)容器和pod的時(shí)候，請(qǐng)確保為你的pod，容器和volumes配置了安全的上下文。一個(gè)安全的上下文是部署yaml中定義的一個(gè)屬性。它控制了將賦給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

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

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

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

每個(gè)地方都記錄日志

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

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