search

IAM Roles Anywhere là gì? Thành phần và cách hoạt động

calendar_today Đăng ngày: 12/10/2026

IAM Roles Anywhere là dịch vụ của AWS cho phép server, container hoặc ứng dụng chạy ngoài AWS (on-premises, cloud khác) sử dụng IAM Role để truy cập tài nguyên AWS một cách an toàn, mà không cần lưu Access Key và Secret Key trên máy. Ví dụ, bạn có một máy chủ Ubuntu hoặc Windows on-premises cần truy cập S3, Secrets Manager hoặc KMS. Thay vì tạo IAM User rồi lưu Access Key trên máy chủ, bạn có thể sử dụng IAM Roles Anywhere để cấp thông tin xác thực tạm thời cho máy chủ đó.

IAM Roles Anywhere là gì?

IAM Roles Anywhere là một tính năng trong hệ sinh thái AWS IAM, ra mắt năm 2022, cho phép các workload chạy bên ngoài AWS như máy chủ on-premises sử dụng IAM Role để truy cập các dịch vụ AWS như S3, CloudWatch và Secrets Manager thay vì sử dụng IAM User cùng Access Key + Secret Key.

Mỗi máy chủ sẽ được cấp chứng chỉ số X.509. Khi cần truy cập tài nguyên, AWS sẽ kiểm tra chứng chỉ, sau đó cấp thông tin đăng nhập tạm thời gồm Access Key ID, Secret Access Key và Session Token để máy chủ sử dụng. Thông tin đăng nhập này có thời hạn tối đa 1 giờ, hết hạn thì cần lấy thông tin mới để tiếp tục sử dụng.

Các quyền mà máy chủ được phép thực hiện vẫn do IAM Role và IAM Policy quy định. IAM Roles Anywhere không mất phí riêng, nhưng một số dịch vụ đi kèm như AWS Private CA có thể phát sinh chi phí. Giải pháp này giúp giảm nguy cơ lộ thông tin đăng nhập, không phải quản lý và thay đổi Access Key thủ công trên nhiều máy chủ, đồng thời dễ kiểm soát quyền truy cập hơn.

Các thành phần chính của IAM Roles Anywhere là gì?

1. Trust anchor là gì?

Trust anchor là nơi khai báo CA mà AWS tin cậy để xác minh certificate của máy chủ.

Ví dụ: Công ty có một hệ thống cấp chứng chỉ riêng để cấp chứng chỉ cho các máy chủ. Khi cấu hình hệ thống này làm trust anchor trong AWS, AWS sẽ dựa vào đó để kiểm tra chứng chỉ mà máy chủ cung cấp khi muốn truy cập AWS.

Trust anchor có thể sử dụng CA do AWS quản lý (AWS Private CA), CA nội bộ của công ty hoặc chứng chỉ tự ký để thử nghiệm.

Hiểu đơn giản: Trust anchor giống như danh sách các đơn vị cấp giấy tờ mà AWS tin tưởng. Tuy nhiên, có chứng chỉ do đơn vị đáng tin cậy cấp chưa đủ; AWS vẫn cần kiểm tra chứng chỉ có hợp lệ hay không trước khi cho phép máy chủ tiếp tục xác thực.

2. Profile là gì?

Profile là nơi cấu hình máy chủ được phép sử dụng IAM Role nào và credentials có hiệu lực trong bao lâu khi truy cập AWS thông qua IAM Roles Anywhere.

Ví dụ: Máy chủ app-server-01 cần tải file lên S3. Bạn tạo một profile cho phép máy chủ sử dụng role S3UploadRole và đặt thời hạn credentials là 1 giờ. Khi xác thực thành công, máy chủ sẽ nhận credentials tạm thời để thực hiện công việc.

Trong profile, bạn có thể cấu hình danh sách IAM Role được phép sử dụng, giới hạn thêm quyền truy cập, thiết lập thời hạn credentials từ 15 phút đến 1 giờ và bật hoặc tắt profile.

3. IAM Role và trust policy

IAM Role vẫn là role thông thường trong AWS, dùng để xác định máy chủ được phép làm gì, chẳng hạn đọc file S3, ghi log CloudWatch hoặc đọc thông tin từ Secrets Manager.

Điểm khác biệt là Trust Policy phải cho phép IAM Roles Anywhere thay mặt workload sử dụng role đó.

Ví dụ minh họa (chỉ để hiểu khái niệm, không phải bước triển khai):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "rolesanywhere.amazonaws.com" },
      "Action": ["sts:AssumeRole", "sts:TagSession", "sts:SetSourceIdentity"],
      "Condition": {
        "ArnEquals": {
          "aws:SourceArn": "arn:aws:rolesanywhere:ap-southeast-1:111122223333:trust-anchor/EXAMPLE-ID"
        },
        "StringEquals": {
          "aws:PrincipalTag/x509Subject/CN": "app-server-01"
        }
      }
    }
  ]
}

Điểm hay là bạn có thể ràng buộc role vào một trust anchor cụ thể và vào thuộc tính chứng chỉ (như CN). Nhờ vậy không phải chứng chỉ nào cũng assume được mọi role.

4. Chứng chỉ X.509 (end-entity certificate)

Chứng chỉ X.509 có thể hiểu là giấy tờ dùng để chứng minh danh tính của máy chủ khi kết nối với AWS.

Chứng chỉ thường chứa thông tin nhận dạng, thông tin về đơn vị cấp chứng chỉ và thời hạn hiệu lực. Trên máy chủ còn có private key tương ứng để chứng minh rằng máy chủ thực sự sở hữu chứng chỉ đó.

5. Credential helper (aws_signing_helper)

aws_signing_helper là công cụ do AWS cung cấp, được cài đặt trên máy chủ bên ngoài AWS để tự động lấy thông tin đăng nhập tạm thời khi cần truy cập AWS.

Ví dụ, bạn có một máy chủ Ubuntu bên ngoài AWS và muốn dùng AWS CLI để tải file lên S3. Thay vì phải tạo và lưu Access Key cố định trên máy chủ, bạn cấu hình aws_signing_helper để công cụ này sử dụng chứng chỉ của máy chủ xác thực với IAM Roles Anywhere và lấy credentials tạm thời từ AWS. Sau đó, AWS CLI sử dụng credentials đó để tải file lên S3 theo quyền được cấp.

aws_signing_helper có ba cách hoạt động chính:

  • credential-process: AWS CLI tự gọi công cụ để lấy credentials khi cần. Đây là cách phù hợp nếu bạn muốn sử dụng AWS CLI như bình thường.
  • serve: Công cụ tạo một địa chỉ cục bộ để các ứng dụng lấy credentials, tương tự cách máy chủ EC2 lấy thông tin đăng nhập từ metadata service.
  • update: Công cụ cập nhật credentials vào file theo cấu hình.

IAM Roles Anywhere hoạt động như thế nào?

IAM Role Anywhere How to work

Quy trình thực tế:

  1. Bạn tạo hoặc sử dụng một Certificate Authority (CA) để cấp certificate cho máy chủ.
  2. AWS tin cậy CA đó thông qua một cấu hình gọi là Trust Anchor.
  3. Máy chủ sử dụng certificate và private key để yêu cầu credentials thông qua IAM Roles Anywhere.
  4. AWS xác thực yêu cầu và cấp credentials tạm thời cho IAM Role được phép sử dụng.
  5. Máy chủ dùng credentials này để gọi AWS API theo quyền của role.

IAM Roles Anywhere khác gì IAM user access key và các phương án khác?

Đây là bảng so sánh mình hay dùng để chọn giải pháp:

Phương án Loại credentials Phù hợp với Điểm yếu
IAM user + access key Dài hạn, tĩnh Thử nghiệm nhanh, hệ thống cũ Dễ rò rỉ, khó xoay, khó truy vết
IAM Roles Anywhere Tạm thời, dựa trên chứng chỉ X.509 Server/ứng dụng ngoài AWS đã có hoặc có thể xây PKI Phải quản lý vòng đời chứng chỉ
SSM Hybrid Activation Tạm thời, qua SSM Agent Quản lý máy hybrid bằng Systems Manager Gắn với SSM, không phải mọi SDK dùng tiện
OIDC / Web Identity federation Tạm thời, dựa trên token Workload đã có IdP (GitHub Actions, Kubernetes, SPIFFE…) Cần IdP hỗ trợ OIDC
IAM Identity Center (SSO) Tạm thời, cho con người Người dùng đăng nhập CLI/console Không dành cho workload tự động
Role gắn trực tiếp (EC2, ECS, Lambda, EKS Pod Identity) Tạm thời, do AWS cấp Workload chạy trong AWS Không dùng được ngoài AWS

Quy tắc đơn giản mình nhớ:

  • Chạy trong AWS → dùng role gắn trực tiếp.
  • Ngoài AWS, có IdP OIDC sẵn → cân nhắc OIDC federation.
  • Ngoài AWS, có hoặc có thể có PKI → IAM Roles Anywhere.
  • Con người → IAM Identity Center.