Bài viết này được viết bởi Siarhei Kazhura, Senior Solutions Architect, Serverless.
AWS Step Functions cho phép bạn tích hợp với hơn 220 dịch vụ AWS bằng cách sử dụng các tích hợp tối ưu hóa (cho các dịch vụ như AWS Lambda) và các tích hợp SDK của AWS. Những khả năng này cung cấp khả năng xây dựng các giải pháp mạnh mẽ bằng cách sử dụng AWS Step Functions làm động cơ đằng sau giải pháp.
Nhiều khách hàng đang sử dụng nhiều tài khoản AWS cho việc phát triển ứng dụng. Cho đến nay, khách hàng đã phải dựa vào chính sách dựa trên tài nguyên để làm cho truy cập đa tài khoản cho Step Functions có thể. Với chính sách dựa trên tài nguyên, bạn có thể chỉ định ai có quyền truy cập vào tài nguyên và những hành động gì mà họ có thể thực hiện trên nó.
Không phải tất cả các dịch vụ AWS đều hỗ trợ chính sách dựa trên tài nguyên. Ví dụ, có thể kích hoạt truy cập đa tài khoản thông qua chính sách dựa trên tài nguyên với các dịch vụ như AWS Lambda, Amazon SQS, hoặc Amazon SNS.. Tuy nhiên, các dịch vụ như Amazon DynamoDB không hỗ trợ chính sách dựa trên tài nguyên, vì vậy quy trình làm việc của bạn chỉ có thể sử dụng tích hợp trực tiếp của Step Functions nếu nó thuộc cùng một tài khoản.
Bây giờ, khách hàng có thể tận dụng chính sách dựa trên danh tính trong Step Functions để quy trình làm việc của bạn có thể trực tiếp kích hoạt tài nguyên trong các tài khoản AWS khác, do đó cho phép tích hợp API dịch vụ trên đa tài khoản.
Tổng quan
Ví dụ này mô tả cách sử dụng khả năng truy cập giữa các tài khoản khác nhau sử dụng hai tài khoản AWS:
- Một tài khoản AWS được tin cậy (ID tài khoản là 111111111111) với một luồng công việc Step Functions có tên SecretCacheConsumerWfw và một role IAM có tên là TrustedAccountRl.
- Một tài khoản AWS tin tưởng (ID tài khoản là 222222222222) với một luồng công việc Step Functions có tên SecretCacheWfw và hai role IAM có tên là TrustingAccountRl và SecretCacheWfwRl.
Ở mức cao:
- Luồng công việc SecretCacheConsumerWfw chạy dưới role TrustedAccountRl trong tài khoản 111111111111. role TrustedAccountRl có quyền giả định role TrustingAccountRl từ tài khoản 222222222222.
- Nhiệm vụ FetchConfiguration của Step Functions lấy ARN của role TrustingAccountRl, ARN của luồng công việc SecretCacheWfw và ARN của bí mật (tất cả các tài nguyên này thuộc về tài khoản AWS đang được tin tưởng).
- Nhiệm vụ GetSecretCrossAccount của Step Functions có trường Credentials với ARN của role TrustingAccountRl được chỉ định (lấy được trong bước 2).
- Nhiệm vụ GetSecretCrossAccount giả định role TrustingAccountRl trong quá trình thực thi luồng công việc SecretCacheConsumerWfw.
- Luồng công việc SecretCacheWfw (thuộc tài khoản 222222222222) được kích hoạt bởi luồng công việc SecretCacheConsumerWfw dưới role TrustingAccountRl.
- Kết quả được trả về cho luồng công việc SecretCacheConsumerWfw thuộc tài khoản 111111111111.
Định nghĩa luồng công việc SecretCacheConsumerWfw chỉ định trường Credentials và RoleArn. Điều này cho phép bước GetSecretCrossAccount giả định một role IAM thuộc một tài khoản AWS riêng biệt:
JSON
{
“StartAt”: “FetchConfiguration”,
“States”: {
“FetchConfiguration”: {
“Type”: “Task”,
“Next”: “GetSecretCrossAccount”,
“Parameters”: {
“Name”: “<ConfigurationParameterName>”
},
“Resource”: “arn:aws:states:::aws-sdk:ssm:getParameter”,
“ResultPath”: “$.Configuration”,
“ResultSelector”: {
“Params.$”: “States.StringToJson($.Parameter.Value)”
}
},
“GetSecretCrossAccount”: {
“End”: true,
“Type”: “Task”,
“ResultSelector”: {
“Secret.$”: “States.StringToJson($.Output)”
},
“Resource”: “arn:aws:states:::aws-sdk:sfn:startSyncExecution”,
“Credentials”: {
“RoleArn.$”: “$.Configuration.Params.trustingAccountRoleArn”
},
“Parameters”: {
“Input.$”: “$.Configuration.Params.secret”,
“StateMachineArn.$”: “$.Configuration.Params.trustingAccountWorkflowArn”
}
}
}
}
Phân quyền
Ở mức cao nhất:
- role TrustedAccountRl thuộc tài khoản 111111111111.
- role TrustingAccountRl thuộc tài khoản 222222222222.
- Đã thiết lập quan hệ tin cậy giữa TrustedAccountRl và role TrustingAccountRl.
- Quá trình thực hiện workflow SecretCacheConsumerWfw được thực thi dưới role TrustedAccountRl trong tài khoản 111111111111.
- Quá trình thực hiện workflow SecretCacheWfw được thực thi dưới role SecretCacheWfwRl trong tài khoản 222222222222.
role TrustedAccountRl (1) đã thiết lập chính sách tin cậy sau đây cho phép workflow SecretCacheConsumerWfw giả định (4) role.
JSON
{
“RoleName”: “<TRUSTED_ACCOUNT_ROLE_NAME>”,
“AssumeRolePolicyDocument”: {
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Principal”: {
“Service”: “states.<REGION>.amazonaws.com”
},
“Action”: “sts:AssumeRole”
}
]
}
}
role TrustedAccountRl (1) được cấu hình với các quyền cho phép nó đảm nhận (3) role TrustingAccountRl (2).
JSON
{
“RoleName”: “<TRUSTED_ACCOUNT_ROLE_NAME>”,
“PolicyDocument”: {
“Version”: “2012-10-17”,
“Statement”: [
{
“Action”: “sts:AssumeRole”,
“Resource”: “arn:aws:iam::<TRUSTING_ACCOUNT>:role/<TRUSTING_ACCOUNT_ROLE_NAME>”,
“Effect”: “Allow”
}
]
}
}
role TrustedAccountRl (1) được cấu hình với các quyền cho phép nó truy cập vào Parameter Store, một khả năng của AWS Systems Manager, và lấy cấu hình cần thiết.
JSON
{
“RoleName”: “<TRUSTED_ACCOUNT_ROLE_NAME>”,
“PolicyDocument”: {
“Version”: “2012-10-17”,
“Statement”: [
{
“Action”: [
“ssm:DescribeParameters”,
“ssm:GetParameter”,
“ssm:GetParameterHistory”,
“ssm:GetParameters”
],
“Resource”: “arn:aws:ssm:<REGION>:<TRUSTED_ACCOUNT>:parameter/<CONFIGURATION_PARAM_NAME>”,
“Effect”: “Allow”
}
]
}
}
role TrustingAccountRl (2) có chính sách tin cậy sau đây cho phép nó được đảm nhận (3) bởi role TrustedAccountRl (1). Chú ý cài đặt trường Condition. Trường này cho phép chúng ta kiểm soát chính xác tài khoản và máy trạng thái nào có thể đảm nhận role TrustingAccountRl, ngăn ngừa vấn đề confused deputy.
JSON
{
“RoleName”: “<TRUSTING_ACCOUNT_ROLE_NAME>”,
“AssumeRolePolicyDocument”: {
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Principal”: {
“AWS”: “arn:aws:iam::<TRUSTED_ACCOUNT>:role/<TRUSTED_ACCOUNT_ROLE_NAME>”
},
“Action”: “sts:AssumeRole”,
“Condition”: {
“StringEquals”: {
“sts:ExternalId”: “arn:aws:states:<REGION>:<TRUSTED_ACCOUNT>:stateMachine:<CACHE_CONSUMER_WORKFLOW_NAME>”
}
}
}
]
role TrustingAccountRl (2) được cấu hình với các quyền cho phép nó bắt đầu thực hiện các tác vụ của Step Functions Express Workflows một cách đồng bộ. Khả năng này là cần thiết vì workflow SecretCacheWfw được gọi bởi workflow SecretCacheConsumerWfw dưới role TrustingAccountRl thông qua cuộc gọi API StartSyncExecution.
JSON
{
“RoleName”: “<TRUSTING_ACCOUNT_ROLE_NAME>”,
“PolicyDocument”: {
“Version”: “2012-10-17”,
“Statement”: [
{
“Action”: “states:StartSyncExecution”,
“Resource”: “arn:aws:states:<REGION>:<TRUSTING_ACCOUNT>:stateMachine:<SECRET_CACHE_WORKFLOW_NAME>”,
“Effect”: “Allow”
}
]
}
}
Workflow SecretCacheWfw đang chạy dưới danh tính riêng – role SecretCacheWfwRl. role này có các quyền cho phép nó lấy thông tin bí mật từ AWS Secrets Manager, đọc / ghi vào bảng DynamoDB và gọi các chức năng Lambda.
JSON
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Action”: [
“secretsmanager:getSecretValue”,
],
“Resource”: “arn:aws:secretsmanager:<REGION>:<TRUSTING_ACCOUNT>:secret:*”,
“Effect”: “Allow”
},
{
“Action”: “dynamodb:GetItem”,
“Resource”: “arn:aws:dynamodb:<REGION>:<TRUSTING_ACCOUNT>:table/<SECRET_CACHE_DDB_TABLE_NAME>”,
“Effect”: “Allow”
},
{
“Action”: “lambda:InvokeFunction”,
“Resource”: [
“arn:aws:lambda:<REGION>:<TRUSTING_ACCOUNT>:function:<CACHE_SECRET_FUNCTION_NAME>”,
“arn:aws:lambda:<REGION>:<TRUSTING_ACCOUNT>:function:<CACHE_SECRET_FUNCTION_NAME>:*”
],
“Effect”: “Allow”
}
]
}
So sánh với các chính sách dựa trên tài nguyên
Để triển khai giải pháp trên bằng cách sử dụng các chính sách dựa trên tài nguyên, bạn phải đặt SecretCacheWfw phía trước một tài nguyên hỗ trợ các chính sách dựa trên tài nguyên. Bạn có thể sử dụng Lambda cho mục đích này. Một chức năng Lambda có một chính sách quyền hạn tài nguyên cho phép truy cập bởi SecretCacheConsumerWfw workflow.
Hàm trung gian gọi cho SecretCacheWfw, đợi cho quy trình hoàn thành (gọi đồng bộ), và trả kết quả trở lại SecretCacheConsumerWfw. Tuy nhiên, phương pháp này có một số nhược điểm:
- Chi phí phát sinh thêm: Với Lambda, bạn phải trả phí dựa trên số lượng yêu cầu cho chức năng của mình và thời lượng chạy mã.
- Phải bảo trì thêm mã: Mã phải lấy dữ liệu từ SecretCacheConsumerWfw workflow và chuyển nó đến SecretCacheWfw workflow.
- Không có khả năng xử lý lỗi tự động: Mã phải xử lý lỗi một cách chính xác, thử lại yêu cầu trong trường hợp lỗi tạm thời, cung cấp khả năng thời gian ngưng lũng mũi tên và cung cấp một trình ngắt mạch trong trường hợp lỗi liên tục. Khả năng xử lý lỗi được cung cấp một cách tự nhiên bởi Step Functions.
Giải pháp cho phép quyền chính sách dựa trên danh tính cung cấp nhiều lợi ích hơn so với giải pháp quyền chính sách dựa trên tài nguyên trong trường hợp này.
Tuy nhiên, quyền chính sách dựa trên tài nguyên cung cấp một số lợi ích và có thể được sử dụng kết hợp với các chính sách dựa trên danh tính. Chính sách dựa trên danh tính và chính sách dựa trên tài nguyên đều là các chính sách cho phép và được đánh giá cùng nhau:
- Điểm vào duy nhất: Chính sách dựa trên tài nguyên được đính kèm vào một tài nguyên. Với các chính sách quyền hạn dựa trên tài nguyên, bạn kiểm soát những danh tính không thuộc tài khoản AWS của bạn có quyền truy cập tài nguyên ở mức tài nguyên. Điều này cho phép dễ dàng suy luận về danh tính nào có quyền truy cập vào tài nguyên. Công cụ AWS Identity and Access Management Access Analyzer có thể giúp cho các chính sách dựa trên danh tính bằng cách cung cấp khả năng xác định các tài nguyên được chia sẻ với một danh tính bên ngoài.
- Người chủ yếu truy cập tài nguyên thông qua chính sách dựa trên tài nguyên vẫn hoạt động trong tài khoản được tin tưởng và không cần phải cấp quyền hạn để nhận quyền hạn của role qua tài khoản giao giữa. Trong ví dụ này, SecretCacheConsumerWfw vẫn chạy dưới role TrustedAccountRl và không cần phải giả định một role IAM trong tài khoản AWS đang tin tưởng để truy cập vào hàm Lambda.
Tham khảo bài viết về cách role IAM khác với chính sách dựa trên tài nguyên để biết thêm thông tin.
Hướng dẫn triển khai giải pháp
Để theo dõi hướng dẫn triển khai giải pháp, truy cập vào kho giải pháp. Hướng dẫn đi qua các nội dung sau:
- Các yêu cầu tiên quyết cần thiết.
- Hướng dẫn triển khai giải pháp chi tiết.
- Kiểm tra giải pháp.
- Quá trình dọn dẹp.
- Xem xét chi phí.
Kết luận
Bài viết này thể hiện cách tạo một Workflow Express của Step Functions trong một tài khoản và gọi nó từ một Workflow chuẩn của Step Functions trong một tài khoản khác bằng cách sử dụng khả năng thông tin đăng nhập mới của AWS Step Functions. Nó cung cấp một ví dụ về cách thiết lập các role IAM giữa các tài khoản khác nhau để cho phép truy cập. Nó cũng cung cấp một hướng dẫn về cách sử dụng AWS CDK cho TypeScript để triển khai ví dụ.
Để tìm kiếm thêm các tài nguyên học tập về serverless, truy cập Serverless Land.
AWS Study Group 