[[343704]]

【51CTO.com快譯】為復雜環境部署基礎架構并非易事。這需要一致性和標準，以便基礎架構可靠、可擴展。基礎架構即代碼(IaC)是簡化這個過程的一種方法。

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

但是IaC帶來強大功能的同時帶來了重大的責任，因為涉及很多風險。本文概述了IaC模板中五個最常見的風險以及如何化解風險。

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

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

在典型情況下，當基礎架構計劃創建、提交進行部署時，我們以AWS Secrets Manager或Vault為例來獲取那些值。這可以借助適當的訪問控制和審核，更安全地處理秘密信息。

2. 將狀態文件提交到版本控件中

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

共享和重用狀態文件的最佳方法是在遠程狀態位置(通常是遠程存儲服務，比如AWS的S3)共享狀態文件，并實施了適當的權限機制。

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

在使用模板或狀態計劃之前，您可以選擇針對當前基礎架構部署來進行驗證。這將有助于發現任何語法錯誤;但最重要的是，有助于發現在此過程中可能添加的任何意想不到的破壞性變更。

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

第一步是在部署后編寫驗收測試以驗證常見的安全假設(請參閱TaskCat和Terratest)。此外，應該有一個自動化系統(比如Prisma Cloud)，它可以對環境進行定期檢查，以發現任何偏差，并上報安全問題。

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

如果舊的或來歷不明的圖像和實例有漏洞，使用這類圖像和實例可能會帶來安全風險。如果您使用來自第三方的IaC插件(比如，使用Terraform時通常會出現這種情況)，會發生同樣的問題。就因為是開源公開的，并不意味著它們是可信任的可靠的。實際上，除非建立了全面的安全檢查，否則它們會帶來很大的安全風險，因為它們可能會在運行時泄漏數據或執行不安全的部署。

在實際使用之前，應對圖像或插件的功能進行一番認真的同行審查和評估。

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

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

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

結束語

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

應及早制定一些組織政策。只有這樣，我們才能確保避免一大堆的錯誤以及任由未經檢查的代碼進入生產環境的風險。遵循良好的工程實踐并密切關注始終有助于從源頭避免這些風險。

原文標題：5 Common Risks in Infrastructure-as-Code Templates，作者：Theo Despoudis

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