Tìm hiểu về AWS Organization. Khi nào sử dụng AWS Organization?

Phân biệt AWS Organization Account và IAM User

Đừng nhầm lẫn giữa hai khái niệm Account và User khi sử dụng AWS:

  • Account là tài khoản root của bạn để bạn đăng nhập vào AWSaccount luôn có email và thẻ credit đính kèm.
  • User là tài khoản mà account của bạn tạo ra và phân phát cho người khác dùng. User không cần email, chỉ cần username và password.

=> Account chính là tài khoản để tạo và quản lý nhiều User trong AWS.

Xem thêm về IAM tại đây.

Thông thường, khi chúng ta đăng ký sử dụng AWS ta chỉ đăng ký một root account và sau đó từ root account này tạo ra một root IAM User, ta thường đăng nhập vào AWS console bằng root IAM User (chứ không bằng root account) và tạo ra nhiều IAM User khác cho những engineer khác sử dụng. Root account chỉ được sử dụng khi cần setting những thứ có quyền cao nhất, hoặc để chi trả tiền chi phí mà thôi. Khi bạn đăng ký root account trên AWS, bắt buộc bạn phải nhập thẻ credit vào, còn IAM User thì chỉ cần tạo ra username và password là xong.

Như vậy, trong trường hợp, bạn muốn có những account khác nhau để quản lý các AWS khác nhau nhằm mục đích phân chia rạch ròi, bảo mật,… các ứng dụng hay phòng ban thì bạn thường sẽ làm gì?

Ta không thể sử dụng IAM Group cho mục đích trên được vì IAM chỉ là nơi để quản lý các quyền hạn, không phải là nơi để phân cấp các dịch vụ. Và IAM Group không thể chứa các IAM Group con và không thể quản lý các khoản thanh toán riêng biệt được. Đây là những vấn đề liên quan tới tổ chức chứ không liên quan tới phân quyền.

Ta có thể đăng ký AWS bằng nhiều account với nhiều email khác nhau, khi cần sử dụng dịch vụ hoặc phòng ban nào đó, ta sẽ đăng nhập vào account tương ứng để sử dụng. Làm như thế sẽ rất mất công logout rồi login nhiều lần khác nhau, vấn đề thanh toán tiền cũng bị hoàn toàn tách biệt nhau.

=> AWS Organization chính là lựa chọn cho bạn.

2. AWS Organization dùng để làm gì?

AWS Organization là nơi quản lý các account, các account này chỉ có một hoặc một nhóm người có quyền hạn cao nhất quản lý, không phải là IAM User mà các developer sử dụng để thao tác với AWS.

Mục đích của AWS Organization như mình đã nói ở trên, để phân chia quản lý theo phòng bạn, dịch vụ, môi trường vận hành,…

Bài toán ví dụ: Công ty của bạn có 2 team khá to là Team A và Team B, mỗi team lại có nhiều engineer sử dụng AWS để phát triển sản phẩm, mỗi team có 2 product là Product A1, Product A2, Product B1 và Product B2, mỗi product lại có 3 môi trường là prodstaging và dev.

Về phía quản lý, bạn muốn những điều sau:

  • Bạn muốn 2 team phải được quản lý riêng biệt, thanh toán chi phí cho AWS riêng biệt nhưng vẫn gộp được lại ở account cao nhất của bạn để thanh toán 1 lần. Điều này giúp việc kiểm toán của công ty được dễ dàng hơn.
  • Bạn cũng muốn rằng việc thay đổi qua lại các account cũng phải nhanh chóng tiện lợi chứ không logout rồi login như cách thông thường nói phía trên.

Về phía các team, họ sẽ muốn những điều sau:

  • Bạn có thể thiết lập để User làm việc với môi trường prod có full quyền với staging và devUser làm việc với staging có full quyền với dev nhưng không có quyền truy cập prodUser làm việc với dev không có quyền truy cập staging và prod.
  • Team A không được nhìn thấy và thao tác với các tài nguyên của Team B nếu không được cho phép và ngược lại.

Với những điều kiện trên, bạn có nghĩ rằng sử dụng IAM Group là được?

IAM Group sẽ không thoả mãn những yêu cầu sau:

  • Quản lý 2 team riêng biệt, quản lý thanh toán riêng biệt.
  • IAM Group mục đích là để phân chia quyền, tức là ở mức độ thao tác chứ không phải ở mức độ quản lý. Nhìn từ phía người quản lý AWS Organization mới là lựa chọn thích hợp.

AWS Organization sẽ giúp bạn thoả mãn các điều kiện trên, nó là nơi quản lý các account, các Organizational Unit (OU) (là Team A, Team B mình nói ở trên) có thể chứa nhiều account khác nhau. Mỗi account phải có một email riêng biệt, các công ty thường lấy chung một địa chỉ email với các prefix khác nhau, ví dụ aws-teamA-productA1-dev@daovanhung.com và aws-teamA-productA1-prod@daovanhung.com chẳng hạn.

Vậy ta sẽ thiết kế AWS Organization như thế nào trong trường hợp này?

Trước khi tới thiết kế, ta cần xem qua hoạt động của AWS Organization.

3. Cách hoạt động của AWS Organization

3.1. AWS Organization có xung đột quyền với IAM hay không?

Một câu hỏi đặt ra là nếu AWS Organization cũng phân chia quyền thì IAM để làm gì và 2 bên có xảy ra xung đột nhau không?

IAM dùng để tạo và gán quyền ở mức tế bào, IAM có thể gán cho userservice,… AWS Organization nhìn từ phía quản lý để phân quyền, như VD trên thì TeamA không được truy cập vào tài nguyên của TeamB và ngược lại.

AWS Organization và IAM phải giao với nhau thì mới có thể sử dụng được. Nếu IAM có cấp quyền cho TeamA sử dụng tài nguyên nào đó của TeamB nhưng AWS Organization không cho phép thì cũng không thể. Và, dù AWS Organization có cho TeamA truy cập tài nguyên của TeamB nhưng IAM không cho phép cũng không thể. 

Tóm lại là AWS Organization và IAM phải giao nhau.

Với cách hoạt động như vậy, dù cho user có vô thức cấp quyền cho user khác đi chăng nữa, user khác đó cũng sẽ cũng không truy cập được vào nếu như AWS Organization không cho phép. Điều này giúp cho vấn đề bảo mật được chặt chẽ hơn, vì user làm việc với IAM rất nhiều và người quản lý không quản lý được mọi hoạt động của các user.

3.2. Quản lý thừa kế nhau

AWS Organization có thể gán quyền cho organization rootorganizationl unit (OU) hoặc account:

  • Khi gán quyền cho organization root, mọi OU và account trong organization đó sẽ thừa kế quyền đó.
  • Khi gán quyền cho một OU, những OU và account nằm trong OU đó sẽ thừa kế quyền đó.
  • Khi gán quyền cho một account, quyền đó chỉ tác động duy nhất tới account đó.

  Với những cách hoạt động trên, ta có thể thiết kế AWS Organization như sau: 

4. Thiết kế

Với bài toán đặt ra ở phần trên, ta có thể thiết kế AWS Organization như sau:

Mỗi OU trên biểu đồ trên sẽ có ít nhất một account nằm trong đó, account với email mình ghi ở một bên của OU.

Account nằm trong OU con sẽ thừa hưởng mọi quyền của OU cha ông phía trên. Ví dụ, OU prod trong productB1 sẽ có mọi quyền được gán cho OU staging, dev, productB1, teamB. Nhưng ở chiều đi xuống,  account nằm trong teamB sẽ không có quyền hạn của các OU product B1 và product B2 trở xuống dưới. Lưu ý rằng, mặc định các account sẽ không thấy tài nguyên của nhau, nếu bạn muốn share tài nguyên từ dev lên staging rồi lên prod thì bạn phải cấu hình share tài nguyên (có thể sử dụng AWS RAM hoặc S3 cross-account).

OU teamA và teamB nằm ở 2 nhánh khác nhau nên sẽ không có quyền gì của nhau, TeamA không thể nhìn thấy và truy cập vào tài nguyên của TeamB và ngược lại.

Với thiết kế như trên, khi TeamB muốn bạn cấp cho một user để sử dụng Product B2 trong môi trường dev thì bạn sẽ switch role sang account có email là aws-teamB-productB2-dev@daovanhung.com để tạo ra một IAM user phù hợp với yêu cầu của TeamB.

Cách switch account trong AWS Organization sẽ trình bày ở một bài khác nếu có dịp. Switch account trong AWS Organization sẽ không mất công logout login khi bạn tạo nhiều account như cách truyền thống.

Nếu bạn không cần phân cấp thừa kế policy từ dev->staging->prod thì cũng có thể thiết kế như sau:

Bài này chỉ trong phạm vi giới thiệu và trình bày lý thuyết về AWS Organization. Phần thực hành sẽ viết ở một bài khác.

Tham khảo:

https://cloudonaut.io/aws-account-structure-think-twice-before-using-aws-organizations/

https://daovanhung.com/post/khi-nao-thi-su-dung-aws-organization

Leave a Reply

Your email address will not be published. Required fields are marked *