Charlie Wei Blog

只要討論到 Web 應用程式的資安問題，在 Azure 官方文件中都是唯一推薦使用 Web Application Firewall (WAF)，好奇心驅使下的我一直很想知道 WAF 到底會怎麼防禦這些資安攻擊，於是以下我嘗試了幾種最簡單的攻擊手法，來看看 WAF 會有哪些反應。 WAF on Azure Application Gateway WAF 其實本身不是一項單獨的服務，它更像是其他服務內的進階功能，以我們這次選擇的 Azure Application Gateway 為例，你必須要選擇 WAF_v2 等級的 SKU 才能享受到 WAF 的資安保護。 再來我們還需要一個可以被測試攻擊的網頁做為 Application Gateway 的後端，最快速的方式就是建立一個 App Service，在這個測試中我們不需要編寫任何網頁或測試，直接使用 App Service 的預設入口即可。 建立 Virtual Network 首先我們先建立一個 10.10.0.0/16 的虛擬網路，其中 10.10.1.0/24 的子網段會分配給 Application Gateway 使用。 建立 Public IP 接著因為我們會透過 Application Gateway 將網頁對外，所以勢必需要一個公用 IP。 建立 Application Gateway 再來就是建立 Application Gateway 了，這邊記得要對應上剛剛建立的子網段與公用 IP。 Application Gateway 使用 Portal UI 創建時會需要你點一堆東西，但如果使用 AZ CLI 就可以跳過這些點擊，並給你一組基本的設定。 建立 App Service 如前面提到的，我們需要一個 App Service 做為測試的網頁，首先建立 App Service Plan。 接著在 Plan 上建立 App Service。 設定 Application Gateway 再來我們需要在 Application Gateway 上加上一點設定，來讓 Application Gateway 可以將流量導入 App Service。 後端集區 使用 AZ CLI 建立的 Application Gateway 會帶有一個預...

在一次因緣際會下，我們發現 Azure Databricks 下的 Serverless SQL 在 2024 年 1 月底出現了全球範圍的費用計算異常，本篇文章將紀錄如何使用 Databricks 的 System Tables 追蹤各服務的真實用量，並藉此計算成本後與 Azure 費用帳單核對，以保障自身權益。 Databricks System Tables Databricks System Tables 是在啟用 Databricks Unity Catalog 後可以使用的一項新功能，截至目前還位於 Public Preview 階段並免費提供使用。 System Tables 在啟用後不用編寫任何程式，就會自動收集一系列由 Databricks 定義好的系統資訊，這邊我們主要先看 system.billing.usage 這張表。 system.billing.usage system.billing.usage 這張表記錄了所有會被計算費用的 Databricks 資源，並以每個小時每個工作區做彙整，關於這張表的詳細欄位說明可以參考以下官方文檔。 參考連結： https://learn.microsoft.com/zh-tw/azure/databricks/admin/system-tables/billing 使用以下這段 SQL 我們可以整理出 2024 年一月每天 Serverless SQL 所花費的 DBU 數量： 其中我們用 workspace_id 限制查找有開啟 Serverless SQL 功能的工作區，這也會用在我們後續與 Azure 帳單核對。 system.billing.list_prices system.billing.list_prices 這張表非常單純，紀錄的是各項服務的定價，同時也包含了歷史定價，欄位說明一樣參考官方文檔。 參考連結： https://learn.microsoft.com/zh-tw/azure/databricks/admin/system-tables/pricing 以下這段 SQL 可以看出 Serverless SQL 每 DBU 的歷史定價： 執行結果如下： 可以看出目前 Serverless SQL 的每 DBU 是 0.88 美金，而其中...

對於一般使用的 Azure VM，或多或少都需要在防火牆或 NSG 上允許部分的存取規則，來讓我們進入 VM 完成工作，而這樣的允許規則就讓 VM 變得容易受到攻擊。 Azure VM 上的 Just-In-Time (JIT) 存取是 Microsoft Defender for Cloud 的其中一項功能，JIT 可以讓我們在需要連線 VM 時，在 NSG 上暫時性地新增一條允許存取規則，並且可以在設定的一段時間後自動失效該存取規則。 必要條件 也因為 JIT 是 Defender for Cloud 的其中一項功能，所以必須在訂閱層級先開啟 Defender for Servers Plan 2 才能使用 JIT，如果先前未開啟 Plan 2，在開啟前記得先評估可能產生的額外費用。 建立 Azure VM 首先我們先在符合條件的訂閱上建立一台測試用的 VM，都使用最基本的 Windows 就好。 網路部分我們建立一個新的 VNet 與一個稍後要用來連線的對外 IP，另外也記得讓系統順便幫我們建一個基本的 NSG 出來。 啟用 JIT 啟用方式非常簡單，在 VM 的 Portal 中進入左側「連線」→「連線」頁籤，再點擊「Just-In-Time 原則」→「針對此連接埠設定」→「設定」就完成啟用了。 成功啟用後，可以到剛剛自動建起的 NSG 畫面，這時候會多一條 3389 埠的拒絕規則，這是 JIT 預設的行為。 要求 JIT 存取權 設定好 JIT 後，使用者在連線前要先請求存取權，可以根據需求請求單一 IP 或不限 IP 的存取權，這步也是在同一個頁面中點兩下就搞定了。 請求成功後一樣可以到 NSG 的畫面，這時 JIT 會自動加上一條優先度 100 的 3389 允許規則，以此來允許我們的 RDP 連線。 其他連線方式 預設情況下，請求將允許有 3 小時的連線時間，對於其他連接埠或有調整連線時間的需求也可以自行新增設定。 連線測試 🎉成功！ 結論 JIT 不但能有效減少 VM 對外暴露的入口，定時讓允許規則失效的機制也減少了管理工作，與以往常發生機器用完忘了關閉連線的風險，在設定與使用上都很簡單方便，唯一的缺點大概就是 Defender for Servers Plan 2 的成本，這點就需要大家自行評估囉！

在 Azure 中提供了各式各樣的 API 讓我們可以在不同的場景中隨意組合使用，對於服務的 API 一般會在建立完成時分配一個專用的 Key，雖然這可能不是最佳作法，但直接使用 Key 來呼叫 API 的作法非常方便直觀。然而其他非服務類或管理層面的 API 就會遵循 OAuth 2.0 標準來設計，這對於初次使用且不太熟悉 OAuth 2.0 流程的人來說就不是很好上手。 這篇文章就來記錄一下如何在 Service Principal 中使用 OAuth 2.0 四個基礎流程之一的 Client Credentials 來呼叫 Azure API，並且盡量跳過那些繁雜的 OAuth 2.0 理論。 建立 Service Principal 首先建立要用來呼叫 API 的 Service Principal，使用以下 Azure CLI 指令： 指令在建立時會順便指派權限給 Service Principal，以這邊為例，我們將 Service Principal 指派在資源群組範圍 "/subscriptions/<SUBSCRIPTION-ID>/resourceGroups/charlie-test" 上的 Reader 。 建立成功後會得到以下回應： 其中 appId 、 password 與 tenant 會在下一步中使用，記得要先記錄下來。 另外在 Portal 中的 Microsoft Entra ID 也可以搜尋得到建立完成的 Service Principal。 取得 Access Token 在上一步中我們得到了類似密碼或 Key 的 password ，但這並不能直接作為呼叫 API 的驗證，我們必須要先用這個 password 來換取 Access Token。 至於為什麼需要多這一步驟，就與最一開始提到 OAuth 2.0 的 Client Credentials 有關，我們將理論的部分留給有興趣的讀者，現在我們只要把他當成固定流程就好。 取得 Access Token 的方式是一個 HTTP Post，以下我們選擇可以直接在 Azure Cloud Shell 中執行的 curl 指令作為範例。 其中 <TENANT-ID> 、 <APP-ID> 與  ...

上週 5/13 OpenAI 公開了最新一代的模型 GPT-4o，而讓人意外的是 Azure 居然搶在第一天與 OpenAI 同時上線了 GPT-4o，要知道以往這都要落後一個月的。時過一週 Microsoft Build 2024 開發者大會登場，題目當然是繼續圍繞著 AI，而 GPT-4o 也脫離 Azure OpenAI Early Playground 進入可佈署模型，沒錯，僅僅一週這個剛推出的 Early Playground 又不見了 。 在 Microsoft Build 2024 期間推出的眾多新功能中，目前最讓我出乎意料的就是 GPT-4o 多了一種新的 Global Standard 佈署型態，這讓 GPT-4o 可以達到前所未見的一千萬 TPM，對於整天 429 的我來說真的是一大救星。 模型佈署 截至撰文當下，GPT-4o 只支援美東、美東二、美國中南部、美國中北部、美西與美西三地區，所以必須要先在這些地區建立 Azure OpenAI 資源，正確的支援地區請參考 官方文件 。 佈署方式與之前的模型一樣，點擊「Deployments」頁面上方的「Create new deployment」。 當選擇 gpt-4o 模型時，佈署型態就能選到全新的 Global Standard，接著開啟下方的「Advanced options」。 真的可以有一千萬 TPM 😱 Global Standard vs Standard 根據最新發佈的官方文件，Global Standard 其實就是透過將客戶的請求負載均衡到世界各地的 Azure 資料中心，藉此來提供更高的 TPM，同時 Global Standard 也是目前官方建議在測試或實驗階段首選的佈署型態。 不過因為每次請求都不知道會到達哪個地區的資料中心，所以 Global Standard 並不支援 Azure Data Residency Promises，如果有這方面考量的人可能就需要注意了。 最後附上 官方文件上的比較表 供讀者參考。 TPM 事實上 Global Standard 的一千萬 TPM 必須要 Enterprise Agreement 客戶才能得到，這對蠻多使用者來說可能比較難達成，如果你使用的是 Pay-As...

為了將運行在 Kubernetes 內的服務對外公開，最基本就是透過  ClusterIP 或 Nodeport 的方式，而到了雲端的 AKS 可以使用  LoadBalancer 搭配 Azure Load Balancer 這類的雲端服務，但對於有網址或 URL 規則等第七層的需求時，就會選擇使用 Ingress。 Ingress 最常見的選擇是使用 Nginx，但在雲端的 AKS 就多了 AGIC 的選項，AGIC 是搭配 Azure 的 Azure Application Gateway 運作的，可以直接想像成是 PaaS 版本的 Ingress，本篇將記錄在 AKS 上啟用 AGIC 的過程。 Application Gateway Ingress Control 借用一下官方的 AGIC 架構圖，當我們在 AKS 中啟用 AGIC 後，本質上 AGIC 就是一個在 AKS 內的 Deployment，其 Pod 將監控所有在 AKS 內的 Ingress YAML，並將設定同步到外部的 Application Gateway。 因為監控的 Pod 還是在 AKS 內部，這部分是會佔用到 AKS 效能的，但比起一般自架的 Nginx Ingress，AGIC 負責處理負載均衡的 Application Gateway 還是位於 AKS 外部，這部分就不會佔用到 AKS 本身的資源。 建立 Virtual Network 首先我們先建立一個 10.10.0.0/16 的虛擬網路，並且在其中切出兩個子網段，第一個 10.10.1.0/24 會分配給 AKS 使用。 而第二個子網段給 Application Gateway 使用。 建立 Public IP 接著因為我們會透過 Application Gateway 將 AKS 對外，所以需要一個公用 IP。 建立 Application Gateway 再來就是建立 Application Gateway 了，這邊記得要對應上剛剛建立的子網段與功用 IP。 另外如果沒記錯的話，Application Gateway 使用 Portal UI 創建時會需要設定一堆東西，這些設定在 AGIC 的情境是用不到的，但如果...

在第一篇文章，我們討論了 ACR 中 Manifest 與 Tag 的關係，並了解到沒有 Tag 的 Image 對於管理與費用都會產生不好的影響，隨後在第二篇文章中透過 acr purge 與 az acr task 建立自動清理的排程來處理這些 Image，詳細內容歡迎參考以下系列文章。 接著在進入正式的生產環境時，常見的作法會希望將 ACR 的外網訪問關閉以建立私人的儲存庫，這種情況的 az acr task 就需要另外搭配專用的代理程式集區執行，可惜的是這項功能截至發文為止處於預覽階段，而且更慘的是還不支援我自己常用的東南亞地區 😭 做為替代方案，我們選擇使用 Retention Policy 來清理這些沒有 Tag 的 Image，本篇文章將紀錄關於保留原則的一些限制與設定過程。 系列文章 【Azure Container Registry】Manifests、Tags 與清除垃圾 【Azure Container Registry】使用 acr purge 與 az acr task 自動清理舊版映像 【Azure Container Registry】設定 Retention Policy 自動清理無標籤的映像（本篇） 將 ACR 升級至 Premium  Retention Policy 最大的限制就是只能在 Premium 等級的 ACR 上啟用，不過對於已經考量到需要關閉外網的生產環境來說不是太大的問題，畢竟要在 ACR 上啟用 Private Endpoint 也需要 Premium 的 SKU。 可以直接使用以下 az acr update 指令來將 ACR 升級到 Premium 等級： 啟用 Retention Policy 在 Premium SKU 的 ACR 上就能直接啟用 Retention Policy 了，一樣使用 Azure CLI 來完成。 其中 --days 可以設定要對沒有 Tag 的 Image 保留多久，可以設定 0 到 365 天。 而目前 Retention Policy 只支援清理沒有 Tag 的 Image，也就是 --type UntaggedManifests ，所以目前也只能設定這個值，期待未來會開放更多功能。 回到 Portal 畫面也可以在...