建站
咨詢
售后
建站咨詢
新聞中心
為復雜環(huán)境部署基礎架構并非易事。這需要一致性和標準，以便基礎架構可靠、可擴展?；A架構即代碼(IaC)是簡化這個過程的一種方法。
創(chuàng)新互聯(lián)公司堅持“要么做到，要么別承諾”的工作理念，服務領域包括：網(wǎng)站建設、網(wǎng)站設計、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務，滿足客戶于互聯(lián)網(wǎng)時代的廣東網(wǎng)站設計、移動媒體設計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡建設合作伙伴！
Terraform和CloudFormation之類的IaC工具允許開發(fā)者編寫描述應如何配置基礎架構的代碼，然后自動配置基礎架構以滿足定義，為原本繁瑣又費時的過程大大提高了自動化程度——萬一管理員在配置系統(tǒng)時犯了錯誤，這個過程還很容易出現(xiàn)人為錯誤。
但是IaC帶來強大功能的同時帶來了重大的責任，因為涉及很多風險。本文概述了IaC模板中五個最常見的風險以及如何化解風險。
1. 硬編碼秘密或資源引用
如果信息太敏感、不可查看，或隨著時間而變化(比如密鑰、代碼、IP地址、域名、別名或帳戶名)，應為其分配具有適當名稱的變量。作為一條經(jīng)驗法則，出于安全目的，不應將此類信息硬編碼到版本控制中。這也很不方便，因為如果我們輪換一些密鑰或秘密信息，就需要新的提交和審查階段：如果部署不當，這個階段可能會被阻止或拖延數(shù)小時乃至數(shù)天。而是應將所有此類數(shù)據(jù)存儲在專門的服務中，根據(jù)需要注入所需的秘密信息或上下文變量。
在典型情況下，當基礎架構計劃創(chuàng)建、提交進行部署時，我們以AWS Secrets Manager或Vault為例來獲取那些值。這可以借助適當?shù)脑L問控制和審核，更安全地處理秘密信息。
2. 將狀態(tài)文件提交到版本控件中
對于Terraform的用戶而言，狀態(tài)文件是啟動IaC計劃時創(chuàng)建的項目。它們含有用于特定基礎架構的實用的元數(shù)據(jù)和配置選項。將敏感值存儲在狀態(tài)文件中，并提交到版本控制中的可能性比較大，這可以理解。別人試圖從版本控制中檢出代碼時，這會帶來其他問題。狀態(tài)文件會過時或不完整。他們可能最終部署難以安全回滾的錯誤或不安全的基礎架構組件。
共享和重用狀態(tài)文件的最佳方法是在遠程狀態(tài)位置(通常是遠程存儲服務，比如AWS的S3)共享狀態(tài)文件，并實施了適當?shù)臋嘞迿C制。
3.在部署前后未執(zhí)行健全性和安全性檢查
在使用模板或狀態(tài)計劃之前，您可以選擇針對當前基礎架構部署來進行驗證。這將有助于發(fā)現(xiàn)任何語法錯誤;但最重要的是，有助于發(fā)現(xiàn)在此過程中可能添加的任何意想不到的破壞性變更。
另外，部署完畢之后，應該有另外的健全性和安全性檢查，以回答最常見的問題：部署的基礎架構是否安全?部署是否留下了敞開的端口?部署是否沒有破壞未使用的資源?
第一步是在部署后編寫驗收測試以驗證常見的安全假設(請參閱TaskCat和Terratest)。此外，應該有一個自動化系統(tǒng)(比如Prisma Cloud)，它可以對環(huán)境進行定期檢查，以發(fā)現(xiàn)任何偏差，并上報安全問題。
4. 使用不受信任的圖像或插件
如果舊的或來歷不明的圖像和實例有漏洞，使用這類圖像和實例可能會帶來安全風險。如果您使用來自第三方的IaC插件(比如，使用Terraform時通常會出現(xiàn)這種情況)，會發(fā)生同樣的問題。就因為是開源公開的，并不意味著它們是可信任的可靠的。實際上，除非建立了全面的安全檢查，否則它們會帶來很大的安全風險，因為它們可能會在運行時泄漏數(shù)據(jù)或執(zhí)行不安全的部署。
在實際使用之前，應對圖像或插件的功能進行一番認真的同行審查和評估。
5. 不重用代碼并將所有內容放在一個文件中
把所有配置和模板放在一個文件中會招惹災難，這是由于它們可能不搭。增加配置數(shù)量可能導致大量重復代碼。這種代碼重復導致難以理解的模板，從而導致更多的配置漂移，最終可能出現(xiàn)在生產環(huán)境中。IaC模板應按環(huán)境和邏輯邊界加以組織管理，比如生產環(huán)境、開發(fā)環(huán)境和模擬環(huán)境，它們有各自的數(shù)據(jù)庫、VPC、權限和IAM策略模板。
每次使用通用引用和共享模塊都有助于更有把握、更一致地部署基礎架構資源。
結束語
您可以從上述場景中清楚地了解到IaC模板是源代碼，需要將其視為源代碼。這實際上意味著，將這些模板提交到版本控制系統(tǒng)中之前，應該每次都對這些模板進行多人審核、質量評估、格式化和驗證。
應及早制定一些組織政策。只有這樣，我們才能確保避免一大堆的錯誤以及任由未經(jīng)檢查的代碼進入生產環(huán)境的風險。遵循良好的工程實踐并密切關注始終有助于從源頭避免這些風險。
文章名稱：基礎架構即代碼模板的五個常見風險
網(wǎng)頁URL：http://www.5511xx.com/article/coocijg.html
