Iac

昨天我們為每個環境(dev / stag / prod …) 設定一個 aws organization account 今天要使用 terraform 設定 AWS IAM User root 中設定 IAM User 將手動產生的 Administrator 的 IAM User 加到 terraform 中 security 中設定 IAM User security 設定 password policy security 設定 MFA policy iThome 鐵人賽好讀版 賽後文章會整理放到個人的部落格上 http://chechia.net/ 追蹤粉專可以收到文章的主動推播 Accounts & IAM Users 今天要使用 Terraform 設定 IAM Users。 未來所有的 User 都會透過 terraform 設定並管理 Day02 設定的 root account IAM User: Administrator 雖然是手動建立的，我們一樣需要把他匯入到 terraform 中 然而上個 PR 中，我們的 terraform module 中並沒有設定 IAM User 的功能，也就是這段 code 是沒有發揮功能 https://github.com/chechiachang/terragrunt-infrastructure-live-example/pull/1/files#diff-62920ff868733e1c625c23fe7ffd6c93bebd87ae16b865869bf682e29b082a99R54-R67 ...

昨天設定了多個 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. ...