</>Học Dev
Bài học

Tuần 1 - Ngày 4: IAM và Lake Formation cơ bản cho Data

Tuần 1 – Ngày 4

Mục tiêu học tập

  • Ôn nhanh IAM: policy evaluation, role, resource-based policy trong ngữ cảnh data
  • Hiểu pattern IAM Role cho data services (Glue, Lambda, Redshift, Firehose)
  • Nắm mô hình quyền của Lake Formation và khác biệt với IAM-only
  • Viết được S3 bucket policy / IAM policy cơ bản cho data pipeline

1. IAM ôn tập nhanh (góc nhìn data)

Policy evaluation

RequestExplicitDENY?TCHIkhôngExplicitALLOW?CHOPHÉPkhôngDefaultDENY(implicit)
  • Explicit Deny luôn thắng — nhớ khi debug "vì sao Glue job bị AccessDenied dù đã Allow"
  • Với cross-account: cần cả hai phía cho phép (identity policy bên gọi + resource policy bên tài nguyên)

IAM Role — pattern chuẩn cho mọi data service

Không bao giờ hard-code access key. Mỗi service assume một role qua trust policy:

ServiceRole điển hìnhTrust principal
Glue job/crawlerGlueServiceRole (đọc S3, ghi catalog, logs)glue.amazonaws.com
LambdaExecution rolelambda.amazonaws.com
RedshiftRole để COPY/UNLOAD từ S3, Spectrumredshift.amazonaws.com
FirehoseRole ghi S3/OpenSearch, gọi Lambda transformfirehose.amazonaws.com
EMRService role + EC2 instance profileelasticmapreduce.amazonaws.com
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "glue.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}

Ví dụ policy cho Glue job đọc raw, ghi curated

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadRaw",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::datalake-raw",
        "arn:aws:s3:::datalake-raw/*"
      ]
    },
    {
      "Sid": "WriteCurated",
      "Effect": "Allow",
      "Action": ["s3:PutObject"],
      "Resource": "arn:aws:s3:::datalake-curated/sales/*"
    }
  ]
}

Lưu ý hay thi: s3:ListBucket áp trên bucket ARN, còn GetObject/PutObject áp trên object ARN (/*). Nhầm chỗ này gây AccessDenied kinh điển.

2. Giới hạn của IAM-only với data lake

Với IAM + S3 bucket policy thuần:

  • Quyền cấp theo bucket/prefix/object — không hiểu khái niệm database/table/column
  • Muốn cho phép "đọc bảng sales nhưng ẩn cột email" → không làm được
  • Mỗi engine (Athena, Redshift Spectrum, EMR, Glue) phải cấu hình quyền S3 + Catalog riêng → dễ lệch nhau
  • Chia sẻ cross-account bằng bucket policy phức tạp và thô

AWS Lake Formation giải quyết: tầng permission tập trung theo ngữ nghĩa database / table / column / row / cell trên Glue Data Catalog.

3. Lake Formation — mô hình cơ bản

Kiến trúc

DatalakeLakeFormationadmin(permissions:DB/table/column/row+LF-tags)enforcekhitruycpquaAthenaRedshiftSpectrumGlue/EMRGlueDataCatalog+S3(registeredlocation)

Các bước thiết lập

  1. Register S3 location: đăng ký bucket/prefix với Lake Formation, kèm một IAM role để LF cấp credential thay mặt (vended credentials)
  2. Data lake administrator: user/role quản trị quyền
  3. Grant permissions: GRANT SELECT ON TABLE sales TO <principal> — theo database, table, column (include/exclude), hoặc data filter (row-level)
  4. Query engine (Athena/Spectrum/EMR/Glue) khi truy cập sẽ được LF kiểm tra quyền và cấp temporary credentials xuống đúng dữ liệu được phép

IAMAllowedPrincipals — chế độ tương thích

Mặc định catalog mới có nhóm IAMAllowedPrincipals = "ai được IAM cho phép thì Lake Formation cho qua" (backward compatible). Muốn LF thực sự enforce fine-grained: thu hồi IAMAllowedPrincipals trên database/table đó. Đây là điểm hay gặp khi "đã grant LF mà ai cũng vẫn đọc được".

So sánh nhanh

IAM + bucket policyLake Formation
Đơn vị quyềnBucket/prefix/objectDatabase/table/column/row/cell
Quản lý tập trung đa engineKhông
Column-level securityKhông
Row-level (data filters)Không
Cross-account sharingBucket policy phức tạpGrant + AWS RAM, gọn hơn
Phù hợpPipeline nội bộ đơn giảnData lake nhiều team/nhiều engine

(LF-tags và cross-account chi tiết học ở Tuần 7.)

4. Các pattern quyền hay gặp trong đề

  1. Analyst chỉ được xem một số cột → Lake Formation column-level permissions (exclude cột PII), không phải IAM
  2. Mỗi country team chỉ thấy row nước mình → Lake Formation data filter (row-level security)
  3. Glue job AccessDenied khi ghi S3 → kiểm tra role của job: thiếu s3:PutObject đúng prefix, hoặc bucket dùng KMS mà role thiếu kms:GenerateDataKey/kms:Decrypt
  4. Cross-account đọc bucket → bucket policy (bên A) cho phép principal bên B identity policy bên B cho phép hành động — thiếu một trong hai là fail
  5. Credential trong code → luôn sai; đáp án đúng là IAM Role (hoặc Secrets Manager cho credential DB bên ngoài)

Câu hỏi ôn tập

  1. Glue job bị AccessDenied khi ghi vào bucket mã hóa SSE-KMS dù policy đã có s3:PutObject. Thiếu gì?

    Xem đáp án

    Thiếu quyền KMS trên key của bucket: tối thiểu kms:GenerateDataKey (để mã hóa khi ghi) và kms:Decrypt (khi đọc). Với SSE-KMS, mọi thao tác object đều gọi KMS bằng credential của caller — key policy hoặc IAM policy của role Glue phải cho phép các action này trên đúng key ARN.

  2. Yêu cầu: analyst được query bảng customers nhưng không được thấy cột email, phone. Dùng dịch vụ nào?

    Xem đáp án

    Lake Formation column-level permissions — grant SELECT trên bảng với column list loại trừ email, phone. IAM/S3 policy không thể enforce theo cột vì chỉ hiểu object. Athena/Redshift Spectrum/EMR đều tôn trọng quyền LF khi bảng thuộc registered location.

  3. Đã grant Lake Formation SELECT cho một analyst, nhưng user khác không được grant vẫn query được bảng. Vì sao?

    Xem đáp án

    Database/table còn gắn nhóm IAMAllowedPrincipals (chế độ tương thích mặc định): bất kỳ ai được IAM cho phép Glue/Athena/S3 vẫn truy cập được, LF chưa thực sự enforce. Cần revoke IAMAllowedPrincipals trên resource đó (và điều chỉnh Data Catalog settings cho DB mới) để chuyển hẳn sang mô hình Lake Formation.

  4. Sự khác nhau giữa s3:ListBuckets3:GetObject về Resource trong policy?

    Xem đáp án

    s3:ListBucket là hành động trên bucket → Resource là arn:aws:s3:::bucket-name. s3:GetObject/s3:PutObject là hành động trên object → Resource là arn:aws:s3:::bucket-name/* (hoặc prefix cụ thể). Viết lẫn hai loại vào một Resource sai là nguyên nhân AccessDenied phổ biến nhất với data pipeline.

  5. Ứng dụng cần đọc password của database on-premises trong Glue connection. Best practice lưu ở đâu?

    Xem đáp án

    AWS Secrets Manager — lưu credential mã hóa bằng KMS, cấp quyền đọc qua IAM role của Glue, hỗ trợ rotation tự động. Glue connections tích hợp trực tiếp với Secrets Manager. Không đặt password trong job parameters, script hay environment variables plain-text. (SSM Parameter Store SecureString là lựa chọn rẻ hơn khi không cần rotation tự động.)

Bài tập thực hành

  • Tạo IAM role cho Glue với trust policy glue.amazonaws.com + policy đọc/ghi 2 bucket bài trước
  • Bật Lake Formation trong account lab, register S3 location của bucket curated
  • Grant quyền SELECT một bảng cho một IAM user thử nghiệm, thử query qua Athena
  • Đọc Lake Formation permissions overview

Tài liệu tham khảo chính thức


Tiếp theo: Quiz Tuần 1