I would like to configure access control based on source IP address with Google Cloud Functions.
(Only allowed IPs can reach Google Could Functions.)
I suppose there is no way for Google Cloud Functions itself to limit client IPs.
So I have an idea to put some gateways in front of the Cloud Functions, such as Apigee, API Gateway and Cloud Endpoints.
I found that only Apigee has souce IP access control, but I wonder that Apigee is too rich for my simple workload.
https://cloud.google.com/apigee/docs/api-platform/reference/policies/access-control-policy?hl=ja
Is it possible to use API Gateway or Cloud Endpoints to configure source IP based access control?
Related
I have a Google Cloud Run services and i would need to allow traffic from certain machine only.
I use Google cloud armor to allow IPs to access the Cloud Run service.
I have problem in adding dynamic IPs of certain machine as it keeps changing. I also searched on adding mac address to allow, but Cloud armor does not have that feature.
You cannot use MAC addresses for the Internet. The service (Cloud Armor) will never see the client's MAC address, only the MAC address of the last router (which would be a Google router). Google Cloud VPCs do not expose layer 2 information.
Cloud Run is a public service with a public URL. Restricting traffic based upon IP address is not supported by Cloud Run. You can put an HTTP Load Balancer and Cloud Armor in front, but that would not prevent traffic that goes directly to the service.
There are much better techniques to control access to public services. Google Cloud implements authorization using OAuth via Identity Aware Proxy (IAP). That is the correct method to use. Given that your clients have changing IP addresses, that is your best solution.
If I needed access control based upon IP address, I would run my service on Compute Engine using either Container Optimized OS, Docker or just natively using Apache/Nginx. You can dynamically update VPC firewall rules as the client's IP address changes with custom code.
I am trying to use Google Workflows to make HTTP POST requests to a service that uses a whitelisted IP list. How can I find an IP, or range of IPs that I could give to the vendor?
You can whitelist all the IP range reserved by Google Cloud. But at the end, it's like if you allow all users. Indeed, any users (or attackers) that use Google Cloud services will use one of the Google IP ranges, anyone will be able to access your service.
The best solution is to use a Cloud Functions or a Cloud Run as proxy. Cloud Workflows call that proxy internally at Google Cloud. Then, on the proxy service, you can plug a serverless VPC connect (with egress param set to all traffic) and a CLoud NAT to reserve a static public IP ONLY FOR YOU, and you will be able to allowlist it securely because ONLY YOU will be able to use it.
Here the doc of Cloud Run, but it's pretty similar on Cloud Functions.
I have an API which is deployed in GKE and exposed via Cloud Endpoints with ESPv2. I have secured the API using API key as of now and its available via internet. Is there any possible way I can apply some firewall rules that the endpoint is available only from a certain network or range of IPs ?
You need to define an ingress with a global HTTPS load balancer in front of your ESPv2 service.
Then, you can activate Cloud Armor and set policies to filter the IPs and ranges that you want
Google APIs and Services that are supported by VPC Service Controls based on Supported products and limitations available here includes Pub/Sub, Cloud Monitoring and Cloud Logging.
However a related documentation available here about configuring Private Google Access for on-premises hosts available here has Pub/Sub, Monitoring and Logging listed under Reached using Private Google Access but not secured by VPC Service Controls.
I am confused reading this. Can Pub/Sub access (as well as Monitoring and Logging) be secured by VPC Service Controls or not?
Edit
Uploaded image of new VPC Service Control creation screen that allows PubSub to be selected as one of the services to be restricted.
After reviewing both documents, I can see that, as you commented, Pub/Sub is a Supported VPC SC product. However, the combination of these 3 products: Private Google Access + VPC SC + Pub/Sub will not work. Therefore you can secure these products (Pub/Sub, Monitoring and Logging) by using VPC Service Controls without using Private Google Access (service that allow on-premises hosts to reach the Google APIS without using public IPS)
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.