Mateo Burillo認爲，安全需要適應容器/Kubernetes世界中日益快速的持續交付，這意味着安全性即代碼。在RebelCon.io 2019大會上，他展示瞭如何實現具備持續安全性的DevSecOps流程。
人類無法相當好地審查每天的多個構建；我們需要一個安全團隊，能夠考慮安全要求、限制和最佳實踐，並使用本身瞭解微服務的工具將它們自動化。要充分利用DevOps的靈活性和響應能力，安全性必須在應用程序的整個週期中發揮綜合作用。Burillo說，應該將安全性集成到管道中，使用安全性即代碼方法。
Burillo提到了將安全性實現爲代碼的好處：
第一個也是最重要的是自動化：你需要擴展並加速建立你的安全流程，以適應微服務/容器的世界。
可見性：任何團隊成員都可以訪問和討論安全規則，消除專有技術豎井。
可跟蹤性：現在，你對所做的每個更改都擁有版本控制和所有權。
Burillo說，容器是黑盒子，這對運營有利，但對安全不利。可能需要幾天或幾周的時間才能發現漏洞。這就像CSI一樣，但是沒有屍體，因爲容器很可能在漏洞出現後就不見了。
在構建時，要將安全性構建到產品中，最明顯的步驟是將CI/CD工具與鏡像掃描器集成在一起。Burillo說，人們經常將容器鏡像掃描與公共漏洞列表（稱爲CVE列表或“漏洞”）以及漏洞掃描關聯在一起，但這只是開始。使用高級鏡像掃描器，你可以做很多事情：遵從性檢查（NIST、PCI、MITRE）、發現泄漏的憑證、實現你自己的應用程序級安全實踐……
Burillo提出，Kubernetes提供了一些特定於容器的安全遵從性標準和一組很好的開箱即用的安全功能，因此要避免重複發明輪子。
現在最常見的用例是將鏡像掃描軟件與你的CI/CD管道集成在一起，無論是Jenkins、AWS CI/CD、Bamboo還是其他任何東西。Burillo提到了另一個用例，這個用例可能更具創新性，但並非沒有必要：對運行時容器進行常規鏡像檢查。他提出了疑問，如果在CI/CD聲明鏡像“乾淨”後發現一個新的零天漏洞，或者如果容器受到攻擊，修改了原始條件，會發生什麼情況？
Burillo提到，鏡像掃描是必要的，但還不夠；你還需要運行時安全性。傳統的Linux安全工具不提供容器運行時可見性；他建議對這套工具進行現代化改造。
在Sysdig技術作家Mateo Burillo結束了他在RebelCon.io 2019大會上的演講後，InfoQ與他進行了交談。
InfoQ：我們可以做些什麼來爲安全領域帶來敏捷性？
Mateo Burillo：我認爲，要採用的主要概念與IT基礎設施或QA所經歷的變革沒有太大區別：將安全性實現爲代碼。
安全性即代碼意味着你的規則需要進行版本控制並保存在存儲庫中。你的安全運維團隊將向該存儲庫推送，你的環境應該能夠動態地拉取並執行這些規則。
讓我用一個例子來幫助闡明這個概念。
例如，使用Anchore實現鏡像掃描，你的容器鏡像將始終被掃描以檢測CVE。然後，你的安全團隊決定你不希望任何容器以root身份運行或泄漏AWS憑據。
- 安全團隊修改*掃描策略*並將新版本推送到內部存儲庫。
- 編寫Anchore引擎腳本，用於檢測、下載和應用此更新。
- 你的CI/CD工具，比方說Jenkins，負責構建鏡像。它可以很容易地*與Anchore集成*，構建管道的其中一個步驟會運行這個鏡像掃描驗證。只有獲得Anchore批准的鏡像纔會被Jenkins簽名並推送到內部註冊中心。
- 使用Admission Controller配置Kubernetes，以拒絕運行任何CI/CD工具沒有簽名的鏡像。
在上面的例子中，安全團隊只需要設計高層次的安全目標；其他一切都是自動化的。
InfoQ：我們可以做些什麼來確保在容器中運行的應用程序以一種安全的方式運行？
Burillo：要知道，IT不存在100%的安全性保證，我們可以做幾件事來儘可能接近100%：
- 鏡像掃描，以檢測已知的漏洞，並遵循與你的IT部門和你部署的應用程序類型更相關的最佳安全實踐，例如：
- 你知道你的應用程序只需要從外部卷裝載/web/html；Dockerfile中的任何其他文件系統操作都應該發出警告；
- 你有與GLPv3不兼容的許可；任何聲明需要該許可的軟件包都要報告。
- 根據容器特定的安全遵從性框架驗證容器。不重複發明輪子是安全的黃金法則之一，這就是爲什麼我們有標準，舉幾個例子：
- NIST SP 800-190應用程序容器安全指南；
- 互聯網安全中心（CIS） Kubernetes基準測試；
- 支付卡行業數據安全標準或PCI DSS。
- 你需要深入的可見性和可跟蹤性，以瞭解容器是如何構建的，以及它們在運行時是如何操作的。你無法阻止你看不到的安全威脅；
- 實現運行時安全規則和自動修復。容器是簡單的機器，這在運行時是一個巨大的優勢，因爲你可以很容易地預測它們的行爲，並立即檢測是否有可疑的事情發生。讓我們使用該特性來提高IT安全性。
InfoQ：Kubernetes有哪些安全特性，你有什麼使用建議？
Burillo：特性真的有很多，最好的（最差的？）的方面是這個名單在不斷增長：RBAC、准入webhook,、pod安全策略、網絡策略、自動證書輪換、資源配額……
我的建議是像統計學家一樣思考。這有一個超速駕駛的危險，只是儘可能地實現你能想到的規則。從過去的攻擊、開發者的經驗、生態系統中臭名昭著的安全漏洞、面向安全的Kubernetes通訊和博客中收集數據。然後思考：下一個將最大化安全性並最小化我需要引入的複雜性的安全性規則是什麼？
有一個很好的例子，我們將一個脆弱的Kubernetes集羣作爲一個蜜罐暴露在互聯網上。該集羣是故意留有缺陷的，但是攻擊、攻擊檢測和取證是真實的。這些安全漏洞演練將幫助你識別和阻止你的生態系統中的實際攻擊活動。記住，它們總是在變異和適應；安全是一場軍備競賽。
InfoQ：我們如何檢測在容器中運行的軟件的異常？
Burillo：正如我前面提到的，容器的主要優點是它們本質上是“簡單的”，所以你可以輕鬆地找出規則來確定在運行期間允許什麼和禁止什麼。然而，主要的障礙是，在容器出現之前存在的大多數安全軟件都完全無視運行時容器操作——你可以分析輸入和輸出的內容，但除此之外，它只是一個黑盒。
我們一直推薦使用Falco進行運行時異常檢測；它的設計從一開始就考慮了容器，得益於它的內核級檢測，你可以獲得全面的可見性和可跟蹤性。最後同樣重要的是，它是完全開源的，並且是一個CNCF沙箱項目。你可以立即開始嘗試，甚至將你的容器安全規則貢獻給社區:)。
原文鏈接：
Implementing Continuous Security for Microservices and Kubernetes