Skip to main content

Command Palette

Search for a command to run...

aws iam 重要概念

Updated
2 min readView as Markdown
aws iam 重要概念

AWS IAM (Identity And Access Management)

  • 是一個用來管理 Resources 權限的 AWS 核心服務

  • Resources 代表是在 AWS 使用者所建立已即可存取的任何 AWS 資源,比如 S3 Bucket or Object

  • 使用者會透過 Action 來描述對該資源執行的動作,比如 S3:CreateBucket

  • 會透過 Policy 來授權每個資源能執行的 Action

Example

image

最基礎的概念是每個 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 存取

Access Key & Secret Access Key

  • Secret 能夠讓使用者與 AWS 互動

image

Policy Statement

  • DynamoDB Table Read Only Access To Specific Columns
{
    "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"}
            }
        }
    ]
}

其他概念

Groups

AWS 有 Groups 概念,可以讓 User 指定到某個 Group , 來讓該 Group 預設的 Policy 可以套用在該使用者。通常是為了方便管理。

image

Roles

Role 的概念是用來給非使用者的執行身分權限的一種方式,比如說 lambda 要執行某個權限,可以 attach 所需要的 policy document 到那個 role 上,再把 lambda 指定為那個 role

Role 的另一種特性是具有可變性,不一定是永久存在的。有一種概念是 assume role ,透過暫時性給定一個 role 給某些執行程式,比如說 gitlab runner 透過 OIDC 取得暫時發佈的 role ,執行完就撤銷該 role,能夠達到安全性上的考量。

image

Trust RelationShips

當遇到有兩個以上的 AWS account 彼此需要跨帳號存取資源時,需要在兩個 AWS account 設定彼此信任對方 account ,並且資源提供者需要建立 assume role 給存取者帳號,讓存取者透過該 assume role 俱備存取的 Policy

舉例如下圖: 假設 account1 有 Dynamodb 資源,需要讓 account2 中的某個 user 或是 app 存取

image

則需要在 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 效果。

84 views

More from this blog

AI 時代下的系統可理解性問題

GAI 的時代下,近一年很流行 Vibe-coding,幾乎人人都在草率地使用 Vibe-coding 一詞來指一系列的軟體工程實踐。它指的是一種開發者不親自手打 coding,而是僅透過自然語言向 AI 描述需求(給出「方向」或「感覺」),完全放手讓 AI 代理去自動生成、拼湊出整個應用程式的開發風格。 然而,在專業的軟體工程領域,這股看似美好的「Vibe」背後,隱藏著極高的安全隱患與系統崩潰危

Aug 24, 20263 min read94
AI 時代下的系統可理解性問題

Get Your Hands Dirty on Clean Architecture CH5 Use Case

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

Jul 2, 20264 min read68
Get Your Hands Dirty on Clean Architecture CH5 Use Case
M

MicroFIRE

75 posts