This is my first post on my Amazon Web Services (AWS) journey with a series of short blogs. I hope to demystify and breakdown some basic concepts that you can use in your day-to-day life as an AWS administrator. Cloud adoption has continued to accelerate, with more than 50% of organizations expected by 2027. While there are many cloud providers in the marketplace today, I will be focusing on AWS. I will review Amazon's Identity and Access Management (IAM) which is the first step into cloud adoption. There are two types of credentials that you need to keep in mind: human and machine credentials. Both have their unique purpose when accessing resources within an AWS environment. When authenticated and authorized, it will allow you access either programmatically such as an API call between resources (machine), or direct access to the console or CLI (human). It's good if you become familiar with the term principals as it is often used within AWS to refer to actions that you perform on your account. You will also notice it is an element in JSON, which is their code behind the scenes, and that you can edit directly during account creation. Figure 1 indicates the account workflow with principals.
Figure 1 - AWS Identity and Access Management
When creating a new account, you would have to consider your use case and security construct before implementing. In AWS you can have a root account, an IAM user, a role or application. Organizations wishing to scale should implement federation, which allows access using temporary pass-through credentials from an authoritative source like Microsoft’s Active Directory, instead of a cloud IAM user within AWS. The root account should rarely be used unless there is an emergency.
A best practice is for you to utilize strong authentication and least privilege principle when authorizing users to AWS resources. Authentication can be managed using passwords, multifactor authentication and/or keys and authorized through policies, which are either bound to an IAM user or a group that they are part of. Policies can be configured as a Trust Policy, which is a resource-based policy for IAM roles, or an identity-based, which permits users to perform a certain activity. For example, if you want to give a user fine-grained access to a table within a database, you would need a resource-based policy. This policy would provide access using least privilege without exposing the entire database. Something that could not be accomplished using identity-based alone. Roles can be used for temporary cross-account access, such as a developer account assuming a role as a production account that is allowed to migrate code to production. A nice benefit with roles is that it will prevent you from accidentally performing tasks that are not permitted by the more restrictive credentials. It also expires automatically over a set period of time.
Once you figure out if you are using IAM users and roles, federation, identity, and resource-based policies, the next step would be to create your permission set. Fortunately, AWS has its own managed policies for its services out of the box so this won’t take long to configure unless you have a unique use case that would require customer-managed policies. You will need to consider if you are going to use role-based access control (RBAC) with groups or attribute-based using resources (ABAC). For example, you have a user in the finance department that needs access to a suite of financial applications. You create a group for finance and add a user to this group. If you are looking to implement at scale, you could use AWS Tags and apply it to the financial applications. Then use that tag to assign to your IAM user so resources can be added or removed dynamically which will not require you to update the group with every resource move, add or change.
You should keep in mind additional services such as logging, monitoring, and configuration using AWS Well-Architected framework goes into the finer details around identity and access management.