What is AWS IAM? AWS IAM stands for Amazon Web Services (AWS) Identity and Access Management (IAM). AWS IAM provides identity management capabilities for AWS customers by enabling IT administrators to control which users have permission to access various AWS resources and the type of actions they can perform.
AWS IAM leverages three core objects for managing AWS identities and access: Users, Groups, and Permissions. Users represent actual AWS customers and are used to authenticate individual user identities and provision access. Groups are a collection of users, which allow admins to manage multiple users at once. Finally, Permissions determine which AWS resources a particular user or a group of users has permission to access and the actions they can perform.
Why AWS IAM?
The purpose of AWS IAM is to help IT administrators manage AWS user identities and their varying levels of access to AWS resources. For example, AWS users can be created and assigned individual security credentials (e.g. passphrases, SSH keys, MFA), granted permission to access AWS, or removed at any time.
In doing so, organizations gain granular control over who has permission to access their AWS resources, which resources are available, and the actions authorized users can perform within their provisioned resources.
The result is a more secure and efficient approach for connecting AWS users to the AWS resources they need to succeed. With 90+ fully featured resources and utilities currently available from AWS, it’s easy to see why having the ability to manage access is critical.
Limitations of AWS IAM
AWS IAM is certainly the best solution for managing AWS user identities. However, it is limited by the fact that AWS IAM is only for managing AWS user identities. Additional solutions will be required to manage access to AWS servers (e.g. AWS Directory Service), not to mention the huge number of resources that fall outside of AWS.
Common examples of resources that fall outside of AWS include user identities from other cloud providers (e.g. G Suite, Office 365, Azure), systems (Windows, Mac, Linux), cloud applications (e.g. Box, Zendesk, Salesforce), on-prem applications (e.g. Jenkins, Docker, OpenVPN), networks (wired & WiFi), Samba file servers and NAS devices (e.g. Synology, FreeNAS, QNAP), and more.
Amazon’s attempt to resolve the limitations with AWS IAM is by adding the AWS Directory Service solution, which allows admins to integrate with an existing Microsoft Active Directory® instance, either on-prem or managed by AWS. But this approach is like taking one step forward and two steps back for cloud-minded organizations because then IT admins will have to address the native limitations of AD, such as lack of management capabilities for non-Windows resources.
Furthermore, while AWS eliminates the need for purchasing, implementing, and maintaining the actual equipment necessary to support an AD instance, IT admins are still required to manage users, servers, interconnects, licenses, migrations, and the added cost that comes with maintaining AD.
Even after dealing with this headache, AD identities managed with the AWS Directory Service solution can only be federated to AWS resources. The end result is that Admins are now responsible for managing two incomplete solutions with AD in addition to AWS IAM, thus, adding complexity in management which drains time, effort, and money away from more important tasks.
AWS IAM with Directory-as-a-Service
The good news is that a powerful third party solution has emerged that can help streamline IAM for AWS resources in addition to actually connecting users to the wide variety of other resources an organization might need, both on-prem and in the cloud at AWS and beyond. This solution is called Directory-as-a-Service®.
Directory-as-a-Service is a cloud based directory service platform. It is effectively the cloud alternative for AD, and integrates with AWS with a similar approach as the AWS Directory Service solution. The key difference is that Directory-as-a-Service is not bound by the same limitations of AD and JumpCloud identities can be federated to a much wider array of resources.
For example, Directory-as-a-Service streamlines management by providing the source of truth for user identities just like AD. Similarly, JumpCloud identities can then be federated to AWS IAM with our AWS IAM Single Sign-On (SSO) connector. Directory-as-a-Service can even work in place of the AWS Directory Service solution and federate AD identities to AWS resources and much more.
However, Directory-as-a-Service goes much further to provide not only management capabilities for AWS IAM, AWS resources, and Windows devices, but also for other cloud resources (e.g. G Suite, Office 365, Azure), heterogeneous systems (Windows, Mac, Linux), cloud applications (e.g. Box, Zendesk, Salesforce), on-prem applications (e.g. Jenkins, Docker, OpenVPN), wired and WiFi networks, Samba and NAS appliances (e.g. Synology, FreeNAS, QNAP), and a lot more. All of which can be accessed by leveraging one core identity in the cloud.
As a result, IT admins can and should continue to use AWS IAM to control AWS identities and access management for AWS resources. However, they are now empowered with the ability to control IAM for all of their resources as well as connect JumpCloud managed users to resources on AWS and anything else your organization needs to get the job done. Directory-as-a-Service effectively becomes the foundation upon which to build your cloud infrastructure where AWS and everything else your organization needs can live happily under one identity management roof.
Learn more about AWS IAM with Directory-as-a-Service
To learn more about what AWS IAM is, and how Directory-as-a-Service can help manage the breadth of your IT infrastructure including managing access to AWS resources, drop us a note. You can also sign up for a free IDaaS account and see for yourself. Your first ten users are on us to help you test the full functionality of our product with no upfront cost.
This is a Security Bloggers Network syndicated blog post authored by Vince Lujan. Read the original post at: JumpCloud