In this lecture, I want to review some of the key points that are highlighted in our existing course found here, as these will be fundamental in gaining an understanding and comprehension of how access control and authentication is implemented across different AWS Databases.

Let me start off by looking at users, groups and roles.

Users are objects created to represent an identity. This could be a person within your organization who requires access to operate and maintain your AWS Database, either via the AWS Management Console or programmatically via the AWS CLI. Users are simply objects representing an identity which are used in the authentication process to access resources within your AWS account.  Permissions can then be assigned to user objects granting that user access to resources, such as AWS Databases.  

When using the AWS Management Console, authentication is verified through a password.  When working programmatically with the AWS CLI for example, then authentication is verified through the use of the secret access key credentials configured with the CLI on the client. 

IAM Groups are objects much like user objects, but they are not used in any authentication process. However, they are used to authorize access to AWS resources, through the use of AWS Policies. IAM Groups contain IAM Users, and these groups will have IAM Policies associated that will allow or explicitly deny access to AWS resources, such as your AWS Databases.

Groups are normally created that relate to a specific requirement or job role. Any users that are a member of that group inherit the permissions applied to the group. By applying permissions to the group instead of individual users, it makes it easy to modify permissions for multiple users at once. All you would need to do is modify the permissions of a group, and all users associated with the group would inherit the new access.

IAM Roles allow users and other AWS services and applications to adopt a set of temporary IAM permissions to access AWS resources. Consider the following scenario. You have an EC2 instance running an application that requires access to one of your RDS Databases.  

To allow access, you could store a set of credentials on the EC2 instance itself, allowing any application to use those credentials to gain access to the relevant table. However, in this scenario, you would need to manage these credentials manually, including the rotation of access keys, which is obviously an administrative burden.

To alleviate this issue, the EC2 instance could be assigned an IAM role that would contain the relevant permissions granting the EC2 instance and its applications access to RDS to perform the relevant API calls.  From a security best practice perspective, you should always associate a role to an EC2 instance for accessing AWS resources over storing local credentials on the instance itself.

There may be circumstances where you'll need to grant temporary access to your database for a particular user, and this can be achieved by configuring a role.  To do this, you can simply create a new role, associate the relevant permissions to that role, and then give the user permission to adopt the role via an access policy. 

IAM policies are used to assign permissions to users, groups, and roles and are written as JSON documents, Javascript object Notation, and each policy will have at least one statement.  This is an example policy, taken from the AWS managed policy of AmazonRDSReadOnlyAccess

Within a statement, you will see at least one Action, one Effect, and one Resource.

• Action. This is the action that will either be allowed or denied, depending on the value entered for the Effect element. 
• Effect. This element can either be set to allow or deny, which will either grant or restrict access for the previous Actions defined in the statement. 
• Resource. This element specifies the actual resource you wish the "Action" and "Effect" to be applied to. AWS uses unique identifiers, known as ARNs, Amazon Resource Names to specify specific resources. 

IAM policies can be categorized between 2 different types within IAM.

Managed Policies:  These policies can be associated with multiple Group, Roles, and Users. Although assigning policies to a single user is not best practice, it is best to apply permissions to groups and place that user within a group.

Inline policies: Whereas a Managed Policy can be attached to multiple users, groups, and roles, Inline Policies cannot. An Inline Policy is directly embedded into a specific User, Group or Role, and as a result, it is not possible to use it for multiple identities or IAM objects.

Managed policies also come in 3 different flavours:

AWS Managed - The AWS Managed policies have been pre-configured by AWS and made available to you to help with some of the most common permissions that you may wish to assign. Here are some examples of AWS managed policies that relate to RDS and DynamoDB

AWS Managed - Job Function - These policies are much the same as AWS Managed but they have been created to cover typical job role functions and the permissions that would likely be required.

As expected, AWS do have one for a Database Administrator:

Customer Managed - These policies are created and configured by us as customers to define specific permissions required against our resources

So now we have covered at a high level some of the main components of IAM, let’s look at some of the service-specific ways that different AWS database services utilize IAM in its effort to maintain security, starting with a review of Amazon RDS Authentication methods.