AWS Database Authentication & Access Controls
The course is part of these learning paths
This course covers the different options available to you to enable you to authenticate to your Amazon RDS and Amazon DynamoDB Databases. You'll learn about the difference between authentication and authorization, as well as Identity and Access Management, and how to authenticate to Amazon RDS, and DynamoDB.
If you have any feedback relating to this course, feel free to contact us at email@example.com.
- Define the differences between authentication and authorization
- Understand the key components of IAM used for access control and authentication
- Learn the authentication methods used to access RDS databases across different DB engines
- Learn the authentication controls of Amazon DynamoDB
This course has been designed to assist those who are responsible for securing, designing, and operating AWS Database solutions. It is also ideal for anyone who is looking to take the AWS Certified Database - Specialty exam.
To get the most out of this course, you should have a basic awareness of AWS database services, in addition to AWS Identity & Access Management.
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.
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.
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.
Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.