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

Yaml定義K8s配置

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



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

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

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

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

最后，第三層也是最深層的驗(yàn)證是安全驗(yàn)證，以確保所定義的Kubernetes應(yīng)用程序不存在任何漏洞。我們可能已經(jīng)成功地編寫了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è)知識，我們將簡要介紹如何使用Kubernetes領(lǐng)域?qū)＜议_發(fā)的工具輕松處理它們。

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

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

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

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

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

從DevOps到DevSecOps

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

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

總結(jié)

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

審核編輯：劉清