Hi and welcome to my first post in dev.to!

There are already several posts, videos, and tutorials from different sources that cover their journey to the cloud, so I will not cover some of the really basic concepts of what's the cloud and similar, but I would rather focus on some of the concepts that I have seen are a bit of a challenge during the first days on cloud projects.

User Management is one of the first concepts we need to have clear before working in the cloud and for that we need to differentiate between the types of users we could have:

• Cloud users and roles: via IAM or IAM Identity Center Users (successor to AWS Single Sign-On)
• Operating System (OS) users: e.g. Linux or Windows
• Database users: e.g. AuroraDB, Oracle, or SQL Server
• External APIs or system users: e.g. SAP Hana, On Premises API, BI Tools (Tableau, Power BI, etc)
• And on top of that our Application users. Which for this post can be either a web application or REST API

Cloud Users and Roles

The difference between a user and a role on a high level is that the user is associated with a person or an application and the role has no association with a specific person. I leave this link for more information and best practices on when to use a user or role.

These users depend normally on the IAM service or the IAM Identity Center Users and are the ones responsible to communicate with the AWS APIs, which makes them ideal for the use case of deploying the cloud infrastructure like EC2 (ideally with Infrastructure as a Code) or when our application needs to make direct calls to one of the AWS services like Lambda or S3.

The permissions we have for our users are managed by IAM Policies which we can attach to our user, role, or group. One of the best practices for this is to apply least-privilege permissions, which means that we should assign just the permission required to our tasks and nothing more.

OS Users

Once we have our EC2 up and running, we figure out that most probably we need to connect with ec2_user or ubuntu in case of most distros of Linux or Administrator for Windows.

These users are the local users configured by default in the AMIs we choose for our EC2 and with them, we can create more OS users, install packages, update the OS, and in general do our sysadmin tasks inside our EC2.

But one important thing to consider is that those users don't exist in IAM, so by default, we cannot access the AWS APIs (though we can attach an IAM role to our EC2, but let's leave that option aside at the moment to not complicate things more).

Database users

Next, we have our database. In this scenario, we can use AWS RDS to deploy our database and it will create an administrator user. With this, we can create more users and then, as an example, use AWS Secret Manager to store those credentials and even rotate them.

Besides this mechanism, RDS also supports authentication via IAM, which means we would need a valid Cloud User, and via Kerberos. This last one might sound scary, so I will leave it for later.

External Users

Depending on our organization, we might have more systems to access outside AWS, which means more users to track. Here it would depend on the system, we could be speaking of the regular user:password mechanism, certificate-based, SSO via SAML and OAuth2, among several others.

Our Application Users

And last we have the users for our application. Normally we would have a module in our application dedicated to this purpose. This module would have its database of users and check they are who they claim they are (authentication) and that the users have permission to access the resources they request in our applications (authorization).

Having said that, one of the benefits of deploying our application in AWS is that we can leverage that module to AWS Cognito. I talk a little more about this scenario in a previous post.

With Cognito, we can have a user pool with valid users that can access our application and configure our application to retrieve the scopes of those users and see if they can access certain resources.

Users everywhere

At this point I hope it's clear that the more systems and services we would use, the more kind of users are needed, so we need to be careful from the very beginning of our journey when we decide on the users to be created, their permissions and who will use them.

The developer's dream is to have administrator access, with root or sudo permissions, and grant all to our schemas, that would be rainbows and flowers until the sad truth comes when we realized why the best practices are in our best interest: keeping our application and environment safe from attacks, misuse or error during deployments and have proper observability on what is happening in our account.

Centralized user management

But not everything needs to be spread in several places, remember that scary word: Kerberos. This mechanism is used by RDS as a way to authenticate to our database and it requires an Active Directory (AD). Luckily for us, AWS provides a service for that: AWS Directory Service.

If we enable this integration in RDS, all the users we create on Active Directory will be valid on our database. Up to this date, AuroraDB, MySQL, Postgres, Oracle, and SQL Server are compatible with this.

The advantage of using AD is that several external systems, like SAP Hana or BI Tools, are compatible with it and we could configure them also to use it. Even QuickSight, which is the business analytics service from AWS, and with its enterprise edition we can integrate it with Directory Service.

Besides that, we can also configure our Linux or Windows EC2 instances to join our AD and do it automatically during bootstrap. And if we would require to provide several desktops to our users, we might have had a look into AWS Workspaces, which is a managed desktop computing service in the cloud that can be also integrated with AD.

For Cognito, you might guess, we can integrate it with AD using SAML and Active Directory Federation Services. And with this, we can implicitly extend this integration to our applications behind API Gateway, ELB, or mobile apps.

And last, we can enable IAM Identity Center Users to communicate with an AD in our central AWS account, so all the child accounts can access them using the SSO mechanism.

Having configured this, we would need:

• Cloud Users: For the initial setup of the main account and the AD.
• AD Users: Active Directory users and groups for all other cases.

And that's it! I won't cover the details of the configuration of this setup here, but please leave a comment if that would be something of interest for another post. And I hope this will help you in your journey to the cloud...

One User to rule them all, One User to find them, One User to bring them all and in the system bind them.