Created behavior in AWS cloud front like
/api/* to Application load balancer
default (*) to S3
want to route the traffic to maintenance page bucket during code deployment time, should allow to do smoke test from my static ip when set maintenance page.
How to archive this?
WAF - You can whitelist certain IP for smoke test and for the others IP present maintenance page.
Lambda#Edge
Related
Halo, i’m a dev recently diving into cloudflare security layers and got few questions on a website security which is deployed to cloudflare. I’m using Pages and my domain is directly hosted by cloudflare Registrar. I’m also using the security layers provided with cloudflare infrastructure, including [ Bots, DDos, Settings, Page Shield ], which can be found in security tab of my domain in cloudflare dashboard. Below list is my questions:
security layers in use: [ Bots, DDos, Settings, Page Shield ]
I’m using firebase hosting to link my firebase functions with the domain which is hosted by cloudflare. In this case, do the above listed security layers of cloudflare automatically protect the firebase hosting resources or traffics?
I’m using cloudflare workers to manage Durable Objects. The Workers’ functions are also linked to the same root domain with different subdomain. In this case, do the above listed security layers of cloudflare automatically protect the Worker traffics?
the proxy status of firebase hosting connection is “DNS only” mode(not “Proxied” mode), since in the case of Proxied, the dns connection does not work(i didn't figure out the reason yet..). In this case, it makes me feel like the firebase hosting resources are not being protected since the orange switch in DNS dash is turned off
please consider the cloudflare plan is Pro
Thank you in advance [:
For the products you are listing, Cloudflare is implemented as a reverse proxy.
This means that from an end user perspective, when they try to connect to your services, their traffic reaches Cloudflare first (since a proxied record resolves to a Cloudflare anycast IP). Cloudflare carries out the features and security services that are configured, then forwards the HTTP requests to your origin infrastructure as specified in your Cloudflare DNS tab. This is true when the traffic is directed to proxied records.
For records in DNS-only mode, Cloudflare only performs DNS resolution (answering to the DNS query for that DNS record). Once this is done, the client will connect directly to the specified resource and the traffic will not be flowing through the Cloudflare network, meaning Cloudflare cannot provide proxy services in this scenario.
For a full explanation, I recommend the following documentation page
I have created a load balancer on my Google Cloud app engine, and also have added SSL certificates to them, but the links of the App Engines are still active and don't have any security on them.
So I wanted to know how can I close or disable those links of the app engine?
And secondly,
Can we do something like only the load balancer is able to access the App Engine and the load balancer is open to public and the app engine links are closed for the public access.
Something like if the load balancer had a static IP we could have added it to the App engine firewall and allowed that IP and denied the rest?
Please Help me with this scenario.
You can configure the ingress for App Engine so requests sent to the default URL are discarded and only the Load Balancer will be capable to communicate with the backend service.
To do so, you can modify the ingress controls and set it to Internal and Cloud Load Balancing, so your app will only receive requests that are routed through Cloud Load Balancing, or that are sent from VPC networks in the same project. All other requests will be denied with a 403 error.
I think also this page from the documentation on how requests are routed with Cloud Balancing is worth a read for your use case.
In your GCP cloud console, go to App Engine > Firewall rules.
Click on Create rule and allow ingress from the LoadBalancer's public IP ranges 130.211.0.0/22 and 35.191.0.0/16 ranges.
for reference
Question: How do I host an endpoint in azure which allows me to redirect internet traffic at will between azure and aws services?
I am hosting two kubernetes clusters - one in Azure and the other in AWS. I want to be able to:
1. redirect the traffic at will to either aws or azure, whilst retaining the public dns endpoint.
2. fail over manually [and pref automatically too] to the aws cluster. What is the best way to host the endpoint in azure?
Requirements:
The traffic needs to be redirected immediately - no caching issues and stale loads!
Ability to configure failover - i.e. specify that Azure is hot and AWS is the failover service - the traffic should be automatically redirected as soon as Azure goes down.
I have looked at Traffic Manager, Load Balancers and Application Gateway. Not sure which one (if any) of these is best.
traffic manager wont work for you, since its a dns service, so caching will happen (admittedly its the best solution if you set dns cache to 5 seconds or something). application gateway allows you to specify an ip address as an endpoint, load balancers only work when attached to vms inside azure. But application gateways dont allow to failover at will. you would need to block the probe to failover.
Azure Front Door might be the solution for you (like the other answer mentions)
You can have a look into Azure Front Door Service for your usecase.
Look into this https://learn.microsoft.com/en-gb/azure/frontdoor/front-door-overview
Namecheap and other registrars provide a way to setup HTTP 301 or 302 redirects when configuring DNS. It is a nice feature since otherwise you would need to implement it yourself. See screenshot below from Namecheap DNS configuration page.
Does Google Cloud DNS offer something similar?
Google Cloud DNS does not provide a "URL Redirect". This isn't actually a DNS feature - it requires a webserver to serve the 302 redirect. You could implement this with a small cloud funciton like:
exports.redirectFunc = function redirectFunc (req, res) {
res.set('Location', 'https://example.com/destination');
res.status(302);
res.end();
};
Firebase now has a very simple setup to achieve domain redirection, just do the following:
[Your firebase project] > Console > Hosting > Connect domain
Then it should display the following:
Although Google Cloud DNS does not have this feature, if you register your domain with Google Domains, it has a "subdomain forwarding" feature (https://support.google.com/domains/answer/6072198 that implements not only 301 / 302 redirects but also provides integrations for G Suite and other platforms that set up other types of synthetic records (https://support.google.com/domains/answer/6069273).
Google Domains runs on the same DNS serving infrastructure as Google Cloud DNS, but currently you have to choose between the "Google Domains name servers" and Google Cloud DNS name servers that serve managed zones that you can control programmatically with the Google Cloud DNS API. This means you have to choose between the Domains-specific features like synthetic records and the Cloud DNS API and GUI console. You can delegate subdomains of a domain hosted on the Google Domains name servers to specific managed zones in Cloud DNS, so it is possible to mix and match this a bit.
Though it isn't supported directly in Cloud DNS yet (see issue: https://issuetracker.google.com/issues/70980380) a workaround can be to deploy an HTTP(S) Load Balancer and set up a redirect in the URL-map and then map the root domain to the IP address of the load balancer via an A record in Cloud DNS (and the same load balancer can be used to serve all subdomains as well without requiring any other Cloud DNS records), see: https://cloud.google.com/load-balancing/docs/url-map-concepts#url-redirects
I am looking for an easy way to fail over to a different DC quickly, does CloudFlare offer anything special in this regards with things like health checks or is it just like a standard DNS service?
Update: CloudFlare started a closed beta for the Traffic Manager feature which allows to do exactly this kind of failover:
https://www.cloudflare.com/traffic-manager/
AWS Failover:
The following solution seems to work well when you are hosting your backend system on AWS:
I setup a AWS Route 53 zone with a separate domain (e.g. failover-example.com). Route 53 allows you to setup health checks on the backend server (e.g. the load balancer) with DNS failover. AWS will remove the unhealthy backend system from the DNS record list.
In cloudflare I setup a CNAME for example.com record to failover-example.com and activate the cloudflare proxy on example.com.
The result is that the browser resolves the IP address of example.com to a cloudflare IP address. Cloudflare queries the AWS DNS server to lockup failover-example.com. Cloudflare fetches the content from the resolved IP address and returns the content back to the browser.
In my tests the switch to the other backend system occurs after ca. 20 seconds.
The separate domain is required because cloudflare does not route the traffic through the proxy when the CNAME is a subdomain of example.com.
I have tried to visualize the failover. In theory the failover works with any DNS failover capable service and not only with Route53:
The browser connects always with CloudFlare and hence a DNS failover of the backend system does never effect the browser of the user.
We don't have automatic failover at this time (something we're looking at). We can support the additional DNS entries in your zone file, of course, but you would currently have to manually make the change in that circumstance.
To add -- in the mean time, I'd recommend looking at https://runbook.io
Several other DIY options:
http://blog.booru.org/?p=12
https://vpsboard.com/topic/3341-running-your-own-failover-dns-setup/
https://github.com/marccerrato/python-dns-failover
You'd want to decide if these are the right options for you, of course.