Mindblown: a blog about philosophy.

  • Linux Professional Institute LPIC-1

    全球最大、最受認可的 Linux 認證 LPIC-1 是 Linux Professional Institute (LPI) 多層 Linux 專業認證計畫中的第一個認證。 LPIC-1 將驗證候選人在命令列上執行維護任務、安裝和配置運行 Linux 的電腦以及配置基本網路的能力。 LPIC-1 旨在反映目前研究並驗證候選人在現實世界系統管理方面的熟練程度。 這些目標與現實世界的工作技能相關,這是我們在考試開發過程中透過工作任務分析調查確定的。 目前版本:5.0(考試代碼 101-500 和 102-500) 目標:101-500、102-500 先決條件:此認證沒有任何先決條件。 要求:通過101和102考試。 每場考試時間為 90 分鐘,包括 60 道選擇題和填空題。 有效期限:5年,除非重考或達到更高水準。 費用:按此處了解您所在國家/地區的考試定價。 VUE 考試中心提供的考試語言:英文、德文、日文、葡萄牙文(巴西)、中文(簡體)、中文(繁體)、西班牙文(現代) 透過 OnVUE 線上提供考試語言:英語、德語、日語、葡萄牙語(巴西)、西班牙語 要獲得 LPIC-1 認證,候選人必須能夠: 了解Linux系統的架構; 安裝和維護 Linux 工作站,包括 X11 並將其設定為網路用戶端; 在Linux命令列上工作,包括常見的GNU和Unix命令; 處理文件和存取權限以及系統安全; 和 執行簡單的維護任務:幫助使用者、將使用者新增至更大的系統、備份和復原、關機和重新啟動。

  • 2024年的AI風險管理:您應該知道的幾件事

    Shanika Splunk大数据 生成式AI技術(如GPT-3 和 DALL·E)的不斷進步,帶動了AI技術在全球的快速採用。 對許多企業來說,應用AI技術的目的是在市場競爭中獲得優勢,但有時他們忽略了AI帶來的風險因素,而這些風險很有可能會影響到個人、組織以及更廣泛的生態系統。 我們將透過本文向您介紹AI風險管理這一概念。 我們將帶您了解與AI系統相關的技術性風險和非技術性風險。 同時,我們也將向您展示如何借助美國國家標準與技術研究院(NIST)制定的《人工智慧風險管理框架》來開發AI風險管理方案,創建負責任的AI系統。 在文章的最後,我們將討論組織在管理AI風險方面將不得不面對的主要挑戰。 什麼是AI風險管理 對AI技術越來越多的應用,將為組織帶來許多技術性風險和非技術性風險。 作為風險管理領域的分支學科,AI風險管理主要聚焦於組織在部署和應用人工智慧技術流程中對風險進行的識別、評估和管理等工作。 這個過程包括制定策略來應對這些風險,確保對AI系統的使用是負責任的,保護組織、客戶、員工免受AI專案的負面影響。 為了實現更有效率的風險管理,人們引入了多個AI風險管理框架,例如,美國國家標準與技術研究院(NIST)制定的《人工智慧風險管理框架》, 可透過結構化的方法來評估和消除 AI風險,其中包括AI使用指南和AI最佳實踐。 與AI相關的風險 談到AI風險管理,最重要的是要清楚AI使用過程中的技術性風險和非技術性風險。 01.技術性風險 以下即為常見的AI技術性風險: 資料隱私風險。 AI模型,特別是經過大型資料集訓練的模型,可能會含有敏感的個人訊息,如個人識別資訊 (Personally Identifiable Information, PII)。 這些系統可能會在不經意間記住並顯示這些敏感信息,導致個人隱私洩露,違反資料保護條例(如GDPR)的合規要求。 AI模型的偏見。 有時候,用來訓練AI模型的資料可能會帶有偏見,導致AI模型產生不準確且帶有一定歧視色彩的結果。 舉例如下: 在招募事件中存在偏見,導致只僱用特定人選(或特定族群) 在金融借貸領域的偏見,會導致只面向特定族群開放 結果不準確。 如果接受訓練的AI模型精準度較低,那麼產生的結果準確度也會比較低。 甚至有些模型無法提供及時的訊息,導致公司或員工做出錯誤決策。 過擬合。 當AI模型過度使用訓練資料時,就會發生這樣的現象。 一旦使用新數據,則其效能降低。 這種現象會影響結果的可靠性和準確性。 02.非技術性風險 現在我們來看看AI技術所帶來的非技術性風險: 道德和社會風險。 在辦公室使用AI會引起道德層面的擔心,例如,可能會導致裁員,產生的某些數據會涉及種族問題,甚至會出現未經他人同意便收集數據的情況。 失去對企業的信任。 有些AI系統會產生有害的或帶有偏見的結果,這會損害企業的聲譽。 企業員工和內部利害關係人會失去對AI系統的信任,客戶會對企業失去信任,長遠角度來看,會影響企業的營收。 監管風險。 隨著AI技術的快速演進,對全新AI監管條例的呼聲越來越大,也越來越迫切。 為了確保系統的合規性,這些條列是在已有條規框架基礎上經過改進而得到。 這種做法降低了責任制,增加人們對使用AI技術的道德顧慮。 AI風險管理:一種方法 與其他風險管理方法類似,我們可以採用五步驟法來管理AI風險。 此方法會涉及上下文定義、識別、排序和風險消減。 第一步.定義上下文…

  • 什麼? 能用Python就可以輕鬆解決這5個常見運維!

    通信弱电交流学习 許多運維工程師會使用 Python 腳本來自動化維運任務。 Python 是一種流行的程式語言,具有豐富的第三方函式庫和強大的自動化能力,適用於許多不同的領域。 在維運領域,Python 腳本可以用來實現各種自動化任務,例如: 連接遠端伺服器並執行命令 解析日誌檔案並提取有用信息 監控系統狀態並發送警報 大量部署軟體或更新系統 執行備份和復原任務 運用 Python 腳本可以大幅提高維運效率,並減少人工幹預的錯誤率。 因此,許多維運工程師會選擇學習 Python,以便在日常工作中使用它。 當然,維運崗位的具體職責和要求可能因公司而異,有些公司可能不會要求維運工程師會使用 Python 腳本。 但總的來說,學習 Python 可以為維運工程師的職涯發展帶來很大的好處。 它可以幫助維運工程師更好地完成日常工作,並為他們提供更多的發展機會。 除了 Python 之外,還有許多其他程式語言也可以用於維運自動化,例如 Bash、Perl、Ruby 等。 維運工程師可以根據自己的喜好和需求選擇合適的語言學習。 1、連接遠端伺服器並執行命令 連接遠端伺服器並執行命令是維運工程師經常要進行的任務之一。 使用 Python 腳本可以方便地實現這一操作。 連接遠端伺服器的方法有很多,常用的有 SSH、Telnet 等協定。 在 Python 中,可以使用第三方函式庫 paramiko 來實現 SSH 連線。 下面是一個範例程式碼,可以使用 SSH 連接遠端伺服器並執行命令: import paramiko # 建立 SSH 用戶端…

  • 雲端運算優劣勢分析

    雲端運算的優勢主要基於其自身的特點: (1) 隨選服務、快速部署、自助計費。 一切所需的資源和服務都可以根據自身的需求在雲端運算供應商處獲取,因為雲端運算供應商強大的技術支援能力和 PaaS 、 SaaS 的快速發展,使得部署更加簡單快速。 雲端運算提供的資源和服務皆可自助計費,對於所投資源和成本有較好的數位展示。 (2) 彈性伸縮、快速大規模運算能力 雲端運算另一最重要的優點是彈性伸縮和能夠快速的進行大規模的運算能力。 這對有對外發布系統的企業非常重要。 以下情境舉例:企業在自己的電商平台或銷售平台對使用者或客戶進行促銷活動或秒殺活動。 傳統方式這對IT 部門來說是一個蠻大的挑戰,可能需要準備不少的伺服器和網路資源以便應對高並發和大流量的場景,且不說準備的資源能夠頂住高峰的壓力,峰值之後,很多 資源會處於空閒狀態。 而雲端運算平台則是基於按需服務、按量計費以及彈性伸縮的特性,可以根據系統負載情況進行動態調整,按需、按量計費,不會造成額外的資源浪費和資金浪費。 超大規模的運算能力除了可以幫助企業應對業務高峰之外,還可以幫助企業進行大規模的運算處理能力,如大數據的處理、複雜業務的計算等,這在一些實驗室會有相應的場景。 (3) 雲端生態資源的共享共用 雲端生態資源的共享共用主要體現在以下即可方面: a) 、優秀先進的技術、經驗與高效能的設備資源。 採用雲端運算平台最直觀的就是在技術、經驗和設備方面的效益。 不管是公有雲服務商或私有雲供應商,其大多基於自身或產業的先進技術、經驗完成。 例如運算、儲存的高可用部署,網路的高並發、高頻寬,應用程式、資料庫的叢集和分散式部署方式,作業系統效能最佳化、安全加固,資料庫效能最佳化、安全加固等等,採用雲端運算平台, 可以直接將這些技術和經驗拿過來使用,避免重複研究,再造輪子。 另一方面,採用雲端運算平台,可以不需要單獨投入資金購買價格昂貴的高效能設備資源,按需使用,提高性價比。 b) 、產業數據和大環境分析數據。 雲端運算規模發展到一定程度之後,對應的產業數據分析和大環境數據分析會在雲端平台逐漸成形,這部分數據可以為企業經營提供借鏡意義,同時企業本身也可能是數據生產者一員( 具有兩面性,貢獻資料促進產業資料分析;雲端環境下資料安全性不可控制)。 c) 、雲生態資源的高度利用。 這主要是針對 PaaS 和 SaaS 層。 依托優秀企業的 PaaS 、 SaaS 的服務經驗,對其進行產品化對外提供使用。 對這類資源企業只需專注於自身的業務即可,無需關心底層硬體架構,且業界領先的設計方案能夠為企業自身發展提供建設性指導意見。 雲端運算因為其自身按需服務、自助計費、快速部署、彈性伸縮、超大規模運算能力等一些欄位特性,相比傳統的 IT 架構和部署方式有著非常多且非常顯著的優勢。 但也正好相比傳統部署的這些特性也帶來系列的風險和不穩定的因素,主要集中在資料安全性、雲端服務穩定性以及雲端服務關閉的善後等問題。 (1) 資料安全性問題 相較於傳統封閉部署的方式,企業採用雲端服務之後,其自身的系統、資料便不再由自身自主可控,而是放在雲端平台,其資料的隱私安全一直是業界討論的重點之一。 絕大多數的存有敏感資料的企業在選擇雲端平台方面還是非常低調保守,大多只是邊緣性業務上雲。 對於資料安全性問題還是要一分為二看待:首先規模比較大、比較正規的雲端服務供應商,其在資料安全保護方面的技術和策略上一般是大大優於傳統企業部署方式,不管是在…

  • 可組合架構與微服務:哪個比較優?

    岱军 云云众生s 兩種軟體開發架構都有各自的優缺點。 以下是如何決定可組合架構還是微服務架構哪一種比較適合你的方法。 譯自Composable Architectures vs. Microservices: Which Is Best?,作者 Michel Murabito。 單體架構幾十年來一直是軟體開發的基石。 儘管其簡單易開發的特點,但隨著應用程式複雜度的增加,傳統架構往往會遇到效能瓶頸和可擴展性挑戰。 微服務很快就成為一種解決方案,透過提供效能優化、靈活性和容錯性來應對這些挑戰。 從行業巨頭如Atlassian和Netflix成功從單體技術遷移的經驗中我們可以學到的一課是,速度、敏捷性和可擴展性在當今市場上獲勝。 可組合架構作為一種與軟體開發不斷發展的需求相契合的補充方法已經出現。 這種設計方法在科技業引起了許多關注,在2021年,Gartner預測採用可組合方法的公司將能夠比競爭對手更快實現新功能,提高了80%。 儘管可組合架構可以增強企業的敏捷性、可擴展性和適應性,但許多IT和DevOps團隊想知道這對微服務意味著什麼。 他們關心這些方法之間的關係、相似之處和差異,以及可組合架構是否會讓微服務過時。 可組合架構:模組化系統的崛起 可組合架構是一種模組化的軟體設計和開發方法,建構了靈活、可重複使用且適應性強的軟體架構。 它涉及將龐大的、單體平台分解為小型、專業化、可重複使用和獨立的組件。 這種架構模式包括一系列可插拔的模組化元件,如微服務、打包的業務能力(PBC)、無頭架構和API-優先開發,這些元件可以無縫地替換、組裝和配置,以滿足 業務需求。 在可組合應用中,每個元件都是獨立開發的,使用最適合應用功能和目的的技術。 這使企業能夠建立可以迅速適應業務需求的客製化解決方案。 由於這種架構模式是基於API-優先原則,資訊在服務和系統之間共享,無需了解底層技術。 這種方法提供了一系列好處,包括: 它幫助團隊輕鬆快速地擴展規模,充分利用成長機會獲得競爭優勢。 它使維護和系統更新變得更容易,因為模組化組件可以單獨修改和替換,減少認知負擔。 它透過允許團隊重複使用和重新利用現有組件來滿足不斷變化的需求和要求,加快了開發過程。 它允許添加新的API和工具以支援成長,而不必擔心它們是否能很好地配合使用。 它使組織能夠跟上數位管道的業務趨勢,同時提供一致的體驗,提高客戶滿意度。 在電子商務應用和網站開發中,可組合方法已經得到了顯著的普及,為開發人員、客戶和零售商增強了數位體驗,像Shopify和Amazon這樣的行業領導者正充分利用其優勢。 微服務:仍然強大的經過驗證的方法 微服務架構仍然被用於開發、部署和擴展簡化的模組化軟體解決方案,這些解決方案可以被其他應用程式重複使用。 它包括一組較小的獨立組件或服務,每個組件負責特定的業務功能。 微服務是與傳統的單體架構有重大差異的,傳統架構中,使用者介面和後端通常緊密耦合,設計為作為單一功能一起工作。 微服務架構是一種分散化的方法,可讓團隊開發、維護和持續改進單一服務,而不會中斷整個應用程式。 這些技術通常利用API來外部公開訊息,以實現與外部服務、應用程式和系統的無縫整合。 微服務架構非常適合具有多個功能組件的複雜系統,許多大型科技公司,包括eBay、X(以前被稱為Twitter)和Netflix,已將其傳統的單體應用程式遷移到了小型、獨立的、專業 化的應用程式。 在2023年,Stack Overflow的開發者調查報告稱,49%的開發者正在其組織中使用微服務。 微服務為軟體開發組織提供了明顯的好處,例如: 增強了故障隔離,並確保單一模組的失敗對較大的應用程式影響最小。 提供了靈活性,可以根據需要添加、替換或移除單一微服務,同時嘗試新的技術堆疊。 使團隊能夠採用小型且頻繁的發布,利用CI/CD自動化開發、測試和發布流程。 將軟體組件隔離,以便進行效能和健康監控。 然而,與每一項新興技術一樣,使用微服務也有其缺點。 大量獨立的服務引入了複雜性,可能會使得管理每個服務變得艱鉅。 DevOps和維運團隊也可能會遇到分散式追蹤的挑戰。 多個服務之間的通訊也會產生操作開銷,使系統設計變得複雜。…

  • 私有雲環境下三種類型儲存適用場景的比較分析

    原创 陈萍春 twt企业IT社区 一、關鍵技術需求 金融業機構對於資料中心儲存都有高效能、高可靠性、彈性擴展、易管理的技術需求。 對於企業私有環境下的雲端平台儲存來說,這些技術需求又會存在一些差異: 高效能 雲端平台的彈性伸縮特性可支撐超大規模的運算節點部署,也帶來了超大規模的資料存取請求,這就給儲存系統帶來了相當大的負載壓力;而不同的業務系統對儲存設備的效能 又有明顯的差異,如何承接這些儲存負載,如何儲存分級分層、保障儲存服務品質是雲端平台儲存架構設計的首要目標。 高可靠性 雲端運算的虛擬化特性大大提高了IT資源的使用效率,也帶來了很高的耦合性,極易造成問題群發,故障影響半徑往往更大。 而金融資料安全的重要性不言而喻,有著嚴格的RTO、RPO要求,那麼如何做好資料隔離,如何滿足儲存系統的高可用和容災復原需求成為雲端平台儲存架構設計最關鍵目標。 彈性擴展 雲端平台儲存可以有效提高儲存使用效率,儲存精簡配置和自動供給能一定程度滿足儲存資源的彈性供給。 隨著業務規模的增加、業務資料增量龐大,雲端平台儲存資源池也不可避免地需要頻繁調整。 另外,雲端運算技術也處於蓬勃發展階段,技術更迭速度較快,因此一個支援平滑升級適配、平滑擴充、無需中斷業務即可無縫擴展的雲端平台儲存架構也是迫切需求。 易於管理 雲端平台儲存的易管理性體現在兩個方面,一方面是統一儲存管理,另一方面則是儲存自動化和視覺化能力。 統一儲存管理既能對外提供豐富的標準接口,如文件系統接口、塊存儲接口或對象接口等,又能異構存儲納管,將各類存儲資源統一管理、靈活配置;自動化可簡化部署,對 日常工作進行自動化管理,視覺化可深入洞察儲存與應用的關係,掌握儲存使用與容量成長趨勢。 二、關鍵技術元素 雲端平台儲存架構圖 雲端平台儲存主要是資料儲存層、儲存抽象層、儲存介面層和儲存資源管理這樣的分層架構,包括以下的關鍵技術元素: 底層資料儲存:可分為企業儲存、分散式物件儲存和分散式檔案系統這三種類型; 儲存資源虛擬化:儲存資源虛擬化是透過虛擬化技術將底層資料儲存虛擬化為儲存資源池,對雲端平台屏蔽底層資料儲存實作細節; 儲存介面:儲存介麵包括提供給業務應用的資料存取介面和儲存資源管理介面。 其中底層資料儲存是雲端平台儲存的基礎,與其他技術元素的實現方式息息相關,下文將分別剖析不同的底層資料儲存及其適用場景。 三、企業儲存及其適用情境分析 企業儲存使用專用硬體和儲存控制器,儲存控制器採用雙控製或多控互連架構,包含Raid功能和大容量Cache。 控制器後端連接到磁碟櫃,磁碟櫃包含了多個Raid組,每個Raid組又包含多塊磁碟,這就組成了磁碟陣列,如圖3所示。 圖3:企業儲存硬體架構示意圖 企業儲存一般可提供區塊儲存或文件儲存介面服務,其優點可總結為: 效能:IO分片粒度小,資料IO傳輸路徑短,表現為低時延和高IOPS; 可靠性高:專有硬體和儲存控制器的可靠性高,基於RAID和硬體冗餘等技術也較成熟; 資料強一致性:控制器、磁碟間的集中式互聯架構最大限度地保證了資料的強一致性。 一般來說,企業儲存在私有雲平台的適用場景如下: 雲端主機硬碟:透過iSCSI介面對接雲端平台,為雲端主機提供儲存; 文件共享:提供NFS或CIFS的檔案系統接口,滿足業務系統的文件共享儲存需求; 關鍵業務系統和交易類資料庫:由於企業儲存具有優異的IO效能和高可靠特性,可以很好地契合關鍵業務系統和OLTP資料庫。 四、分散式物件儲存及其適用場景分析 分散式物件儲存(Key-Value)是一種無中心化架構,透過資料佈局演算法均衡分佈在不同節點上。 Ceph是一種典型基於分散式鍵值的儲存系統,其object資料分佈採用的是crush演算法,是在一致性hash演算法基礎上,充分考慮多副本、故障域隔離等約束設計而來,其實現原理 如圖4所示。 圖4:分散式物件儲存底層原理示意圖 分散式物件儲存可以支援更好的擴充性,其適用場景如下: 雲端平台硬碟:Ceph可透過RBD、iSCSI方式對接OpenStack雲端平台,支援大規模部署; 海量資料儲存:由於分散式物件儲存的高擴充性,可以很好地滿足海量資料儲存需求。 五、分散式檔案系統及其適用情境分析 分散式檔案系統遵循map-reduce的設計思路,分而治之再合併。 分散式檔案系統(DFS)本質上是一種虛擬檔案系統,本身有著檔案目錄結構特徵。 而DFS對外提供的儲存單元則由檔案組成,這些檔案會被邏輯分片,再依照多重資料副本分佈演算法分佈到不同資料節點上,如圖5所示。 圖5:分散式檔案系統的儲存底層原理示意圖 基於DFS的雲端儲存邏輯清晰,也有著比較廣的應用範圍,例如GFS、HDFS等典型應用,包括部分超融合方案的底層儲存也是基於DFS來實現的。 透過IO效能優化,分散式檔案系統具有較好的儲存IO效能、擴充性,其適用場景如下: 雲端主機硬碟:可透過iSCSI介面對接雲端平台,為雲端主機提供儲存;…

  • 如何設定交換器SSH遠端登入

    通訊弱電交流學習 2024-01-13 07:35 山東 如何設定交換器SSH遠端登錄,本期我們就來了解下ssh遠端登陸的方式,以銳捷交換機為例。 如何設定銳捷SSH遠端登陸? 一、配置思路 配置ssh遠端登陸,一般是有四個步驟: 1.首先選擇Console方式登陸交換機 2、開啟交換器的SSH服務功能並設定IP 3、產生加密金鑰 4、配置SSH管理的登入口令 二、設定步驟(以銳捷交換器的配置為例) 1.首先選擇Console方式登陸交換機 2、開啟交換器的SSH服務功能並設定IP switch>enable //進入特權模式 switch#configure terminal //進入全域設定模式 switch(config)#enable service ssh-server //開啟ssh-server switch(config)#interface vlan 1 //進入vlan 1接口 switch(config-if)#ip address 192.168.1.1 255.255.255.0 //為vlan 1介面上設定管理ip 192.168.1.1 switch(config-if)#exit //退回全域設定模式 3、產生加密金鑰 switch(config)#crypto key generate dsa //加密方式有兩種:DSA和RSA,可以隨意選擇 然後等待密鑰生成,然後直接敲回車就好 4、配置SSH管理的登入口令 switch(config)#line vty 0 4 //進入SSH密碼設定模式,0 4表示允許共5個使用者同時SSH登入交換機 switch(config-line)#login local //啟用SSH時使用本機使用者和密碼功能…

  • 思科、華為、H3C交換器巡檢命令全整理

    通信弱电交流学习 01.思科交換器巡檢命令 1、show interface stats:查看交換器所有介面目前介面流量 2、show running-config:查看目前設備配置 3、show version:查看IOS版資訊及設備正常運作時間 4、show clock:查看設備時鐘訊息 5、show vtp status:查看交換器vtp設定模式 6、show vtp password:查看交換器vtp設定口令 7、show env all:查看設備溫度,電源與風扇運轉參數及是否警報 8、show inventory:調取設備內部闆卡出廠模組型號及序號 9、show spanning-tree root:查看交換器產生樹根位置 10、show cdp neighbors:查看鄰接cisco設備基本資訊 11、show cdp neighbors detail:查看鄰接cisco設備詳細信息 13、show interface summary:查看交換器所有介面目前介面流量 14、show interface |ierrors|FastEthernet|GigabitEthernet:查看介面是否有大量input或output errors套件錯誤 15、show processes cpu:查看設備cpu負載 16、show processes mem:查看設備mem負載 17、show access-list:查看存取控制清單配置及匹配資料包數量 18、show logging:查看本機內部日誌記錄狀況 19、show ip route:查看路由表 20、show firewall:檢查防火牆的工作模式 21、show…

  • 思科收購Cilium對開發者的意義

    原创 岱军 云云众生s 思科收購Isovalent,取得開源專案Cilium。 Cilium利用eBPF(擴展伯克利包過濾器)技術,實現核心級網路與安全。 譯自Cisco Gets Cilium: What It Means for Developers,作者 Torsten Volk。 2023年底,思科宣布意圖收購Isovalent,這是Cilium開源專案背後的公司。 Cilium利用eBPF(擴充伯克利包過濾器)進行核心級網路與安全,是2023年雲端原生空間中值得注意的重要進展之一。 Cilium利用eBPF提供進階網路和安全控制。 eBPF是一項Linux核心技術,可讓動態插入強大的安全、可見性和網路控制邏輯。 這項技術在Cilium中被用來提供高效能網路、多叢集和多雲能力以及進階負載平衡。 Isovalent由一批享譽盛名的投資者支持,如Google、安德森·霍洛威茨(Andreessen Horowitz)、微軟、Grafana以及思科本身。 但是思科為什麼真的要進行這項收購,它對應用程式開發者和DevOps專業人員意味著什麼呢? 讓我們從頭開始 Dan Wendlandt,CEO,和Thomas Graf(CTO)都參與了Open vSwitch和Nicira的網路虛擬化平台(NVP)的誕生,後來成為VMware最重要的產品之一:軟體定義網路(SDN)的NSX平台 。 SDN的全部意義在於將網路交換器轉換為軟體。 這使得應用程式開發者能夠快速迭代和部署網路配置,例如微分段,與應用開發週期同步。 DevOps人員可以自動化和簡化網路供應和管理流程,使其與CI/CD管線保持一致。 安全專業人員可以以程式方式強制細粒度的安全策略和隔離網路流量,以增強整體安全態勢。 這一切聽起來都很棒,那我們為什麼需要Cilium和eBPF呢? SDN和帶有eBPF的Cilium 網路中SDN和eBPF的詳細集成 SDN透過可程式介面在第1、2和3層提供對網路配置和管理的控制。 另一方面,利用eBPF的Cilium將此可程式控制擴展到傳輸層(第4層)和應用層(第7層)。 這允許透過TCP、UDP、ATP和MTCP等協定強制網路策略,這些協定為應用程式提供端到端的通訊服務。 eBPF,一個起源於Linux核心的革命性技術,允許沙箱化的程式在作業系統內運行,為雲端原生環境中的網路和安全性提供更細粒度和更靈活的控制。 與傳統的用戶空間網路相比,這種核心級網路消耗更少的資源並且運行更快,主要是由於Linux核心和用戶空間之間的通訊減少,以及直接存取系統資源。 作為Kubernetes叢集上每個節點的守護程式集部署的Cilium,強制執行使用者定義的網路策略,並將這些定義轉換為eBPF程式。 這種方法使Cilium能夠提供一個簡單的平面Layer 3網絡,並能夠在第3、4和7層(應用程式層級)為HTTP、gRPC或Kafka等協定強制執行網路策略。 總之,雖然SDN在較低層提供對網路配置和管理的可程式控制,但帶有eBPF的Cilium將此控制擴展到傳輸層和應用層。 這為網路和安全性提供了更細微和更靈活的控制,特別適合雲端原生環境。 對應用程式開發者的優勢 SDN與eBPF的集成,特別是透過像Cilium這樣的工具,為應用程式開發者帶來許多優勢,尤其是在雲端原生環境中。 以下是這些優勢的詳細分析: 增強的可程式性和適應性: eBPF的可程式性質使開發者能夠快速適應雲端原生格局的變化。 這種靈活性在一個以不斷演進和需要快速迭代為特徵的領域至關重要。 簡化的開發過程: Cilium抽象化了eBPF的複雜性,使開發者能夠利用其功能而不需要深入探究編寫eBPF程式碼的複雜性。 這種抽象降低了學習曲線和開發時間,使其更容易被廣泛的開發者所接受。…

  • 「裸奔」的容器,安全問題迫在眉睫

    汪照辉 twt企业IT社区 【摘要】容器本身就是弱安全的,容易帶來越權逃逸等問題,同時容器應用研發人員對容器技術又缺乏了解,缺乏相應的安全意識和安全知識,這就帶來了比較嚴重的潛在的安全 問題,有很多的事項迫在眉睫。 【作者】汪照輝,中國銀河證券架構師,專注於容器雲、微服務、DevOps、資料治理、數位轉型等領域,對相關技術有獨特的理解與見解。 擅長於軟體規劃和設計,提出的「平台融合」的觀點越來越被認同和事實證明。 發表了許多技術文章探討容器平台建置、微服務技術、DevOps、數位轉型、資料治理、中台建置等內容,受到了廣泛關注與肯定。 最近測容器安全,才發現部署的容器雲平台和容器應用幾乎在裸奔,每個鏡像和容器都有各種各樣的漏洞,平臺本身也不少問題,真是不測不知道,一測嚇一跳 。 容器本身就是弱安全的,容易帶來越權逃逸等問題,同時容器應用研發人員對容器技術又缺乏了解,缺乏相應的安全意識和安全知識,這就帶來了比較嚴重的潛在的安全問題。 容器安全問題涉及內容很多,比如說鏡像安全、容器運行時安全(入侵偵測監控、入侵攔截和隔離)、容器平臺本身的安全、容器網路安全、微隔離等,任何一項內容做好都不容易 ,而且可能涉及多個部門和團隊,需要協作,所以我們也在討論容器安全應該由安全團隊來負責還是容器雲平台團隊來負責,在安全左移的趨勢下,是否應該更多關注pre- runtime安全性等等。 安全問題無所不在,有很多的事項迫在眉睫。 一、 容器安全的核心在哪? 最近的測試讓我一直在思考容器安全的核心到底該在哪裡。 是鏡像安全? 還是容器運作時安全? 還是主機安全? 網路安全? 雖然都在鼓吹安全左移,但我覺得容器運行時安全依然是核心,要能及時的檢測到安全威脅並自動實現入侵攔截,網絡微隔離或者網絡阻斷可能是最後的手段了。 不過為了減少安全漏洞,降低安全威脅程度,前期的安全準備及安全措施也是至關重要,例如鏡像安全掃描和修補程式修復,平台和網路本身的安全能力等等,都是密切相關。 任何環節都有漏洞,都可能帶來嚴重的問題。 二、 安全左移 安全左移目的就是要提前採取措施修復潛在的漏洞,盡可能在後期的運作過程中增強抗攻擊能力。 對於容器雲端平台來說,基礎鏡像的維護就非常重要。 雖然目前說可以很方便的從網路上下載各種各樣的鏡像文件,但許多鏡像文件都存在這樣那樣的眾多漏洞,如果不加區分的部署在自己的容器雲環境,勢必會帶來很多潛在 的問題。 所以這就需要在容器雲平台提供企業業務應用開發所需的基礎鏡像,例如jdk、tomcat、nginx、mysql、kafka、nodejs、CentOs等等,這些鏡像需要容器團隊來維護並及時的更新,在發現 新的漏洞之後先更新基礎鏡像,然後在適當時間適當的方式用新鏡像更新存量運行時的容器。 基礎鏡像的安全維護可能是一個不小的工作量。 但是這是一個值得做的事情。 許多容器雲廠商也提供像製品庫、應用程式商店一樣的功能來管理鏡像,但缺乏對鏡像的深度維護和安全措施。 這些鏡像往往存在著許多漏洞,在公司內部網路可能還好,一旦運作在網路環境,就面臨極大的威脅。 依照安全左移的思想,最好的方法就是所有部署的鏡像都是安全的鏡像,在部署前解決掉安全問題。 在測試中我們震驚於一個鏡像竟然存在數百個高風險漏洞,如果讓業務應用團隊去修復,基本上是不可能的。 所有的業務應用鏡像最好來自於平台所提供的安全的基礎鏡像。 這樣,至少統一的安全的基礎鏡像會減少安全漏洞,也減少業務團隊自行下載、產生鏡像所帶來的安全隱患。 三、 Pre-Runtime鏡像掃描 提供安全的基礎鏡像應該是容器雲端平台的基本職責之一。 不過業務團隊也需要載入業務應用程式及對應的工具庫等到基礎鏡像,然後產生業務鏡像。 這就可能引入新的安全威脅。 在鏡像部署之前或在鏡像進入鏡像倉庫之前需要進行必要的安全掃描,以偵測鏡像檔案可能存在的漏洞和問題,在部署之前修復鏡像存在的漏洞。 我們在建造容器雲端平台時,“以鏡像倉庫為媒介”,隔離開發和部署,我們不向終端用戶提供Docker和Kubernetes CLI命令,所有的操作都透過平台UI完成。 也就是說要部署鏡像,需上傳鏡像到鏡像倉庫,上傳鏡像倉庫裡的鏡像可以自動被安全掃描。 如果存在高風險漏洞,則可以透過設定的規則禁止部署。 我們測試的容器安全廠商提供Jenkins外掛程式來實現高風險漏洞鏡像阻斷部署,用於CD持續部署流程。 由於思路的不同,實作方式有差別。 不過我個人覺得可以再安全左移一點,把部署阻斷放在鏡像倉庫。 高風險漏洞的鏡像禁止出鏡像倉庫或甚至禁止進鏡像倉庫,在upload時實現鏡像的安全掃描和高危險阻斷。 四、…

Got any book recommendations?