Networking & Content Delivery
AWS Verified Access support for non-HTTP resources is now generally available
Connecting securely to RDS databases
AWS Verified Access (AVA) now extends beyond HTTP apps to provide VPN-less, secure access to non-HTTP resources like RDS databases, enabling improved security and enhanced user experience for both web applications and database connections. AVA is built based on Zero Trust principles and allows administrators to define fine-grained access policies, based upon user’s identity and device posture. AVA extends fine-grained access policies to a RDP, SSH and other TCP based applications hosted on AWS while still maintaining a high level of security posture.
In this blog post, we look at common use cases with organizations where database administrators, data science teams, as well as DevOps teams, need to connect to their private databases securely. We will walk through an example architecture of a database environment protected by AVA’s non-HTTP access capability for secure access.
AWS Verified Access: non-HTTP Access Support
The AVA non-HTTP access support, enables secure access to resources that connect over protocols such as TCP, SSH, and, RDP. While originally AVA enabled secure access to HTTP(s) applications, this new feature allows customers to extend protection to other TCP applications.
When creating the AVA endpoint, now you can select TCP as the Protocol type. For this protocol, the following Endpoint targets are supported
Load Balancer Endpoint: Allows you to specify Network Load Balancers which are hosting TCP based applications in your VPCs
Network Interface: TCP application which is hosted on EC2 as well as applications which are exposed through interface endpoints
Network CIDR: Applications and resources which are accessible within a VPC using IP Address and Port. This enables access to applications such as SSH, databases over EC2.
Amazon Relational Database Service (RDS) endpoint: This allows for more seamless integration with RDS database instances, RDS Proxy and RDS clusters.
We previously illustrated the use case of how you can use a Network CIDR endpoint to create an AVA endpoint for SSH connectivity in a blog post. Lets dive into how AVA can help secure connectivity to your database layer on AWS using one or more of the capabilities mentioned above. In order to support non-HTTP access, AVA provides a connectivity client which needs to be installed on client devices. The client securely encrypts user traffic, adds user identity information and device context, and routes it to Verified Access for policy enforcement. If the access policies allow access, the user is connected to the application.
Architecture of Customer Database Environment
Figure 1 shows an example environment comprising of a multiple VPCs in an AWS Region. These VPCs host several applications App1, App2 and App3 in their own VPCs and with their databases residing in private subnets and not accessible from the internet. We have an internal data science team comprising of data scientists involved in machine learning and database admin team which manage the databases across the organization. Each application uses different databases. App1 uses a Amazon RDS Database, App2 uses RDS Multi-AZ Cluster , whereas App3 uses Aurora cluster. App1 and App2 are consumer facing apps which generate customer and transaction data required by data science teams for their machine learning pipelines. App3 however is an internal application and does not have data needed by the Data Science team. Applications and their subnets are not shown in the diagram for brevity. Database admin team needs to have the ability perform remote management tasks on all the database to run sql queries for schema changes and other table updates. However, data science team which is working on data preparation and exploration needs access to App1 and App2 datasets for their work but not to App3 database.
Setting up AWS Verified Access for Database Access
To illustrate the setup, it’s assumed you have the databases and the Identity center setup in your AWS account. To learn more about how to setup the databases please visit AWS documentation for RDS database instance, RDS Multi-AZ Cluster and Aurora database cluster. A representative environment with the 3 databases is shown in the AWS Console in Figure 2.
To create IAM Identity Center users and groups please visit AWS documentation. A representative environment with IAM identity Center configured with users and groups created for the Database Admin team and the Data Science Team as shown in Figure 3 and Figure 4.
You can use the following steps to configure AVA Endpoints for the databases
- The first step for the endpoints is to create an Identity Trust Provider. The trust provider is a service that sends information about users and their devices to AVA. This information can then be used in AVA policies for performing access control. For this setup we will use the IAM Identity Center as our identity trust provider. To create the trust provider, do the steps outlined in the documentation.
- You can then create a Verified Access Instance by following the steps here and shown in Figure 5. As part of this step, AVA instance integrates with the Identity Trust Provider that you setup in Step 1.
- As shown in the architecture of Figure 1, we have 2 categories of application databases i.e consumer app databases and internal app databases. They will have different access requirements. AVA provides a capability called Verified Access Groups which allows you to group applications and resources with common access requirements and apply a common verified access policy. In this case, we will use 2 separate verified access groups. One for the consumer apps databases, which will be accessed by both Data Science team and Database Admin team, and one for the internal app database which should only be accessed by Database Admin team. This will allow us to apply different set of verified access policies in subsequent steps. The Verified Access Groups can be created using the steps here and have been shown in Figure 6.
- Next we will create a Verified Access Endpoint for RDS in AWS console or CLI. You will select the Endpoint Type as “Amazon Relational Database Service” and select the ARN of the RDS database. The configuration needed for this step is shown in Figure 7. In this setup you can create an endpoint for either a specific RDS database instance, an RDS cluster or a RDS Proxy as specified by the RDS Target type field. In the screenshot shown in Figure 7 we are creating an AVA endpoint for RDS cluster for app2-database which is a Multi-AZ RDS mysql cluster and then specifying which specific cluster endpoint to use. Since this endpoint belongs to the consumer app, we add it to the “ava-group-consumer-app”.
- We will do the same for the other endpoints, RDS database instance endpoint and Aurora database cluster endpoint.
- For App1 RDS database instance, specify Endpoint Type as RDS and RDS target type as RDS instance. This is also added to the “ava-group-consumer-app” since its database belonging to the consumer application.
- For App3 Aurora database cluster, specify Endpoint Type as RDS and RDS target type as RDS cluster. This database is added to the “ava-group-internal-app” since this belongs to an internal app.The resulting AVA endpoints are shown in Figure 8 below
- Since the data science team as well as database admin team needs to access the consumer app databases remotely, we specify separate AVA policies to ava-group-consumer-app and ava-group-internal-app as shown in Figure 9 and Figure 10.
- AVA Policy for ava-group-consumer-app: allows access to the Data Science Team and Database Admin Team to the endpoints associated with this group which includes all the consumer app databases in the environment as specified below.
- AVA Policy for ava-group-internal-app allows access only to the Database Admin team as this internal database is not required to be accessed by the Data Science team.
Testing the connectivity and access control
In order to be able to connect to the Verified Access endpoints for our databases, one of the prerequisite is to use the AVA Connectivity Client. Follow the steps in the documentation to download and install the client as well as export the client configuration file.
You can then connect to the AVA endpoint.
- Once the connectivity client asks for Authentication, specify the username “dsuser” and their password to login and get connected.
- Navigate to the AWS console Amazon VPC > Verified Access Endpoints and select the endpoint for App1 RDS database. Copy endpoint domain to clipboard as shown in Figure 11. AVA creates DNS domains in Route 53 to route traffic to the endpoints and these domain names will allow clients to connect to these endpoints. You can use a CNAME or custom domain names for the endpoint and users don’t need to change any settings on their device to access the database.
- Connect using mysql client using the below command.
As Figure 12 shows data science user is able to connect to this database successfully. This is as per the AVA policy that is applicable for the endpoint.
- Navigate to the AWS console Amazon VPC > Verified Access Endpoints and select the endpoint for App3 Aurora database. Copy endpoint domain to clipboard as shown in Figure 13.
- Connect using psql client using the below command.
As Figure 14 shows, Since the AVA policy did not allow access to the data science user, they are not able to connect successfully.
- Disconnect the Connectivity client as shown in Figure 15 below and also logout the user session.
- Sign in to the connectivity client again and specify the username “dbadmin” and their password to login and get connected.
- Connect to the App3 Aurora database using psql client using the below command.
As Figure 16 shows, Since the AVA policy allows access to the database admin user, they are able to connect successfully. You can try other scenarios to test connectivity to the databases and validate the policies applied to the 2 groups of databases.
Considerations
- When AVA Endpoint is created for the RDS or Aurora Clusters, separate endpoints need to be created for each database endpoint and used accordingly by the client applications for e.g. you would create a Reader Endpoint and Writer Endpoint for Aurora database cluster and use them in the client.
- When customers have self managed databases on Elastic Compute Cloud(EC2) they can achieve the same functionality by creating a Network CIDR AVA endpoint and using the domain name associated with the IP address corresponding to the db instance.
Summary
With the launch of non-http access support within AWS Verified Access, you have the flexibility to use AWS Verified Access to secure their database environment and allow access from anywhere. Apart from databases, any TCP based resources can now be securely accessed using AVA using zero trust principles there by improving the security posture of your applications and databases on AWS. To learn more about the new endpoints supported by non-HTTP access feature please visit Verified Access Endpoints page in AWS documentation and video tutorial for the Overview and Demo.
About the authors