AWS PrivateLink - Access Our App, Not Our VPC
Working with our clients, we get requests all the time to help them provide access to their partners and other vendors for the purpose of accessing an internal, private service such as a web app, ECS cluster, or API Gateway. The problem is, this usually means coordinating some form of VPN or Bastion server access.
This ends up creating several headaches in the process.
Agree on a method of ingress between two parties. (Client/Server VPN, site-to-site VPN, Bastion host, etc.)
Reconcile conflicts for the above. (There always are.)
Build out that solution, maintain, and incur compute costs.
Control and maintain user access to intended resources.
Control and maintain network access to intended resources.
Manage and protect access keys.
Cross your fingers and hope the third party behaves and you didn’t miss anything.
That’s a lot - and it’s not even a fraction of all of the immediate and ongoing concerns. Add in doing this at scale beyond one vendor and you can see how things will easily begin to fall apart and serious security compromises will be made.
Give Them What They Want
If the goal of the vendor is to access one internal service, why give them the whole VPC? Why not just the service itself? This is where AWS PrivateLink can help.
PrivateLink is able to create an AWS Cloud accessible endpoint which outside VPCs and Accounts can register with. Once registered, the Service Provider can approve or reject a request to connect to their endpoint by the Service Consumer. Entities can also be whitelisted and automatically accepted based on Principles such as and AWS Account or Role.
Once the link is established, the Service Consumer uses a private DNS entry generated by the Endpoint service to access the new PrivateLink backed service. Now the vendor has the access they need and the Provider doesn’t need to do anything to control access beyond continuing to allow the connection or closing it at a later date. No user accounts, no tunnels, no NACLs, no routes, and no mess.
Behind the Scenes
At a high-level, the basic components are :
Some service provided by an EC2 instance. (For example such as a web app running on port 80)
A Network Load Balancer to broker traffic to the service. (Note, ACM certificates can be used to provide TLS for insecure protocols.)
PrivateLink pointing at the Network Load Balancer.
That’s really about it to get started with using PrivateLink.
So what we’ve learned is how we can provide internal, private services to outside entities without exposing our whole infrastructure and generating more overhead and time to manage those connections.
PrivateLink has some additional features that build upon this. It’s also worth noting that PrivateLink is HIPAA and PCI compliant which goes a long way when working with potentially antiquated and insecure applications and protocols that need to be maintained for longer than anticipated.
Author: Michael Payne