[[343704]]

【51CTO.com快譯】為復(fù)雜環(huán)境部署基礎(chǔ)架構(gòu)并非易事。這需要一致性和標(biāo)準(zhǔn)，以便基礎(chǔ)架構(gòu)可靠、可擴(kuò)展?；A(chǔ)架構(gòu)即代碼(IaC)是簡化這個過程的一種方法。

Terraform和CloudFormation之類的IaC工具允許開發(fā)者編寫描述應(yīng)如何配置基礎(chǔ)架構(gòu)的代碼，然后自動配置基礎(chǔ)架構(gòu)以滿足定義，為原本繁瑣又費(fèi)時的過程大大提高了自動化程度——萬一管理員在配置系統(tǒng)時犯了錯誤，這個過程還很容易出現(xiàn)人為錯誤。

但是IaC帶來強(qiáng)大功能的同時帶來了重大的責(zé)任，因?yàn)樯婕昂芏囡L(fēng)險(xiǎn)。本文概述了IaC模板中五個最常見的風(fēng)險(xiǎn)以及如何化解風(fēng)險(xiǎn)。

1. 硬編碼秘密或資源引用

如果信息太敏感、不可查看，或隨著時間而變化(比如密鑰、代碼、IP地址、域名、別名或帳戶名)，應(yīng)為其分配具有適當(dāng)名稱的變量。作為一條經(jīng)驗(yàn)法則，出于安全目的，不應(yīng)將此類信息硬編碼到版本控制中。這也很不方便，因?yàn)槿绻覀冚啌Q一些密鑰或秘密信息，就需要新的提交和審查階段：如果部署不當(dāng)，這個階段可能會被阻止或拖延數(shù)小時乃至數(shù)天。而是應(yīng)將所有此類數(shù)據(jù)存儲在專門的服務(wù)中，根據(jù)需要注入所需的秘密信息或上下文變量。

在典型情況下，當(dāng)基礎(chǔ)架構(gòu)計(jì)劃創(chuàng)建、提交進(jìn)行部署時，我們以AWS Secrets Manager或Vault為例來獲取那些值。這可以借助適當(dāng)?shù)脑L問控制和審核，更安全地處理秘密信息。

2. 將狀態(tài)文件提交到版本控件中

對于Terraform的用戶而言，狀態(tài)文件是啟動IaC計(jì)劃時創(chuàng)建的項(xiàng)目。它們含有用于特定基礎(chǔ)架構(gòu)的實(shí)用的元數(shù)據(jù)和配置選項(xiàng)。將敏感值存儲在狀態(tài)文件中，并提交到版本控制中的可能性比較大，這可以理解。別人試圖從版本控制中檢出代碼時，這會帶來其他問題。狀態(tài)文件會過時或不完整。他們可能最終部署難以安全回滾的錯誤或不安全的基礎(chǔ)架構(gòu)組件。

共享和重用狀態(tài)文件的最佳方法是在遠(yuǎn)程狀態(tài)位置(通常是遠(yuǎn)程存儲服務(wù)，比如AWS的S3)共享狀態(tài)文件，并實(shí)施了適當(dāng)?shù)臋?quán)限機(jī)制。

3.在部署前后未執(zhí)行健全性和安全性檢查

在使用模板或狀態(tài)計(jì)劃之前，您可以選擇針對當(dāng)前基礎(chǔ)架構(gòu)部署來進(jìn)行驗(yàn)證。這將有助于發(fā)現(xiàn)任何語法錯誤;但最重要的是，有助于發(fā)現(xiàn)在此過程中可能添加的任何意想不到的破壞性變更。

另外，部署完畢之后，應(yīng)該有另外的健全性和安全性檢查，以回答最常見的問題：部署的基礎(chǔ)架構(gòu)是否安全?部署是否留下了敞開的端口?部署是否沒有破壞未使用的資源?

第一步是在部署后編寫驗(yàn)收測試以驗(yàn)證常見的安全假設(shè)(請參閱TaskCat和Terratest)。此外，應(yīng)該有一個自動化系統(tǒng)(比如Prisma Cloud)，它可以對環(huán)境進(jìn)行定期檢查，以發(fā)現(xiàn)任何偏差，并上報(bào)安全問題。

4. 使用不受信任的圖像或插件

如果舊的或來歷不明的圖像和實(shí)例有漏洞，使用這類圖像和實(shí)例可能會帶來安全風(fēng)險(xiǎn)。如果您使用來自第三方的IaC插件(比如，使用Terraform時通常會出現(xiàn)這種情況)，會發(fā)生同樣的問題。就因?yàn)槭情_源公開的，并不意味著它們是可信任的可靠的。實(shí)際上，除非建立了全面的安全檢查，否則它們會帶來很大的安全風(fēng)險(xiǎn)，因?yàn)樗鼈兛赡軙谶\(yùn)行時泄漏數(shù)據(jù)或執(zhí)行不安全的部署。

在實(shí)際使用之前，應(yīng)對圖像或插件的功能進(jìn)行一番認(rèn)真的同行審查和評估。

5. 不重用代碼并將所有內(nèi)容放在一個文件中

把所有配置和模板放在一個文件中會招惹災(zāi)難，這是由于它們可能不搭。增加配置數(shù)量可能導(dǎo)致大量重復(fù)代碼。這種代碼重復(fù)導(dǎo)致難以理解的模板，從而導(dǎo)致更多的配置漂移，最終可能出現(xiàn)在生產(chǎn)環(huán)境中。IaC模板應(yīng)按環(huán)境和邏輯邊界加以組織管理，比如生產(chǎn)環(huán)境、開發(fā)環(huán)境和模擬環(huán)境，它們有各自的數(shù)據(jù)庫、VPC、權(quán)限和IAM策略模板。

每次使用通用引用和共享模塊都有助于更有把握、更一致地部署基礎(chǔ)架構(gòu)資源。

結(jié)束語

您可以從上述場景中清楚地了解到IaC模板是源代碼，需要將其視為源代碼。這實(shí)際上意味著，將這些模板提交到版本控制系統(tǒng)中之前，應(yīng)該每次都對這些模板進(jìn)行多人審核、質(zhì)量評估、格式化和驗(yàn)證。

應(yīng)及早制定一些組織政策。只有這樣，我們才能確保避免一大堆的錯誤以及任由未經(jīng)檢查的代碼進(jìn)入生產(chǎn)環(huán)境的風(fēng)險(xiǎn)。遵循良好的工程實(shí)踐并密切關(guān)注始終有助于從源頭避免這些風(fēng)險(xiǎn)。

原文標(biāo)題：5 Common Risks in Infrastructure-as-Code Templates，作者：Theo Despoudis

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】