User access level 

In the cloud, it is critical to define users and user access. In this section, we define the users, groups, roles, and policies. Users are entities who will access the cloud infrastructure using the console or APIs. A group defines the collection of users who will perform a similar set of actions. Roles define the nature of the job the user will perform, while a policy defines the rules for resource access. It also describes how the users will access the services or applications, and how one service will securely communicate with another service. In the public cloud, communication or integration of different services is usually the user's responsibility, where the consumer defines the secure way for communication. But most of the time, we make a mistake in this process and leave this part vulnerable to security breaches. 

For example, we have a solution where EC2 instances need to store the static files on S3 storage. In this case, ideally we should create an EC2 role that has permissions to access specific S3 buckets, but most people put the access key and secret key into the test file in EC2 instances, which is not recommended. This is because if the VM gets compromised, then the whole account is at a risk if the stored key has root account access keys.

Similarly, we must use MFA for console access and should not use the root account to access the console. However, in real life, most of the users do this—they access the console using the root credentials and they also do not use MFA.

For audit purposes, we must use IAM events and we should be logged in to CloudTrail.

In OpenStack we also have identity management to define user access. As in the case of the AWS service, here also we define users, groups, and roles. Identity management in OpenStack provides you with the Role-Based Access Control (RBAC) and ACLs.