IAM & AWS CLI

1 phút đọcSeries: NoteBook: AWS Certified Solutions Architect Associate SAA-C031 lượt xem

New words

  • correspond/ˌkɔːr.əˈspɑːnd/: Tương ứng

IAM: User & Group

  • IAM (Identity And Access Management), là 1 Global Service
  • Root Account được tạo mặc định, account này được khuyến khích không nên sử dụng trực tiếp hay shared nó cho bất kì ai.
  • User trong tố chức của bạn có thể được nhóm lại thành các group
  • Group chỉ chứa User, không chứa group khác
  • User có thể không thuộc Group nào , cũng có thể thuộc nhiều Group

IAM: Permission

  • User và Group có thể được chỉ định có những quyền nhất định (Bằng những JSON Document như hình bên dưới) gọi là các Policy
  • Trong AWS , có một quy tắc cần tuân thủ là least privilege principle, không cung cấp nhiều permisson hơn nhu cầu thực tế

IAM Policy Inheritance

  • User trong cùng 1 Group thì inherit permission của group đó
  • Một User thuộc nhiều Group sẽ kế thừa tất cả các quyền của các Group đó. Ví du bên dưới, David sẽ có các policy kế thừa từ Operation Group và Audit Group

IAM Policy Structure

Cấu trúc của 1 JSON Policy gồm:

  • Version: Policy Language Version, thường là "2020-10-17"
  • Id: Id của Policy (Optional)
  • Statement: Gồm một hoặc nhiều statement (Required)

Statement bao gồm:

  • Sid: Id của Statement (Optional)
  • Effect: Chỉ ra Statement này Allow hay Deny các quyền 
  • Principal: Chỉ ra các account/user/role sẽ bị statement này ảnh hưởng
  • Action: Chỉ ra các hành động mà statement này Allow hay Deny
  • Resourse: Chỉ ra các tài nguyên mà các Princial bị Effect các Action trên nó
  • Condition: Chỉ ra khi nào thì policy này có tác dụng (Optional)

IAM Role của Service

  • Không chỉ có một cá nhân vật lý cần tương tác với AWS Service mà các AWS Service cũng cần phải tuong tác qua lại với nhau
  • Để làm được điều này , cần phải chỉ định permission cho các service bằng IAM Role

So sánh Role và Policy

  • Role là một identity trong AWS với các quyền được xác định bởi policy. Bản chất role là identity , nên nó cũng có thể coi như là 1 IAM User, tuy nhiên, thay vì gắn liền với một người, vai trò này được thiết kế để bất kỳ ai cần cũng có thể đảm nhận. Bạn có thể sử dụng role để phân quyền truy cập cho ứng dụng hoặc các AWS Service khácđể chúng có quyền truy cập vào tài nguyên AWS của bạn
  • Role không có chức năng riêng biệt nào cả, bạn phải gắn các policy vào chúng.
  • Policy xác định role được phép làm gì.

Identity-based policy

  • Là loại policy được gán cho các IAM entity như: IAM user, IAM group hoặc IAM role.
  • Mục đích: Xác định các hành động mà một identity được phép thực hiện trên các AWS resources cụ thể.
  • Gắn ở đâu: Gắn trực tiếp vào identity.
  • Có thể áp dụng cho: Hầu hết các service trong AWS.

Ví dụ: Gán policy cho một IAM role cho phép nó được gọi lambda:InvokeFunction trên một Lambda function nhất định.

{
 "Effect": "Allow",
 "Action": "lambda:InvokeFunction",
 "Resource": "arn:aws:lambda:region:account-id:function:your-function"
}

Note: Identity-based policy chỉ phát huy tác dụng nếu resource cho phép hành động đó từ phía identity. Trong một số trường hợp (như Lambda cross-account invoke), bản thân resource cũng phải “chấp nhận” quyền đó.

Resource-based policy

  • Là loại policy được gắn trực tiếp vào một AWS resource cụ thể, ví dụ như: Lambda function, S3 bucket, SNS topic, SQS queue, v.v.
  • Mục đích: Chỉ định cụ thể các principal (IAM user/role/service) nào được phép thực hiện hành động nào đó lên resource này.
  • Gắn ở đâu: Gắn trực tiếp vào bản thân resource.
  • Khả năng đặc biệt: Hỗ trợ cross-account access (tài khoản A cho phép principal từ tài khoản B thực hiện hành động lên resource trong tài khoản A).

Ví dụ: Gắn resource-based policy vào Lambda function cho phép IAM role từ account khác được invoke:

{
 "Effect": "Allow",
 "Principal": {
   "AWS": "arn:aws:iam::123456789012:role/CrossAccountRole"
 },
 "Action": "lambda:InvokeFunction",
 "Resource": "arn:aws:lambda:region:account-a:function:target-function"
}

Note: Đây là cách duy nhất để resource chấp nhận hành động được thực hiện từ một principal ngoài tài khoản của nó (cross-account). Identity-based policy ở tài khoản khác là không đủ — resource phải explicit "cho phép" điều đó.

Bạn thấy bài này thế nào?