Kubernetes已經(jīng)占據(jù)如何管理集容器化應(yīng)用程序的核心位置。因此，存在許多定義Kubernetes應(yīng)用程序的約定文件格式，包括YAML、JSON、INI等。 這使得我們需要考慮應(yīng)用程序的最佳策略是什么。此外，我們還必須考慮如何根據(jù)所選擇的文件結(jié)構(gòu)(特別是安全性)路徑來(lái)驗(yàn)證應(yīng)用程序配置。 本文，我們將探討使用YAML文件定義Kubernetes應(yīng)用程序，以及可以采取的各種步驟來(lái)有效地驗(yàn)證這些配置定義。

Yaml定義K8s配置

與JSON和INI相比，YAML更加緊湊和可讀。例如，如果我們要定義一個(gè)可以在端口80上可達(dá)的pod，那么YAML、JSON和INI中的配置將如下表所示。



很明顯，YAML簡(jiǎn)化了我們定義Kubernetes應(yīng)用程序的方式，特別是考慮到一個(gè)普通應(yīng)用程序可能涉及幾十個(gè)配置文件。此外，YAML的緊湊特性允許您將對(duì)象分組在一起，從而減少所需的文件數(shù)量。 然而，在定義Kubernetes配置文件時(shí)存在重大挑戰(zhàn)，特別是在嵌入manifest文件之間的約束和關(guān)系時(shí)。

例如，我們?nèi)绾未_保按照最佳實(shí)踐配置內(nèi)存限制? 在滿足邊界情況時(shí)，缺乏驗(yàn)證不僅會(huì)導(dǎo)致應(yīng)用程序出現(xiàn)意外行為，而且還會(huì)暴露出主要的安全漏洞。因此，我們有必要考慮基于yaml配置文件的驗(yàn)證策略，這就是我們將在下面幾節(jié)中深入研究的內(nèi)容。 驗(yàn)證內(nèi)容 應(yīng)該對(duì)YAML文件執(zhí)行三個(gè)級(jí)別的驗(yàn)證。這些級(jí)別確保根據(jù)YAML文件的實(shí)際有效性執(zhí)行驗(yàn)證，直到是否滿足安全實(shí)踐。

第一級(jí)別是結(jié)構(gòu)驗(yàn)證，這是在Kubernetes配置文件上執(zhí)行的基礎(chǔ)級(jí)別驗(yàn)證。它只需要驗(yàn)證YAML文件，以確保沒(méi)有語(yǔ)法錯(cuò)誤。這一點(diǎn)可以在編寫(xiě)配置文件時(shí)由IDE進(jìn)行驗(yàn)證。

第二層是語(yǔ)義驗(yàn)證。這確保YAML文件的內(nèi)容轉(zhuǎn)換為所需的Kubernetes資源，從而驗(yàn)證Kubernetes應(yīng)用程序本身。

最后，第三層也是最深層的驗(yàn)證是安全驗(yàn)證，以確保所定義的Kubernetes應(yīng)用程序不存在任何漏洞。我們可能已經(jīng)成功地編寫(xiě)了YAML配置，也成功地實(shí)現(xiàn)了所需的Kubernetes資源和連接，但這并不能確保我們的Kubernetes應(yīng)用程序是很安全的，并遵循最佳實(shí)踐。

最后兩個(gè)驗(yàn)證都是Kubernetes配置驗(yàn)證，而且不僅僅是在YAML格式驗(yàn)證方面。因?yàn)楹蛻?yīng)用程序相關(guān)，需要特殊驗(yàn)證。執(zhí)行這種驗(yàn)證需要Kubernetes領(lǐng)域的深入和專業(yè)知識(shí)，我們將簡(jiǎn)要介紹如何使用Kubernetes領(lǐng)域?qū)＜议_(kāi)發(fā)的工具輕松處理它們。

例如，鎖定hostPath掛載權(quán)限可以確保具有可寫(xiě)hostPath卷的集群中的容器不會(huì)被攻擊者訪問(wèn)，因?yàn)樗麄兛赡軙?huì)獲得底層主機(jī)上的持久性。這不符合安全最佳實(shí)踐，為了避免這個(gè)問(wèn)題，我們應(yīng)該始終確保hostPath屬性下的readOnly部分設(shè)置為true。 另一個(gè)例子是只在必要時(shí)才授予pods 主機(jī)網(wǎng)絡(luò)訪問(wèn)權(quán)。所有有權(quán)限的pod應(yīng)該被列入白名單。對(duì)主機(jī)網(wǎng)絡(luò)的不必要訪問(wèn)增加了潛在的攻擊范圍。

因此，從上面的兩個(gè)例子可以看出，即使我們的配置文件通過(guò)了結(jié)構(gòu)和語(yǔ)義驗(yàn)證，導(dǎo)致我們的Kubernetes資源被成功編排，安全和功能漏洞可能仍然存在。因此，我們必須考慮如何最好地捕獲這些漏洞，然后在生產(chǎn)環(huán)境中提醒存在對(duì)后果。安全驗(yàn)證是實(shí)現(xiàn)此目的的方法。

校驗(yàn)Yaml的最佳實(shí)踐

考慮到結(jié)構(gòu)驗(yàn)證相當(dāng)簡(jiǎn)單，通常編程使用的IDE就集成了該功能。Kubernetes語(yǔ)義和安全驗(yàn)證需要特殊處理，特別是在策略和工具方面。 我們考慮一些最佳實(shí)踐和策略，以實(shí)現(xiàn)YAML文件的全面驗(yàn)證。 您可以執(zhí)行一個(gè)試運(yùn)行(kubectl apply -f - -dry-run='server ")來(lái)驗(yàn)證語(yǔ)義結(jié)構(gòu)，但這仍然是一個(gè)額外的步驟，可能會(huì)降低總體速度。

但是，試運(yùn)行要求您能夠訪問(wèn)Kubernetes集群。 這種方法的另一種選擇是Kubeval，這是一個(gè)實(shí)用工具，可以用來(lái)驗(yàn)證配置文件語(yǔ)義，以確保它們滿足Kubernetes的對(duì)象定義需求。它可以是CI過(guò)程的一部分，并在本地執(zhí)行掃描，從而確保在投入生產(chǎn)環(huán)境之前從語(yǔ)義上驗(yàn)證配置文件。 還可以使用kuscape在CI中實(shí)現(xiàn)安全驗(yàn)證。這是一個(gè)開(kāi)源工具，確保您的Kubernetes應(yīng)用程序定義遵循多種安全框架，如NSA-CISA或MITRE ATT&CK。通過(guò)使用kuscape CLI，您可以掃描所有YAML文件的安全漏洞，甚至獲得風(fēng)險(xiǎn)評(píng)分和風(fēng)險(xiǎn)趨勢(shì)。它充當(dāng)YAML驗(yàn)證器，其主要價(jià)值是安全驗(yàn)證。

從DevOps到DevSecOps

你可以運(yùn)行CI流水線中已經(jīng)討論過(guò)的工具的組合，以實(shí)現(xiàn)結(jié)構(gòu)、語(yǔ)義和安全驗(yàn)證。然而，僅僅利用這些工具及其預(yù)定義的檢查是不夠的。 我們從DevOps中學(xué)到的一件事是，總是有一個(gè)可以采用的改進(jìn)循環(huán)。這就是為什么隨著應(yīng)用程序的發(fā)展和安全性需求的變化，你應(yīng)該不斷地檢查安全性控制。 新的安全控件應(yīng)該合并到安全驗(yàn)證步驟中。kuscape是AMRO開(kāi)發(fā)的開(kāi)源平臺(tái)，它允許你定義自己的控件框架。盡管開(kāi)箱即用的框架很健壯，但需要根據(jù)業(yè)務(wù)和Kubernetes資源的具體需求形成策略控制。

只有將安全檢驗(yàn)嵌入到構(gòu)建應(yīng)用程序中，才能實(shí)現(xiàn)這種最佳實(shí)踐。多虧了像Kubeval和kuscape這樣的開(kāi)源工具，開(kāi)發(fā)團(tuán)隊(duì)不斷考慮驗(yàn)證，特別是安全驗(yàn)證的障礙已經(jīng)降低了。

總結(jié)

YAML配置文件使得構(gòu)建Kubernetes應(yīng)用程序非常簡(jiǎn)單。然而，YAML在驗(yàn)證方面確實(shí)有其局限性。因此，我們有必要了解所有驗(yàn)證策略，以確保構(gòu)建的Kubernetes應(yīng)用程序是健康和安全的。 在任何IDE中使用YAML測(cè)試驗(yàn)證YAML文件的結(jié)構(gòu)都是相當(dāng)簡(jiǎn)單的，但是驗(yàn)證Kubernetes資源對(duì)象定義的正確性以及圍繞它們的安全措施是很困難的。幸運(yùn)的是，像kuscape這樣的工具彌補(bǔ)了這一差距，在整個(gè)應(yīng)用程序生命周期中不斷考慮安全性。 由于安全性是構(gòu)建容器應(yīng)用程序的主要關(guān)注點(diǎn)之一，這里討論的驗(yàn)證策略是朝著正確方向邁出的一步。

審核編輯：劉清