Use custom domain for Google Cloud Function - google-cloud-platform

I can't see any option anywhere to set up a custom domain for my Google Cloud Function when using HTTP Triggers. Seems like a fairly major omission. Is there any way to use a custom domain instead of their location-project.cloudfunctions.net domain or some workaround to the same effect?
I read an article suggesting using a CDN in front of the function with the function URL specified as the pull zone. This would work, but would introduce unnecessary cost - and in my scenario none of the content is able to be cached so using a CDN is far from ideal.

If you connect your Cloud project with Firebase, you can connect your HTTP-triggered Cloud Functions to Firebase Hosting to get vanity URLs.

Using Cloudflare Workers (CDN, reverse proxy)
Why? Because it not only allows you to set up a reverse proxy over your Cloud Function but also allows you to configure things like - server-side rendering (SSR) at CDN edge locations, hydrating API response for the initial (SPA) webpage load, CSRF protection, DDoS protection, advanced caching strategies, etc.
Add your domain to Cloudflare; then go to DNS settings, add a A record pointing to 192.0.2.1 with Cloudflare proxy enabled for that record (orange icon). For example:
Create a Cloudflare Worker script similar to this:
function handleRequest(request) {
const url = new URL(request.url);
url.protocol = "https:";
url.hostname = "us-central1-example.cloudfunctions.net";
url.pathname = `/app${url.pathname}`;
return fetch(new Request(url.toString(), request));
}
addEventListener("fetch", (event) => {
event.respondWith(handleRequest(event.request));
});
Finally, open Workers tab in the Cloudflare Dashboard, and add a new route mapping your domain URL (pattern) to this worker script, e.g. example.com/* => proxy (script)
For a complete example, refer to GraphQL API and Relay Starter Kit (see web/workers).
Also, vote for Allow me to put a Custom Domain on my Cloud Function
in the GCF issue tracker.

Another way to do it while avoiding Firebase is to put a load balancer in front of the Cloud Function or Cloud Run and use a "Serverless network endpoint group" as the backend for the load balancer.
Once you have the load balancer set up just modify the DNS record of your domain to point to the load balancer and you are good to go.
https://cloud.google.com/load-balancing/docs/https/setting-up-https-serverless

Been a while for this answer.
Yes, now you can use a custom domain for your Google Cloud functions.
Go over to firebase and associate your project with firebase. What we are interested in here is the hosting. Install the Firebase CLI as per the firebase documentation - (very good and sweet docs here)
Now create your project and as you may have noticed on the docs, to add firebase to your project you type firebase init. Select hosting and that's it.
Once you are done, look for the firebase.json file. Then customize it like this
{
"hosting": {
"public": "public",
"ignore": [
"firebase.json",
"**/.*",
"**/node_modules/**"
],
"rewrites": [
{
"source": "myfunction/custom",
"function": "myfunction"
},
]
}
}
By default, you get a domain like https://project-name.web.app but you can add your own domain on the console.
Now deploy your site. Since you are not interested in web hosting probably you can leave as is. Now your function will execute like this
Function to execute > myfunction
Custom url > https://example.com/myfunction/custom

If you don't mind the final appearance of the url you could also setup a CNAME dns record.
function.yourdomain.com -> us-central1******.cloudfunctions.net
then you could call it like
function.yourdomain.com/function-1/?message=Hello+World

Related

Allowing users to point their domain names to my service

I am giving my services to my users via client.example.com and there are pages like
client.mysite.com/blog
client.mysite.com/blog/content/
client.mysite.com/docs/
etc.
I want to allow users to allow their domains to point to this subdomain.
so they can choose between any of the 1 option below :
client.com -> client.example.com
sub.client.com -> client.example.com
client.com/sub/ -> client.example.com
and pages should work automatically like
client.com/blog -> client.example.com/blog
sub.client.com/blog -> client.example.com/blog
client.com/sub/blog -> client.example.com/blog
Also, I use Elastic Beanstalk in Amazon to deploy my React application with nginx (Docker image ). Before I start I want to know if this is possible.I also don't want to give fixed IP address to my clients, just in case if I lose that IP. How are the big players like blogger.com, wordpress.com etc doing it?
As far as I researched I know cname is possible to allow clients subdomains and we need IP address for named domain. nowhere it mentioned about the folder. And for SSL, I can use LetsEncrypt.
I am OK with anything like CloudFlare / Route53 method.
Cloudflare for SaaS is designed for this use case. You would just go to Cloudflare Dashboard > You Domain (example.com) -> SSL -> Custom Hostnames. Add a fallback hostname to which you client will link to, e.g. ssl.example.com.
Then client then would need to add his or her custom hostname in your app, then link and verify his custom domain by adding a CNAME (pointing to ssl.example.com) and TXT record via his own DNS provider. The verification and issuing a new SSL would take a few minutes, completely handled by Cloudflare and from there on, your clients may access your service via custom hostname (e.g. client.com, sub.client.com, client.com/blog etc.)
If you need to manipulate the HTTP response as it goes through the customer's hostname, it's also possible to route these request through a CLoudflare Worker script (linked to */* — all hostnames/URLs).
Here is an example, of how to create a custom hostname programmatically:
import * as Cloudlfare from "cloudflare-client";
// Initialize custom hostnames client for Cloudlfare
const customHostnames = Cloudflare.customHostnames({
zoneId: process.env.CLOUDFLARE_ZONE_ID,
accessToken: process.env.CLOUDFLARE_API_TOKEN,
});
// Add the client's custom hostname record to Cloudflare
const record = await customHostnames.create(
hostname: "www.client.com",
ssl: {
method: "txt",
type: "dv",
settings: {
min_tls_version: "1.0",
},
}
);
// Fetch the status of the custom hostname
const status = await customHostnames.get(record.id);
// => { id: "xxx", status: "pending", ... } including TXT records
Pricing
CF for SaaS is free for 100 hostnames and $0.10/hostname/mo after (source).
Path-based URL forwarding
If you need to forward HTTP traffic to different endpoints, e.g. www.client.com/* (customer domain) to web.example.com (SaaS endpoint); www.client.com/blog/* to blog.example.com, etc.
You can achieve that by creating a Cloudfalre Worker script with a route handling */* requests (all customer hostnames, and all URL paths), that would look similar to this:
export default {
fetch(req, env, ctx) {
const url = new URL(req.url);
const { pathname, search } = url;
if (url.pathname === "/blog" || url.pathname.startsWith("/blog/")) {
return fetch(`https://blog.example.com${pathname}${search}`, req);
}
return fetch(`https://web.example.com${pathname}${search}`;
}
}
References
https://developers.cloudflare.com/cloudflare-for-saas/
https://github.com/kriasoft/cloudflare-client
https://github.com/kriasoft/cloudflare-starter-kit
The simplest approach to this, which I’ve implemented at scale (10,000+ clients), is to:
DNS
Have your clients create a CNAME record to either a specific client.example.com or general clients.example.com. This applies to both root (set the ALIAS record instead) and subdomains—an IP address is not required, nor recommended as it does not scale.
Create a database entry that registers/links that explicitly links their domain/subdomain to their account.
Have logic in the backend controller will that associates the hostname in the request to a specific client (security measure) to serve relevant content.
The above fulfills the first two use cases—it allows the client to link a root domain or subdomain to your service.
To achieve the third use case, you could allow the client to specify an arbitrary root path for your service to run within. If the client chooses this, you also need to handle redirects to other services that they have on their domain. This is a lot of responsibility for your app, however.
You could just leverage their registrar, most registrars have the ability to do path redirects—this is the simplest approach that requires the least amount of responsibility/maintenance on your end.
I also recommend having an option for redirecting all entry points (ie: root domain, subdomain, root domain+path, subdomain+path) to a primary entry point (ie: root domain + path), for SEO purposes.
Note: You may also use a service, such as wwwizer, that redirects to the www specified if the ALIAS option on the root domain of your client isn't available.
SSL
I recommend using Let's Encrypt's ACMEv2 API to enable SSL for any domain that is setup on your service. There are libraries available that you should be able.
What is worth mentioning is the challenge — which can occur via DNS or HTTP. When the library you decide on makes a request for a new certificate Let's Encrypt will respond by making a request to ensure that you control the domain (by checking DNS record for a predetermined unique hash) or that you control the server it points to (by checking HTTP path for a predetermined unique hash). What that means is that you need to ensure that your client either includes a hash in their DNS that you specify or you expose a route that adheres to the ACME v2 challenge response protocol (handled by the library you choose).
Here is an example library that you could use if the service you are building is based on python, which supports all features mentioned above and also includes a cli: https://github.com/komuw/sewer .
References
https://help.ns1.com/hc/en-us/articles/360017511293-What-is-the-difference-between-CNAME-and-ALIAS-records-
https://letsencrypt.org/docs/client-options/
https://datatracker.ietf.org/doc/html/rfc8555
http://wwwizer.com
I think what you are asking is how to have the client have their own domain, which they own, have a subdomain which points to your website, with a matching certificate somehow. But just from a security standpoint there is no safe way to do this IMO. Here are the ways off the top of my head you can do this:
You Manage DNS of Subdomain
Your customer could create a NS record to a public Route53 distribution which you own. Then that subdomain would effectively be yours, and you can create DNS records in their subdomain, and certificates in ACM which you can use in a Cloudfront Distribution. You can have multiple FQDN in the one certificate so you won't have to have multiple distributions. You will need to add the domains to the aliases in your distribution as well.
Client Manages own DNS but you tell them what to do
I'm not sure this works as I haven't tried it, but in the DNS validation of a ACM certificate you can see the records you need to create, you would tell the client the CNAME record which they need to create for AWS to issue a certificate for the given domain i.e. sub.client.com, and they would also need to create CNAMEs to point to your website. This way the client still manages their own DNS.
Import Certificate
You could get your client to create a cert for you can then you could import it. They would also need to create the CNAME records to point to your website. And again they would need to create a CNAME to point to your site. Probably least secure, and certs will require manual rotation.
Cloudfront
Your client can use your website as an origin in their own Cloudfront Distribution, bit hacky but would work. I don't think this scales with growing customers.
Summary
IMO I don't like any of those solutions, they are all messy, most likely non-compliant with security standards, and hard to automate if at all. Not to say there aren't situations where you might do this. I would suggest you create subdomains for your own domain, or otherwise consider yourself a hosting company and then you would own/manage your client's domains on their behalf then this easier. But IMO it does not make sense to own a domain, and then give out control to it, or transfer certificates. You'll run into trouble with customers who need to hold certain certifications, or need you to hold those, such as SOC2 for example.

AWS Route 53 Domain Point To Github Pages

I am new to working with AWS and route 53 so any help is appreciated.
I have created an organization on GitHub, and then created a simple repository for a static site to display with Github pages. this is working as expected and I can see the static site at the URL generated by Github (something like: https://<githubOrgName>.github.io/<repoName>/)
I got a domain from AWS and now I'm trying to set it up so the apex domain (e.g. "my-domain.com") points to the Github pages site.
I followed the instructions found at: https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site/about-custom-domains-and-github-pages ... but it doesn't seem to be working.
I am trying to make it so that the apex domain points to the repository Github page. something like:
https://my-domain.com -> https://<githubOrgName>.github.io/<repoName>/
... but this only shows a blank screen when I go to the root domain ("my-domain.com"). I have also tried to go to https://my-domain.com/<repoName>/... but this shows me a Github 404 page (so it seems to be correctly forwarding something to Github):
my AWS route 53 configuration is similar to the following (i have tried to remove sensitive details):
can anyone explain to me what I am doing wrong? I am new to working with domains so any help is appreciated.
Using Route53 alone won't help you there, because your target URL contains a URL path i.e. /<repoName>/.
DNS is a name resolution system and knows nothing about HTTP
Furthermore, the origin server (github.io) might be running a reverse proxy which might be parsing the request headers, among which is the Host header. You browser automatically sets this header to the url you feed it. Eventually, you send it the wrong header (i.e. https://my-domain.com/), which Github cannot process. You can explicitly set this header (e.g. via curl) to what Github is expecting, but I believe it's not what you and your users would like.
Instead, you could try using layer 7 redirects (301/302) with the help of Lambda#Edge (provided by AWS CloudFront). I have created a simple solution using the Serverless framework, which does the following redirects:
https://maslick.tech -> https://github.com/maslick
https://maslick.tech/cv -> https://www.linkedin.com/in/maslick/
https://maslick.tech/qa -> https://stackoverflow.com/users/2996867/maslick
https://maslick.tech/ig -> https://www.instagram.com/maslick/
But you can customize it by adjusting handler.js according to your needs. You might also need to create a free TLS certificate using AWS Certificate Manager in the us-east-1 region and attach it to your CloudFront distribution. But this is optional.
Lambda#Edge will give low latencies, since your redirects will be served from CloudFront's edge locations across the globe.
How I got it to work was:
Set a CNAME record from example.org to <USERNAME>/github.io. in the Route 53 console
Set Custom domain to example.org in the Github Pages settings for github.com/<USERNAME>/<REPO>
Note: You shouldn't be setting the CNAME record to <USERNAME>/github.io/<REPO>
Source: https://deanattali.com/blog/multiple-github-pages-domains/

Custom doman (with SSL) for Cloud Functions [duplicate]

I can't see any option anywhere to set up a custom domain for my Google Cloud Function when using HTTP Triggers. Seems like a fairly major omission. Is there any way to use a custom domain instead of their location-project.cloudfunctions.net domain or some workaround to the same effect?
I read an article suggesting using a CDN in front of the function with the function URL specified as the pull zone. This would work, but would introduce unnecessary cost - and in my scenario none of the content is able to be cached so using a CDN is far from ideal.
If you connect your Cloud project with Firebase, you can connect your HTTP-triggered Cloud Functions to Firebase Hosting to get vanity URLs.
Using Cloudflare Workers (CDN, reverse proxy)
Why? Because it not only allows you to set up a reverse proxy over your Cloud Function but also allows you to configure things like - server-side rendering (SSR) at CDN edge locations, hydrating API response for the initial (SPA) webpage load, CSRF protection, DDoS protection, advanced caching strategies, etc.
Add your domain to Cloudflare; then go to DNS settings, add a A record pointing to 192.0.2.1 with Cloudflare proxy enabled for that record (orange icon). For example:
Create a Cloudflare Worker script similar to this:
function handleRequest(request) {
const url = new URL(request.url);
url.protocol = "https:";
url.hostname = "us-central1-example.cloudfunctions.net";
url.pathname = `/app${url.pathname}`;
return fetch(new Request(url.toString(), request));
}
addEventListener("fetch", (event) => {
event.respondWith(handleRequest(event.request));
});
Finally, open Workers tab in the Cloudflare Dashboard, and add a new route mapping your domain URL (pattern) to this worker script, e.g. example.com/* => proxy (script)
For a complete example, refer to GraphQL API and Relay Starter Kit (see web/workers).
Also, vote for Allow me to put a Custom Domain on my Cloud Function
in the GCF issue tracker.
Another way to do it while avoiding Firebase is to put a load balancer in front of the Cloud Function or Cloud Run and use a "Serverless network endpoint group" as the backend for the load balancer.
Once you have the load balancer set up just modify the DNS record of your domain to point to the load balancer and you are good to go.
https://cloud.google.com/load-balancing/docs/https/setting-up-https-serverless
Been a while for this answer.
Yes, now you can use a custom domain for your Google Cloud functions.
Go over to firebase and associate your project with firebase. What we are interested in here is the hosting. Install the Firebase CLI as per the firebase documentation - (very good and sweet docs here)
Now create your project and as you may have noticed on the docs, to add firebase to your project you type firebase init. Select hosting and that's it.
Once you are done, look for the firebase.json file. Then customize it like this
{
"hosting": {
"public": "public",
"ignore": [
"firebase.json",
"**/.*",
"**/node_modules/**"
],
"rewrites": [
{
"source": "myfunction/custom",
"function": "myfunction"
},
]
}
}
By default, you get a domain like https://project-name.web.app but you can add your own domain on the console.
Now deploy your site. Since you are not interested in web hosting probably you can leave as is. Now your function will execute like this
Function to execute > myfunction
Custom url > https://example.com/myfunction/custom
If you don't mind the final appearance of the url you could also setup a CNAME dns record.
function.yourdomain.com -> us-central1******.cloudfunctions.net
then you could call it like
function.yourdomain.com/function-1/?message=Hello+World

AWS Api gateway custom domain routing to wrong base url

I'm developing an Angular Universal serverless app in AWS Lambda/Api gateway. The app works perfectly using the standard api url ( {api-id}.execute-api.{region}.amazonaws.com/{stage}/) but now I'm trying to deploy it in a human-readable url using Api Gateway's Custom domain names.
For that I followed the docs and troubleshooted using other stackoverflow's questions, but now I'm faced with a problem and can't find another question that looks like my problem.
I have already setup the API, the custom domain name (which created a cloudfront distribution) and a Route53 A-type ALIAS routing to this new cloudfront distribution and the routing kind of works.
The problem I'm facing is that when I'm using the new domain name, the angular app cant find assets like CSS, Icons,etc. All of them works fine using the standard api url but not with the custom.
To do some debugging I configured Api Gateway to log requests to CloudWatch, and I can see that when I'm using the standard url, the resource path log is like this:
HTTP Method: GET, Resource Path: /main.4d57a71fd195330e8ee9.js
But when I use the custom URL the same log is like this:
HTTP Method: GET, Resource Path: /development/main.4d57a71fd195330e8ee9.js
I'm guessing it has something to do with the base URL in the custom domain name configuration of Api Gateway, I tried changing it to everything I could think of but nothing fixed it.
Here is a screenshot of my Api Gateway configuration.
Api gateway - Custom Domain Names configuration
Tell me if you need anything more and sorry if bad english.
Thanks in advance.
EDIT: I should make clear that I'm trying to point to the "development" stage of my api
I believe you simply need to reconfigure your custom domain. It should be sufficient for you to change the following;
In "Base Path Mappings" section change Path from "/development" to just "/"
I had similar problem. The only workaround for me is to set baseHref to "/" in environment.serverless.ts and have one single mapping in custom domain name from "/" to "{YOUR-API}:production".
This breaks direct url access to the API but access via custom domain name works fine.

AWS Api Gateway + Lambda + custom domain (Route53) Missing Authentication Token issue

I am aware that many similar questions have been posted and answered here but none of them is quite the same with what I am experiencing.
I have a Lambda function that handles incoming requests (GET and POST). I also set up an api gateway as public facing endpoint. Additionally, I set up custom domain following Set up Custom Domain Name for API Host Name
The testing call works in both of lambda and api gateway console. Everything also works using the invoke URL but not with the custom domain I've set up.
Here are some more details:
Invoke URL (Works) :
https://{api gateway id}.execute-api.us-west-2.amazonaws.com/prod/endpoint
Custom domain endpint (Doesn't work):
https://api.{my domain}.com/endpoint
Base Path Mapping:
/endpoint endpoint:prod
All Method Auth:
Authorization None
API Key Not required
Route53:
A record as alias that points api.{my domain}.com to the cloudfront distribution domain name as alias target.
I'd really appreciate if anyone knows what's going out here.
I had met the same question several years ago and solved it by removing the 'stage' name from the URL.
the URL of gateway API seems like the following:
https://{id}.execute-api.{region}.amazonaws.com/{stage}/todos
if you have routed a custom domain https://api.xxx.com to gateway API {apiName}:{stage}, it seems like the following:
https://api.xxx.com
path: /
target: {apiName}:{stage}
Finally, the correct way to call it is to remove the stage name:
// **remove stage name!!!!**
// Right
https://api.xxx.com/todos
// Wrong
https://api.xxx.com/{stage}/todos
I found the issue is misunderstanding of how base path mapping works.
All my configurations are correct.
My API resource is not under / but under /endpoint
To use the custom domain, instead of visiting https://api.{my domain}.com/endpoint, it needs to go to https://api.{my domain}.com/endpoint/endpoint
Of course this is silly and redundant.
I have two options. I either set up the base path mapping to / instead of /endpoint or I can just user the API resource / instead of /endpoint.
I go with the latter because if base path mapping is set to /, my api.{my domain}.com will only be able to host just one API (I can still use resources under the same API, but why wasting the extra layer of abstraction?).
This seems dump but I am still glad I figured it out.
Another reason for this can be that your user, although admin, does not have a bloody CloudFrontFullAccess permissions! I just spent a couple of hours on it as I relied on serverless to do it for me and it worked perfectly on another project with different credentials, though. So double check the article! https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-custom-domains.html
Step 1: Map the A record from subdomain.yourdomain.com to API Custom domain/API Gateway domain name(API Gateway -> Custom domain names -> tab Configuration/Endpoint Configuration).
Step 2: From API Gateway/ API Custom domain - add the api mapping. Leave "path" empty.
End point format:
Original endpoint: https://{api gateway id}.execute-api.us-west-2.amazonaws.com/prod/endpoint
Endpoint with API custom domain: https://api.yourdomain.com/**endpoint**