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.

Figure 1: Customer example architecture of database environment with connectivity through AVA

Figure 1: Customer example architecture of database environment with connectivity through AVA

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.

Figure 2: AWS Console view showing the configured databases in example environment

Figure 2: AWS Console view showing the configured databases in example environment

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.

Figure 3: Identity Center User groups for Data Science Team and Database Admin Team

Figure 3: Identity Center User groups for Data Science Team and Database Admin Team

Figure 4: Identity Center Users from Data Science Team and Database Admin Team

Figure 4: Identity Center Users from Data Science Team and Database Admin Team

You can use the following steps to configure AVA Endpoints for the databases

  1. 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.
  2. 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.

    Figure 5: AWS Verified Access instance for providing connectivity to the databases

    Figure 5: AWS Verified Access instance for providing connectivity to the databases

  3. 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.

    Figure 6: Verified Access Groups for consumer app databases and internal databases

    Figure 6: Verified Access Groups for consumer app databases and internal databases

  4. 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”.

    Figure 7: Verified Access Endpoint creation for RDS database cluster

    Figure 7: Verified Access Endpoint creation for RDS database cluster

  5. 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

      Figure 8: List of Verified Access Endpoints for the databases

      Figure 8: List of Verified Access Endpoints for the databases

  6. 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.
      permit(principal,action,resource)
      when {
      context.idcpolicy.user.email.address like "*@anycompany.com"
      &&( 
      ( 
            context.idcpolicy.groups has  “a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
      )
      || 
      (
            context.idcpolicy.groups has “a1b2c3d4-5678-90ab-cdef-EXAMPLE22222" 
      )
      )
      };
      Cedar
    • 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.
      permit(principal,action,resource)
      when {
      •	    context.idcpolicy.groups has "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222" &&
          context.idcpolicy.user.email.address like "*@anycompany.com"
      };
      
      Cedar
      Figure 9: AVA policy applied to consumer facing app databases

      Figure 9: AVA policy applied to consumer facing app databases

      Figure 10: AVA policy applied to internal facing app databases

      Figure 10: AVA policy applied to internal facing app databases

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.

  1. Once the connectivity client asks for Authentication, specify the username “dsuser” and their password to login and get connected.
  2. 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.

    Figure 11: RDS DB Endpoint for App2 database

    Figure 11: RDS DB Endpoint for App2 database

  3. Connect using mysql client using the below command.
    mysql -h <AVA endpoint for App1 RDS database instance> -P 3306 -u admin -p
    Bash
    Figure 12: Successful connection by the dsuser to the RDS DB instance endpoint

    Figure 12: Successful connection by the dsuser to the RDS DB instance endpoint

    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.

  4. 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.

    Figure 13: Aurora DB Cluster Endpoint for App3 database

    Figure 13: Aurora DB Cluster Endpoint for App3 database

  5. Connect using psql client using the below command.
    psql -h <AVA endpoint for App3 Aurora database> -p 5432 -U postgres
    Bash
    Figure 14: Unsuccessful connection by the dsuser to the Aurora DB cluster AVA endpoint

    Figure 14: Unsuccessful connection by the dsuser to the Aurora DB cluster AVA endpoint

    As Figure 14 shows, Since the AVA policy did not allow access to the data science user, they are not able to connect successfully.

  6. Disconnect the Connectivity client as shown in Figure 15 below and also logout the user session.

    Figure 15: Disconnecting the AVA session from the client and the browser

    Figure 15: Disconnecting the AVA session from the client and the browser

  7. Sign in to the connectivity client again and specify the username “dbadmin” and their password to login and get connected.
  8. Connect to the App3 Aurora database using psql client using the below command.
    psql -h <AVA endpoint for App3 Aurora database> -p 5432 -U postgres
    Bash
    Figure 16: Successful connection by the dbadmin to the Aurora DB cluster AVA endpoint

    Figure 16: Successful connection by the dbadmin to the Aurora DB cluster AVA endpoint

    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

Anandprasanna Gaitonde

Anandprasanna Gaitonde

As an AWS Principal Solutions Architect, Anandprasanna Gaitonde is responsible for helping customers design and operate Well-Architected solutions to help them adopt the AWS cloud successfully. He focuses on AWS Networking and Serverless technologies to design and develop solutions in the cloud across industry verticals. He has Solutions Architect Professional and Advanced Networking certifications and holds a Master of Engineering degree in Computer Science and a postgraduate degree in Software Enterprise Management.

Rajat Tyagi

Rajat Tyagi

Rajat is a Senior Product Manager on the EC2 Networking team at AWS, where he drives the development of remote connectivity products. His goal is to deliver secure, user-friendly solutions that enable customers to seamlessly access their applications and workloads. Outside of work, Rajat enjoys hiking and swimming.