關於 維運人員 ，我們在網路上蒐集到這些相關的討論、資訊與評價

【SP-ISAC會員專屬限定】線上講座｜資安黑魔法-與駭客諜對諜
課程名稱：線上講座 - 資安黑魔法-與駭客諜對諜
直播時間：(上半場)：2021/10/20 (三) 13:30 - 16:30
(下半場)：2021/10/21 (四) 13:30 - 16:30
參與方式：預計以 Microsoft Teams 軟體進行線上直播
報名時間：2021/10/01 (五)中午12：00 - 10/15 (五)下午5：00
報名表單：https://forms.office.com/r/kyayj9LjKJ

歡迎園區廠商免費報名參加，請有意報名之園區廠商同仁於「報名時間」至「報名表單」連結網址報名登記，報名後將於10/20(一)前寄發課前通知信及提供視訊連結，敬請留意信件！並持續關注SP-ISAC網站『活動資訊』。
考量視訊品質與所使用之平台上線人數最大值，若報名人數達標時，報名連結將關閉。

課程介紹：
本次課程將透過今年的重大資安事件與指標，展開真實案例與環境的研究與討論，同時會於課程當中分享資安日常維運時可能遭遇到的潛在攻擊，找出駭客可能使用的攻擊魔法。
讓身為資訊與資安維運人員的我們，得以從中瞭解如何從防禦面進行剝絲抽繭、查看維運日誌，進一步識別資安威脅與緩解攻擊，亦可使攻擊轉換成有效的防禦助力。

課程內容安排：
1.2021重大資安事件｜2.識別駭客的攻擊魔法｜3.處理駭客攻擊｜4.以其人之道還治其人之身，主被動情資搜集。

ref: https://kubernetes.io/blog/2021/09/03/api-server-tracing/
該文章介紹的是 Kubernetes v1.22 所推出的新功能，該功能目前還是屬於 Alpha 階段，這意味要打開該功能則必須要從 Feature flag 下手打開

該功能非常簡單，就是讓 Kubernetes API Server 支援 Tracing 的功能，讓管理者可以透過 Tracing 的工具去檢視 API Server 之間的 Tracing 資料。

分散式系統的環境使得除錯非常困難，每次問題發生時都要針對一個又一個的元件去檢查，找看看每個元件的 log，甚至可能還需要開啟 debug log 的選項才可以
看到更仔細與直接的內容。而 Distributed tracing 就是用來解決這種情境的，而 Kubernetes API Server 又是 Kubernetes 叢集內最重要的核心元件，
因此 Kubernetes 的 SIG Instrumentation 群組目標就是讓各位管理員能夠更輕易地透過 Tracing 去理解當前 API Server 的狀態。

這次的解決方案是基於 OpenTelemetry 的框架去使用的，文章範例中使用 Jaeger 作為 Backend 的 UI 來顯示 API Server 間的 tracing 資料。

從 Observability 的角度來看，能夠透過 Tracing 觀察與監控 Kubernetes 叢集本身的狀況對維運人員來說是一個滿好的工具，不過該功能目前於 v1.22 都還是 Alpha 的版本。
因此對於大部分的使用者來說應該都還是沒有辦法測試該功能，特別是使用 Kubernetes Managed Service 的使用者來說，估計可能還要再等上一段時間才會變得內建支援。

ref: https://faun.pub/the-best-infrastructure-as-code-tools-for-2021-b37c323e89f0

這篇文章是一個 IaC (Infrastructure as Code) 的推廣文，文章分成幾個部分，從 IaC 的基本概念與應用談起，接者分析了幾個常見的 IaC 工具，最後探討了實際的使用案例

文章偏長，對於 IaC 概念很熟悉的讀者應該可以很快速地看完，以下針對部分進行一些摘要

The need for Infrastructure as Code
作者先描述過去幫機房部署新伺服器時的各種流程，機器少量時能夠透過人力慢慢處理，但是這類型的操作繁瑣，重複且惱人
為了讓這些流程處理得更佳順遂與一致，會有各式各樣的 scripts 等相關工具被開發出來，而這些流程慢慢的會往自動化的方式去發展。
IaC 文化的興起會使得有愈來愈多獲得共識的工具被開發出來，這使得 IaC 的使用門檻會有機會降低，愈來愈多的使用者能夠更簡易的透過 IaC 的方式來管理與維護自身的架構

Benefits and reasons to implement IaC
IaC 帶來的好處是非常顯著的，譬如
1. 將 Config 檔案當作整個環境的 sing source of truth
2. 每次的部署都是基於上述的 Config 來部署，能夠確保每次部署都獲得一樣的結果，避免人為的反覆長期操作帶來的錯誤
3. 透過程式化的方式去建置環境能夠更快速的去應變各種環境需求，對於 testing, developing, production 等各種變化都可以透過 config 的差異來快速搭建
4. Config 也可以透過 Git 的方式去管理來獲得更好的可稽核性與管理性。

Principles and best practices of Infrastructure as code
作者這邊列出了幾個實作上的推薦方式
1. 透過版本控制的方式來管理 IaC 的設定檔案，能夠讓維運人員使用開發者常見的開發合作流程來管理 IaC
2. 將 IaC 的工具整合到 pipeline 的 CI/CD 流程，讓 CI 流程去檢查 IaC 的設定是否符合預期以及 CD 流程來幫忙自動部署修改架構

Infrastructure as code tools
這個區塊作者列出了幾個常見的工具，包含 Terraform, CloudFormation, Puppet, Pulumi 等，接者又透過一張大表格來比較 Terraform/Pulumi/CloudFormation 三者的差異
Pulumi 這工具這一兩年開始聲勢比較多，跟 Terraform 一個最大的差異我想就是撰寫的方式，可以透過 Js, Go, Python...等程式語言來描述架構而並非使用 Terraform 自定義的 DSL 來管理。

最後面作者也列舉了六七個適合 IaC 的使用場景，有興趣的歡迎閱讀全文