AWS Resource Access Manager (RAM)
There is also an alternative for sharing resources across multiple accounts.
AWS RAM is a central service that allows you to share resources you own in one account with multiple accounts either within your own AWS OU or beyond. There is one caveat, though: you cannot share all types of AWS resources with RAM as only a limited set is supported.
Note
For a list of shareable resources, check the documentation at https://packt.link/qEeQE.
That said, for those supported resources it is a convenient and easy way to share resources across your entire organization or with specific AWS accounts. It works quite simply. AWS RAM allows you to share resources in one account with a set of principals. Such principals can be individual AWS accounts, the member accounts of an organization, an OU in AWS Organizations, or even individual IAM entities (users or roles). It is worth noting that when you share resources within an organization that has resource sharing enabled, principals in your organization immediately get access to the shared resources. AWS RAM does not send them an invitation in this case. However, when you share resources in a standalone AWS account or in an organization without resource sharing enabled, AWS RAM would send the principals an invitation that they must accept to gain access to the shared resources.
This is a widespread approach among complex organizations since they often need to share resources located in and managed from a central AWS account with multiple AWS accounts (for instance, EC2 images, Route 53 Domain Name System (DNS) forwarding rules, AWS Transit Gateway, and more).
So far, you have covered IAM, how to leverage it to establish granular access control on AWS resources, and how to delegate access when you need either additional permissions on a temporary basis or access resources in a different AWS account. You will now investigate a security mechanism that enables organizations to reuse their existing IdP(s) to access AWS—namely, the concept of user federation.
It is only natural for organizations to want to reuse their existing IdPs to give their workforce, customers, or partners access to AWS without having to create and manage a separate set of identities on AWS. This avoids multiplying long-lived security credentials unnecessarily and, as such, limits the security risks. You can leverage either AWS Single Sign-On (AWS SSO) or AWS IAM to enable user federation depending on the use case.
AWS SSO is well suited for cases where you want to establish user federation across multiple AWS accounts and leverage your existing corporate or a third-party IdP. You can then assign permissions to your users based on their group membership in your IdP’s directory and control access by modifying users and groups on your IdP. You can also implement ABAC, whether via the user information synchronized with your IdP via System for Cross-domain Identity Management (SCIM) or by passing user attributes in Security Assertion Markup Language 2.0 (SAML 2.0) assertions.
You can also use AWS IAM for user federation with individual accounts. IAM is well suited to cases where, for instance, you want to use separate IdPs for different accounts—in some cases, your corporate IdP, and in others, a third-party OpenID Connect (OIDC) IdP. You can also implement ABAC by passing user attributes in SAML 2.0 assertions.
In both cases, if you use an ABAC approach you can easily change, add, or revoke user permissions by changing the user attributes centrally in your IdP. Whether these attributes get synchronized through SCIM or are passed in SAML 2.0 assertions, AWS SSO will pass them as session tags, which are temporary tags that remain valid for the duration of the federated session you establish. As you also saw previously, you can then use these session tags to filter access to AWS resources by using conditions within IAM policies.
So far, you have covered IAM, how to leverage it to establish granular access control on AWS resources, and how to delegate access when you need either additional permissions on a temporary basis or to access resources in a different AWS account and user federation to leverage your existing IdPs for authentication. The last part of your journey through authentication and authorization mechanisms on AWS will take you to the directory service provided by AWS: AWS Directory Service.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
