is it possible to make an api gateway or lambda function accessible only by a specific vpc.
I searched in amazon doc, but I didn't find anything about this subject.
Thank you in advance
Unfortunately, you won't be able to do that (See update below).
s3 is the service which provides that kind of control access through Bucket policies.
What you can do is grant permissions to your callers (Lambda invoker and API caller).
Take a look at these resources:
Control Access to an API with IAM Permissions
Control Access for Invoking an API
Overview of Managing Access Permissions to Your AWS Lambda Resources
UPDATE: Important comment from Michael - sqlbot
You might point out that the underlying reason why this isn't possible is that both the Lambda service API and API Gateway are accessed from the Internet, which means the VPC identity of the caller is lost -- however, the VPC can be identified indirectly by the EIPs of its NAT Gateways, which should be usable against the aws:sourceIp IAM policy condition key, indirectly restricting access to any machine behind those EIPs, thus only in the VPC. Maybe it's a hack, maybe it's a workaround.
Update 11/08/2018
Introducing Amazon API Gateway Private Endpoints
One of the biggest trends in application development today is the use of APIs to power the backend technologies supporting a product. Increasingly, the way mobile, IoT, web applications, or internal services talk to each other and to application frontends is using some API interface.
Alongside this trend of building API-powered applications is the move to a microservices application design pattern. A larger application is represented by many smaller application components, also typically communicating via API. The growth of APIs and microservices being used together is driven across all sorts of companies, from startups up through enterprises. The number of tools required to manage APIs at scale, securely, and with minimal operational overhead is growing as well.
Today, we’re excited to announce the launch of Amazon API Gateway private endpoints. This has been one of the most heavily requested features for this service. We believe this is going to make creating and managing private APIs even easier.
Private endpoints
Today’s launch solves one of the missing pieces of the puzzle, which is the ability to have private API endpoints inside your own VPC. With this new feature, you can still use API Gateway features, while securely exposing REST APIs only to the other services and resources inside your VPC, or those connected via Direct Connect to your own data centers.
Here’s how this works.
API Gateway private endpoints are made possible via AWS PrivateLink interface VPC endpoints. Interface endpoints work by creating elastic network interfaces in subnets that you define inside your VPC. Those network interfaces then provide access to services running in other VPCs, or to AWS services such as API Gateway. When configuring your interface endpoints, you specify which service traffic should go through them. When using private DNS, all traffic to that service is directed to the interface endpoint instead of through a default route, such as through a NAT gateway or public IP address.
API Gateway as a fully managed service runs its infrastructure in its own VPCs. When you interface with API Gateway publicly accessible endpoints, it is done through public networks. When they’re configured as private, the public networks are not made available to route your API. Instead, your API can only be accessed using the interface endpoints that you have configured.
Related
I am trying to understand the best approach for working with highly sensitive data within my web application. My problem is this:
I have to gather information from the client. I then use that information to make a request to a third party API, which then returns information about the client (for example, personal financial data). I need to store this information in a DynamoDB and present the information back to the client in the front end. What is the recommended architecture to securely handle the data?
My initial thought was to create a custom VPC and private API gateway with a private API integration (to interact with the 3rd party API). What is the proven way to call the private API from my application? Do I need to call a function that is in a public subnet within the VPC and which then calls the private subnet? What is the proven way to write the data to dynamoDB once the 3rd party responds?
UPDATE
So I was looking around and saw approach that seemed to make sense to me. Within my public API I can attach my lambda to my VPC, Subnets, and Security Groups. Attaching in this way doesn't deploy the lambda inside the VPC, but an Elastic Network Interface (ENI) is created to link the lambda function and the different subnets inside the VPC. So I can use my lambda as a forwarder and send the message along to the private API in the VPC. Now I am getting a "User: anonymous is not authorized to perform: execute-api:Invoke on resource:.." response back. The work continues.
UPDATE
I think my assumption "Attaching in this way doesn't deploy the lambda inside the VPC, but an Elastic Network Interface (ENI) is created to link the lambda function and the different subnets inside the VPC."... is wrong and in fact the lambda will run in my custom VPC. Would like to confirm, because then if that is correct and it is running in my custom VPC, then I am all set.
What is the difference between Private Link and VPC endpoint? As per the documentation it seems like VPC endpoint is a gateway to access AWS services without exposing the data to internet. But the definition about AWS private link also looks similar.
Reference Link:
https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html
Does Private Link is the superset of VPC endpoint?
It would be really helpful if anyone provides the difference between these two with examples!
Thanks in Advance!
AWS defines them as:
VPC endpoint — The entry point in your VPC that enables you to connect privately to a service.
AWS PrivateLink — A technology that provides private connectivity between VPCs and services.
So PrivateLink is technology allowing you to privately (without Internet) access services in VPCs. These services can be your own, or provided by AWS.
Let's say that you've developed some application and you are hosting it in your VPC. You would like to enable access to this application to services in other VPCs and other AWS users/accounts. But you don't want to setup any VPC peering nor use Internet for that. This is where PrivateLink can be used. Using PrivateLink you can create your own VPC endpoint services which will enable other services to use your application.
In the above scenario, VPC interface endpoint is a resource that users of your application would have to create in their VPCs to connect to your application. This is same as when you create VPC interface endpoint to access AWS provided services privately (no Internet), such as Lambda, KMS or SMS.
There are also Gateway VPC endpoints which is older technology, replaced by PrivateLink. Gateways can only be used to access S3 and DynamoDB, nothing else.
To sum up, PrivateLink is general technology which can be used by you or AWS to allow private access to internal services. VPC interface endpoint is a resource that the users of such VPC services create in their own VPCs to interact with them.
Suppose there is a website xyz.com that I am hosting in a bunch of Ec2 instances, exposed to the outside world thru a Network load balancer.
Now, a client who has his/her own AWS account, wants to access this xyz.com from an Ec2 running in their aws account.
One approach is to go thru the Internet.
However the client wants to avoid the internet route.
He/she wants to use the AWS backbone to reach xyz.com.
The technology that enables that, is AWS Private link.
(note that if you search for Private Link in the AWS services, there will be none.
You will get "End point services" as the closest hit)
So, this is how to route traffic through the AWS backbone:
I, the owner of xyz.com, will create a VPC End Point Service (NOTE the keyword Service here)
The VPC End point service will point to my Network load balancer.
I will then give my VPC End point service name to the client.
The client will create a VPC End Point (NOTE.. this is different from #1).
While creating it, the client will specify the VPC End Point Service name (from #1) that he got from me.
I can choose to be prompted to accept the connection from the client to my VPC End point service.
As soon as I accept it, then the client can reach xyz.com from his/her EC2 instance.
There is no Internet, no direct connect or VPN.. this simply works; and its secure.
And which technology enabled it.. AWS Private link !!!
PRIVATE LINK IS THE ONLY TECHNOLOGY THAT ALLOWS 2 VPCS TO CONNECT THAT HAVE OVERLAPPING CIDR RANGES.
A useful way in understanding differences is in how they technically connect private resources to public services.
Gateway Endpoints route traffic by adding prefix lists within a VPC route table which targets the Gateway endpoint. It is a logical gateway object similar to a Internet Gateway.
In contrast, an Interface Endpoint uses Privatelink to inject into a VPC at the subnet level, via an Elastic Network Interface (ENI), giving network interface functionality, and therefore, DNS and private IP addressing as a means to connect to AWS public services, rather than simply being routed to it.
The differences in connections offer differing advantages and disadvantages (availability, resiliency, access, scalability, and etc), which then dictates how best to connect private resources to public services.
Privatelink is simply a very much abstracted technology to allow a more simplified connection by using DNS. The following AWS re:Invent offers a great overview of Privatelink: https://www.youtube.com/watch?v=abOFqytVqBU
As you correctly mentioned in the question that both VPC endpoint and AWS private link do not expose to internet. On AWS console under VPC, there is a clear option available to create an endpoint. But there is no option/label to create AWS private link. Actually, there is one more option/label called endpoint service. Creating endpoint service is one way to establish AWS private link. At one side of this AWS private link is your endpoint service and at the other side is your endpoint itself. And interestingly we create both these sides in two different VPCs. In other words, you are connecting two VPCs with this private link (instead of using internet or VPC peering).
understand like,
VPC1 got endpoint service ----> private link -----> VPC2 got endpoint
Here endpoint service side is service provider while endpoint is service consumer. So when you have some service (may be some application or s/w) that you think other VPC endpoints can consume you create endpoint service at your end and consumers will create endpoints at there end. When consumers create endpoints at their end they have to give/select your service name and thus private link will be established with your service.
Ultimately you can have multiple consumers of your service just like one to many relationship.
Based on the documentation, I know that 1 single VPC Endpoint can be shared for multiple API Gateway RestAPIs ( Private)
Each endpoint can be used to access multiple private APIs.
https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-private-apis.html
This option is interesting in that ( I believe) it offers the potential to minimize unnecessary resources. For example, say I have 50 private micro-services, and they are each sitting behind a dedicated RestAPI. If I re-use the VPC Endpoint for all 50 apis, then perhaps I can simplify the URLs that are provided to API developers/consumers.
Said another way, if I create dedicated VPC Endpoint per RestAPI, that means the API consumers need to understand many more VPC Endpoint configurations. Is this correct?
When exactly does it make sense to share VPC Endpoints?
When doesn't it make sense to share VPC Endpoints?
Any insights are appreciated. Just hoping to get some insights so I understand if I need to create unique VPC endpoints per RestAPI.
A VPC Endpoint is really just giving resources in your VPC access to the AWS API Gateway service. That allows resources in your VPC to access any APIs managed by API Gateway. It's very rare that you would need to create more than one of these per VPC. The only reason I can think of creating more than one is if you have some complicated VPC configuration where certain subnets need access to an API, while different subnets need access to a different API, and you wanted to manage that access via VPC route tables.
I'm looking to setup an AWS API Gateway which will have private APIs (internal business client apps only)
One of the client apps that will be making requests to 1 of the apis is a client that is on-prem.
What options are available to authenticate requests coming from a client when that client is on-prem? Is there some type of tunnel I am able to create between the on-prem client on AWS VPC?
I dont want to at all make the APIs public. So I want to continue to keep all apis private. Any and all insights appreciated.
The following tools are provided to enhance the security of API Gateway.
Firstly there's support for a private API Gateway. By doing this it will only be accessible from the VPC and devices connected via VPN or Direct Connect to the API Gateway.
If it must be publicly accessible, but kept private you can lockdown he endpoint via either an API Gateway Resource Policy or by attaching a WAF to your API Gateway.
Finally if you need more advanced methods of authenticating and providing authorization to specific routes in your API, then you should look at API Gateways feature of Lambda Authorizers.
It looks like the simple answer is:
Option 1: Use Direct Connect
https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html
or
Option 2: Use AWS Site-to-Site VPN
https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html
I have a situation when my product(some Web API) is living inside of VPC, i.e. with no any any external access. I'd like to expose the part of this APIs(just a couple of HTTP methods) to be accessible from the internet. I'm trying to achieve this using AWS API Gateway but it looks like I cannot make internal ELB endpoint the API Gateway resource. Any ideas how can I do this?
Thanks,
--Vovan
This was originally not possible, and then was solved with support for client certificates that API Gateway could use to authenticate itself to your services. This was a good solution, and is still available, but still required your services to be exposed -- at least in some sense -- to the Internet.
In November, 2017, AWS released a new capability that allows you to actually provision a network path between API Gateway and your internal services.
You can now provide access to HTTP(S) resources within your Amazon Virtual Private Cloud (VPC) without exposing them directly to the public Internet. You can use API Gateway to create an API endpoint that is integrated with your VPC. You create an endpoint to your VPC by setting up a VPC link between your VPC and a Network Load Balancer (NLB), which is provided by Elastic Load Balancing.
https://aws.amazon.com/about-aws/whats-new/2017/11/amazon-api-gateway-supports-endpoint-integrations-with-private-vpcs/
Historical context follows.
As of now, there is no simple and foolproof way to do this, because your services that are accessible to API Gateway need to be accessible via/exposed to the public Internet and there is no built in trust mechanism by which you can be assured that such a request actually originated from any API Gateway deployment, much less your API Gateway deployment.
Amazon seems to have solved the issue of authenticating requests to your back-end services as having assuredly come, not only from API Gateway, but from your API Gateway instance. As before, endpoints still need to be exposed to the Internet, since the source IP address is not predictable -- but API gateway now supports client SSL certificates, which the back-side of API Gateway uses to authenticate itself to the front-side of your back-end service, that API gateway is calling.
Q: Can Amazon API Gateway work within an Amazon VPC?
No. Amazon API Gateway endpoints are always public to the Internet. Proxy requests to backend operations also need to be publicly accessible on the Internet. However, you can generate a client-side SSL certificate in Amazon API Gateway to verify that requests to your backend systems were sent by API Gateway using the public key of the certificate.
Q: Can I verify that it is API Gateway calling my backend?
Yes. Amazon API Gateway can generate a client-side SSL certificate and make the public key of that certificate available to you. Calls to your backend can be made with the generated certificate, and you can verify calls originating from Amazon API Gateway using the public key of the certificate.
— https://aws.amazon.com/api-gateway/faqs/#security
When you generate a client certificate in the API Gateway console, you're provided with the public key for that certificate. For security, the private key is retained by API Gateway and is not accessible to you. API Gateway will present the public key to your back-end when negotiating SSL. Any peer not presenting that same public key is not API gateway, and your back-end should deny SSL negotiation.
If a malicious actor should ever come into possession of the public key, they would not still be able to communicate with your back-end over SSL, because they would lack the mated private key, which is only known to API Gateway. (Your side of the interaction would be encrypted using your SSL certificate and it's mated private key, which is of course, known only to you.)
This capability addresses what previously appeared to be a significant limitation of the utility of API Gateway's HTTP proxy functionality... a limitation of such significance, in fact, that when I discovered the revised information, above, I began to doubt myself: Had this been there all along, and I had somehow managed to overlook it? The Wayback Machine says no, it's new. This information was added in September, 2015.
It's somewhat of a circuitous path, but you can proxy your Web service endpoints that are in a VPC through a Lambda function. That Lambda function can be called directly from the API Gateway. This blog post gives details on how to do that.