aws iam 重要概念

Search for a command to run...

No comments yet. Be the first to comment.
書本連結 前言 會挑這本書看的人,應該都是關心自己負責專案的軟體架構的人。不只希望開發的軟體能滿足客戶的明確需求,也希望能滿足可維護性(maintainability)的隱性需求,以及自己對結構與美觀習慣的要求。 要能滿足上述這些要求很難,因為專案通常不會按照計畫進行。可能變因有 deadline,最後的 API 與承諾的不同,又或者我們的設計無法很好的貼合需求的變化所需。。因此完美的架構只有在一

我們的 AIOps agent 有個很具體的問題:它會捏造 trace ID。 當 on-call 工程師問「payment service 有沒有 error trace?」,agent 有時會信心滿滿地回答「是的,見 trace a1b2c3d4...」——但這串 ID 根本不存在 Tempo 裡。工程師點進去,404。壞的不只是使用者體驗,而是這讓整個 RCA 結論失去可信度。 另一個問題是

o11y-bench 深入剖析:讓 AI 真正面對 on-call 現場 從任務設計、合成環境、Agent 架構、評分機制到報告輸出,逐一解析這個開放 benchmark 的每個組件——以及 Gemini 3 Flash Preview 的完整實測結果 先說清楚這在解決什麼問題 目前多數 LLM benchmark 測的是「知識」:模型知不知道 PromQL 的語法,知不知道什麼是 p99

臥龍神算奇術完全兵書:從兵法原理到實戰,徹底搞懂奇術機制

稟告主公:此乃司馬懿進呈之兵書,詳解如何以 OpenTelemetry 陣法,令臥龍神算之一舉一動盡在掌握,知糧草消耗、察兵器效能、辨戰報異常,使主公運籌帷幄於大帳之中。 為何需要斥候情報? 司馬懿稟告主公: 臥龍神算(Claude Code)乃當世利器,然若無斥候回報,主公便如蒙眼行軍——兵器耗損幾何、糧草消費幾許、哪路斥候出了差錯,一概不知。臣以為,此乃兵家大忌。 無情報之弊,有四: 軍

是一個用來管理 Resources 權限的 AWS 核心服務
Resources 代表是在 AWS 使用者所建立已即可存取的任何 AWS 資源,比如 S3 Bucket or Object
使用者會透過 Action 來描述對該資源執行的動作,比如 S3:CreateBucket
會透過 Policy 來授權每個資源能執行的 Action

最基礎的概念是每個 user 會有對應的 Policy document
如上圖,如果這個 user 要可以建立 lambda function 則需要這個 user 有被 attach 有建立 lambda function resource 的 policy document 設定
Note: 每個 document 會在 Statement 項目內宣告針對每個 resource 執行某些 actions 的 effect , Effect 可以是 Allow 或 Deny
Effect 預設是 Implicity Deny ,也就是預設是 Deny ,不宣告 Allow 則是 Deny
而如果針對特定 resources 直接宣告 Deny 則稱為 Explicity Deny ,顯示明定哪些資源要 Deny 存取

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ReadOnlyAccess",
"Effect": "Allow",
"Action": [
"dynamodb:BatchGet",
"dynamodb:GetItem",
"dynamodb:Query",
"dynamodb:Scan",
],
"Resource": "arn:aws:dynamodb:*:*:table/MyTable",
"Condition": {
"ForAllValues:StringEquals": {
"dynamodb:Attributes": [
"column-name-1",
"column-name-2",
"column-name-3"
]
},
"StringEqualsIfExists": {"dynamobd:Select": "SPECIFIC_ATTRIBUTES"}
}
}
]
}
AWS 有 Groups 概念,可以讓 User 指定到某個 Group , 來讓該 Group 預設的 Policy 可以套用在該使用者。通常是為了方便管理。

Role 的概念是用來給非使用者的執行身分權限的一種方式,比如說 lambda 要執行某個權限,可以 attach 所需要的 policy document 到那個 role 上,再把 lambda 指定為那個 role
Role 的另一種特性是具有可變性,不一定是永久存在的。有一種概念是 assume role ,透過暫時性給定一個 role 給某些執行程式,比如說 gitlab runner 透過 OIDC 取得暫時發佈的 role ,執行完就撤銷該 role,能夠達到安全性上的考量。

當遇到有兩個以上的 AWS account 彼此需要跨帳號存取資源時,需要在兩個 AWS account 設定彼此信任對方 account ,並且資源提供者需要建立 assume role 給存取者帳號,讓存取者透過該 assume role 俱備存取的 Policy
舉例如下圖: 假設 account1 有 Dynamodb 資源,需要讓 account2 中的某個 user 或是 app 存取

則需要在 account1 設定信任 account 2, account 2 設定信任 account 1, 並且 account1 需要設定具有 dynamodb 存取 policy 的 assume role 給 account 2 的 user 或是 app
要保護 Root account
這個 account 權限最大,儘可能不使用這個 account 去發佈 resource 這個 account 通常只適合用來做帳單管理,或是指派其他 user/role
Effect 權重:當同一個 resource 同時被兩個 Statement 指定,並且 Effect 各別為 'Deny' 與 'Allow',則以 'Deny' 為效果。
儘可能使用最小充分權限給每個 resource ,為了安全性考量。
可以透過 Policy Simulator 來模擬給定的 Policy Statement 效果。