Terraform

昨天設定了多個 aws organization accounts，但我們還沒有說明為什麼要這樣做 今天會先講 Gruntwork 提出的 Production-Grade Design: multi-account security strategy 拆分多個 account 的用意 多 account 下如何統一管理 IAM User access control 與安全性控管 iThome 鐵人賽好讀版 賽後文章會整理放到個人的部落格上 http://chechia.net/ 追蹤粉專可以收到文章的主動推播 Production-grade Design IAM Gruntwork 提出的 Production-Grade Design: multi-account security strategy，我們這邊一一講解 Root Account 的用途 位於 diagram 圖中的最上層 是整個架構的創世帳號，權限最大 root account 裡面沒有任何 infrastructure 元件， i.e. aws ec2 不會長在裡面，是一個空 account root account 的存取最嚴格 只有很少數的 admin 可以存取 i.e 只有 SRE 部門主管有自己的 IAM User，其他 SRE 沒有權限存取 root account root account 的工作最少 設定 child account 管理 billing IAM policy 管理，不要把 policy 直接綁在 User 上，應該要 ...

今天要使用 terraform 設定 AWS account structure iThome 鐵人賽好讀版 賽後文章會整理放到個人的部落格上 http://chechia.net/ 追蹤粉專可以收到文章的主動推播 – Provision AWS Account 今天要把 aws account 設定完成，並且開始使用 live-repository 來搭建 aws 元件 我們自己的 module repository 開一個權限的 repository fork 我自幹的 modules repository terragrunt-infrastructure-modules https://github.com/chechiachang/terragrunt-infrastructure-modules 上面這個是放 terraform module 的 repository，是兩個 repository 不要跟執行 terragrunt repository 搞混，是兩個 repository https://github.com/chechiachang/terragrunt-infrastructure-live-example 今天的進度與 code base terraform-live-example PR 在此 terragrunt-infrastructure-modules 請直接看 tag v0.0.1 因為有地方嚴重寫錯，我有 force push 東西 :tear:，如果已經提早下載的朋友可能會需要清掉 repository main branch + tag 重拉 orz 對，我們且戰且走常常會這樣，發現昨天寫的東西寫錯臨時改，請大家見諒 為何使用 aws modules X) 因為我們沒有付錢，不能用 gruntwork 的 priviate repository (大誤 ...

今天要使用 terraform 設定 AWS account structure iThome 鐵人賽好讀版 賽後文章會整理放到個人的部落格上 http://chechia.net/ 追蹤粉專可以收到文章的主動推播 – AWS Account structure AWS account structure 是 AWS IAM 提供的 feature 之一，可以讓用戶從一個 account login，然後透過授權操作其他 account 的元件。 然而有這個 feature 不代表用戶就要買單，有實際需求我們才來用 feature。使用 account structure 的理由是什麼？ Account structure 的需求 AWS 官方 whitepaper: 使用 multiple aws account 的好處 依據職務需求將 workload 分組 為不同 environment 設定獨立的 security control 限制敏感資料的存取 提升創新與開發的敏捷 控制事故的影響程度與衝擊 impact 精細的拆分 IT 的工作 成本控管 分散 aws quotas 使用限額與 API rate limit AWS 官方的 organization best practice AWS 官方 OU 管理的 best practice ...

iThome 鐵人賽好讀版 賽後文章會整理放到個人的部落格上 http://chechia.net/ 追蹤粉專可以收到文章的主動推播 – AWS 為例，實現 production framework 的最佳實踐的 30 天 workshop 準備 Production environmtn Devops 面臨的問題 DevOps 的工作內容繁雜 今天想要 Deploy 一個 backend API deployment 到 k8s 上 一轉眼發現自己在修 port / servie / ingress / alb 一轉眼發現自己在修 tls certificate 一轉眼發現自己在修 node linux 上的一個 bug 一轉眼發現自己在修 monitoring / metrics + alert / log collection … 我只是想 deploy 一個 backend deployment 修infra 花了好幾天，而寫 deployment 只要 2 hr Devops 的工作，是處理 developer 與 operator 中間的繁雜的細節 換個角度思考：上面這些元件全都是存在許久的功能，應該有一套統一介面隨叫即用這些服務，ex. ...

Titleq 從零導入 Policy as Code 到 terraform 甘苦談 - Introducing policy as code for terraform Presentation Google Slides Description Terraform 是一個很棒的 Infrastructure as Code 的工具，能夠以現代的軟體工程流程來穩定的建構 infrastructure，並隨著需求變更自動化迭代，將新的 feature 安全地更新到既有的 infrastructure 上。只要是 Infrastructure 有關的問題，我一律推薦 Terraform。 這也意味 Terraform 的品質就等於 infrastructure 的品質，好的 terraform 帶你上天堂，不好的 terraform 全 team 火葬場。 Infrastructure 有太多資安的考量，新的風險不斷被檢查出來，連帶要不斷的 patch terraform code 來避免潛在的資安風險 Infrastructure 會不斷地更新，例如公有雲的 api 不斷更新，去年的 code 已經跟不上今年的最佳實踐了 好的工程師寫出的 terraform code 屌打菜鳥工程師，要如何讓團隊依循更好的實踐，避免寫出爛 code 維護 code 有 clean code / best practice，Terraform 也有 clean code 與 best practice，工程師要如何工具來輔助，是 Policy as Code 的一大課題。 本演講聚焦於實際經驗，從一大堆 terraform modules 開始，沒有 Policy as Code，到一步步評估、導入、實作、改進與迭代，逐漸的提升團隊 Terraform code 品質，提升 infrastructure 交付品質，並避免到未來潛在的風險。 ...