Connecting Saas services within a VPC Lattice service network

Many AWS customers modernizing their applications into modular services to speed up the development process and improve their ability to scale out individual services as part of the architecture. This includes services developed by the customer and SaaS applications developed by partners. Communication between services requires network connectivity across the Amazon Web Services (AWS) environment. For these services, the customers and partners use different network connectivity models, where partners grant access to applications using a variety of AWS services. One such network construct that connects, monitors, and secures communications between services is Amazon VPC Lattice. Customers use VPC Lattice to provide a simplified, secure network connectivity model with fine-grained authorization policies used to define access to services. For example, customers create a policy for how each client service in the Amazon Virtual Private Cloud (VPC) associated with a service network may communicate with the SaaS service.

In this post, we discuss how to connect SaaS services within Amazon VPC Lattice. We review the components within VPC Lattice that allow for this connectivity and outline best practices for connecting SaaS services that are deployed in partner accounts and VPCs. We will also review examples of auth policies from both a partner lens and a customer lens to show how to permit or deny access to services within the service network.

Prerequisites

For the following sections, we assume you are familiar with creating AWS Identity and Access Management (IAM) policies and with fundamental concepts with VPC Lattice, including services, service networks, and auth policies. We also assume you are familiar with deploying services and applications using Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Kubernetes Service (Amazon EKS), and AWS Lambda.

Solution overview

For partners to share services within VPC Lattice, there are two feature capabilities that provide this connectivity model: resource sharing and security controls. We use a simple architecture of three services for our examples. Two services, an application front-end and an application backend, will exist in your account. In addition, you add the partner SaaS solution to the service network to provide for communication between the different services. Figure 1 details the applications deployed as part of this network.

Figure 1: Application architecture between customer account and SaaS account

Resource sharing

To share services between a SaaS provider and your service network within the AWS account or AWS Organizations account, we use AWS Resource Access Manager (AWS RAM). AWS RAM is a service that permits you to share VPC Lattice resources with other AWS accounts or organizations. With AWS RAM, partners share their SaaS services with you to access your service network and grant communication between services and VPCs deployed as part of VPC Lattice. When the partners share a VPC Lattice resource that they own with other AWS accounts, they allow those accounts to associate their resources with resources in your account, including your services and service network. AWS RAM allows partners to share their services with one or multiple accounts, depending on the tenancy model, which we will talk about in more detail in upcoming sections. When you create an association against a shared resource, we generate an Amazon Resource Name (ARN) in the resource owner account and an ARN in the account that created the association.

One powerful concept with AWS RAM is that the sharing of resources is only between the resource owner and the AWS accounts or organizations that the resource owner directly shares with. Those AWS accounts or organizations are not permitted to share resources with other accounts directly (transitive sharing). As an example, in Figure 2, the SaaS account shares the SaaS service with Account A, which will add the service to its service network. Other services of that service network will have access to the SaaS service as long as the VPC Lattice service and service network auth policy permits access. However, resources in AWS RAM cannot be transitively shared. For example, Account A cannot share the SaaS service with Account B to add to its own service network. The SaaS account must share the service with Account B directly if Account B wants to add the SaaS service to its service network.

Figure 2: Transitive service sharing is not permitted with AWS RAM

Now that we understand how AWS RAM works, let’s walk through how to share the SaaS service shown in Figure 1. First, the SaaS account has created a single SaaS service. Through AWS RAM, the SaaS service provides partner-owned services that will attach to your service network.

Figure 3: SaaS service created in the SaaS provider account

To share the SaaS service with your account, the partner will create a resource share in AWS RAM for the target AWS account or organization. In the resource share, the partner will select:

• Resources to share: This will include one or more VPC Lattice services that the partner will share with your AWS account or organization.
• Permissions associated with the resource share: By default, permissions for a VPC Lattice service include vpc-lattice:GetService and vpc-lattice:CreateServiceNetworkServiceAssociation. GetService allows the principal to retrieve information about the specific service. CreateServiceNetworkServiceAssociation allows the principal to associate a service with a service network. This is customizable by the partner on what other permissions they want to allow for the resource share.
• Principals that are allowed to access: This specifies the principals (AWS accounts or organizations) that the partner will share the resource with.

This is shown in Figure 4.

Figure 4: Sharing the SaaS service with the customer account

Once the partner shares the SaaS service with your account, you will see the shared service within both AWS RAM and VPC Lattice services. For our example, the services now appear in your account, as shown in Figure 5.

Figure 5: VPC Lattice services within your account

You will now add the SaaS service to your existing service network deployed in your account to allow service-to-service communication between your services (front-end and backend) and the SaaS service. However, before you do so, we need to talk about security and auth policies between services within the service network.

Security controls within VPC Lattice

From a security control perspective, VPC Lattice auth policies allow you to attach IAM policies to both the service networks or a group of services within the service network. They provide a mechanism to control access to each service and service network within VPC Lattice. Each auth policy is an AWS IAM resource policy and provides request-level authentication and context-specific authorization for service access requests. Auth policies provide a powerful construct to allow or deny access at the IAM resource level, besides the existing network level constructs with security groups and network access control lists (ACLs).

Let’s dive into a couple of scenarios from two different personas: the partner lens, who is sharing the service, and the customer or your lens, who is adding the SaaS service to the VPC Lattice service network. The architecture is the same as shown in Figure 1, comprising the front-end, backend, and SaaS service. From an authentication and authorization perspective, the partner will deploy the policy on which AWS accounts or organizations will have access to the service, while you will deploy a policy that will determine how the services will communicate together.

Partner lens

As a partner offering services in VPC Lattice, the tenant isolation strategy for SaaS solutions affects how partners share resources and the different auth policies that are required to be added to their VPC Lattice service. Different SaaS applications, including front-end, backend, and data applications, differ in the way partners deploy the SaaS solutions.

Single tenant model

With a single tenant model, partners will share a VPC Lattice service with a single customer across a single AWS account, multiple AWS accounts, or an organization in your AWS Organizations account. All resources within the partner service are tied to the single customer, with resources isolated from other SaaS customers. This does not require partners to deploy all resources in separate accounts or VPCs. However, they tie each VPC Lattice service to discrete resources provisioned for an individual customer. With this model, the partner’s auth policies will grant access to any authenticated request that originates from principals that belong to the AWS account(s) or organization specified by the auth policy.

Figure 6: SaaS provider sharing the service with a single tenant

Let’s look at an example. Let’s say the partner has a SaaS service shared with your organization. From an authentication and authorization perspective, the SaaS provider only wants to grant permissions to an authenticated request that originates from principals that belong to the organization specified. To accomplish this, the partner writes the following policy and applies the policy to the SaaS service:

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect": "Allow",
         "Principal": “*”,
         "Action": "vpc-lattice-svcs:Invoke",
         "Resource": [
            " arn:aws:vpc-lattice:us-east-1:444455556666:service/svc-0b847e0ccdc496cb3/*"
         ],
         "Condition": {
            "StringEquals": {
               "aws:PrincipalOrgID": [ 
                  "o-123456customer1"
               ]
            }
         }
      }
   ]
}

This policy will grant a request from your organization ID (o-123456customer1) to the SaaS service (svc-0b847e0ccdc496cb3).

Multi-tenant model

With a multi-tenant model, partners will share a VPC Lattice service with multiple customers. They share resources within the SaaS service across customers, where access to partner’s services uses tenant-aware identity authentication, path-based auth polices, or another application-based mechanism to define access to resources or customer data. With this model, the partner’s auth policies will grant access to any authenticated request across customers or to particular paths on a per-customer (AWS account or organization) basis.  This is shown in Figure 7.

Figure 7: Saas provider sharing the service with multiple tenants

Expanding on the previous example, the partner deploys a single SaaS service that multiple customers will use, with the service path separating the authorization. To accomplish this, the partner will change the preceding policy example to the following example and apply the policy to the SaaS service:

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect": "Allow",
         "Principal": “*”,
         "Action": "vpc-lattice-svcs:Invoke",
         "Resource": [
            " arn:aws:vpc-lattice:us-east-1:444455556666:service/svc-0b847e0ccdc496cb3/customer1"
         ],
         "Condition": {
            "StringEquals": {
               "aws:PrincipalOrgID": [ 
                  "o-123456customer1"
               ]
            }
         }
      },
      {
         "Effect": "Allow",
         "Principal": “*”,
         "Action": "vpc-lattice-svcs:Invoke",
         "Resource": [
            " arn:aws:vpc-lattice:us-east-1:444455556666:service/svc-0b847e0ccdc496cb3/customer2"
         ],
         "Condition": {
            "StringEquals": {
               "aws:PrincipalOrgID": [ 
                  "o-123456customer2"
               ]
            }
         }
      }
   ]
}

Now, the partner grants Customer 1 access from their organization (o-123456customer1) to the SaaS service using the /customer1 path. The partner grants Customer 2 access from their organization (o-123456customer2) to the SaaS service using the /customer2 path. They share the same service across multiple customers, but the auth policy allows or denies access to different paths depending on where the traffic is coming from.

Customer lens

From a customer perspective, you need to consider what services will access the partner SaaS service and whether the SaaS service will initiate connections to other services in the service network. You can create fine-grain auth policies to permit or deny access based on multiple conditions in the auth policies. Similar to the policies you will create with your own service-to-service communication, administrators need to determine what access to give each SaaS solution that is added to the service network.  Let’s look at the last example, shown in Figure 8.

Figure 8: Front-end VPC initiates requests to the backend and SaaS services. All other requests are denied.

For this example, you have associated two services with the service network: the backend service and the SaaS service. In addition, you have created a VPC association with the front-end VPC to allow the service to initiate connections into the service network. You only want to allow the front-end service VPC to initiate connections to the backend service and SaaS service. All other VPCs would be denied. To accomplish this, you will write the following policy and apply the policy to the service network.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect": "Allow",
         "Principal": “*”,
         "Action": "vpc-lattice-svcs:Invoke",
         "Resource": [
            " arn:aws:vpc-lattice:us-east-1:444455556666:service/svc-0b847e0ccdc496cb3/*",
            " arn:aws:vpc-lattice:us-east-1:111122223333:service/svc-0be0b12dd1d277c58/*",
         ],
         "Condition": {
            "StringEquals": {
               "vpc-lattice-svcs:SourceVPC": " vpc-1a2b3c4d"
            }
         }
      }
   ]
}

The policy permits the front-end service (vpc-1a2b3c4d) to send requests to both the backend service (svc-0be0b12dd1d277c58) and the SaaS service (svc-0b847e0ccdc496cb3). Now, you have your service network set up to provide service-to-service communication between your services and the partner SaaS service shared with your organization.

Considerations

• Listener protocols and ports supported in VPC Lattice are found in the VPC Lattice User Guide.
• Only the owner of the VPC Lattice service can add an auth policy to the service. If they share a service with you, you can create an auth policy for the service network or for your services within the service network.

Conclusion

In this post, we discussed how you use Amazon VPC Lattice to provide secure connectivity between your services and SaaS services across your service network. We reviewed how partners share services with your account or organization. Then, we walked through examples of how both partners and you create auth policies to permit or deny service-to-service communication within your service network. If you have questions about this post, please submit the question to AWS re:Post. For more information about Amazon VPC Lattice, refer to the Amazon VPC Lattice documentation and additional Networking & Content Delivery Blog posts that cover VPC Lattice.