So my plan is to secure a set of physical servers in a private network against the entire NSX-T workload domain, without buying an additional hardware firewall, since we have massive edge capacity left, but no money. :/
So intuitively I would just add an NSX gateway firewall, just like it's described in this blog post:
https://blogs.vmware.com/networkvirtualization/2020/08/the-nsx-t-gateway-firewall-secures-physical-servers.html/
But there it's the easy case, when the firewall is just added to the default T0, which I can't do due to our active/active setup. So I would have to add an additional active/passive T0 and connect it to the existing T0.
But how do I now force traffic to my private network through the additional T0 including the gateway firewall?
Apprently this is impossible to achieve without bridging only the second T0 to the private network's vlan and omitting the route via the physical BGP router. Or is there a chance?
So if the private network is routed via the physical BGP uplink router, there is indeed no way, but to hide this route on the physical BGP. This wouldn't make too much sense anyways, so let's consider the case where it doesn't.
Then there are apparently two solutions to this task, with the first probably being the more straight forward one:
Deploy an additional service edge (active/passive) and then add a service gateway and the gateway firewall to any T1. The corresponding T1 service router will then be deployed on the service edge (you have to pick one in the deployment wizard). Now we might only have to add a prefix filter on the NSX BGP uplink, if we want to hide the private network to the external uplink network.
Configure L2 bridging: Vmware Docs. Create an L2 bridge in any segment and add the gateway firewall to this segment's T1 uplink or add a bridge firewall to the bridge's VDS. Then optionally apply the prefix filter for the bridged LAN on the BGP uplink.
an upcoming update will let you use A/A and firewall (stateful). VMware is working on it. That simply set stateful services to use even with A/A routing setup.
Related
I have a k8s cluster that runs my app (gce as an ingress) and I want to restrict access to some endpoints "/test/*" but all other endpoints should be publically available. I don't want to restrict for specific IP's to have some flexibility and ability to access restricted endpoints from any device like phones.
I considered IAP but it restricts access to the full service when I need it only for some endpoints. Hence extra.
I have thought about VPN. But I don't understand how to set this up, or would it even resolve my issues.
I have heard about proxy but seems to me it can't fulfill my requirements (?)
I can't tell that solution should be super extensible or generic because only a few people will use this feature.
I want the solution to be light, flexible, simple, and fulfill my needs at the same time. So if you say that there are solutions but it's complex I would consider restricting access by the IP, but I worry about how the restricted IP's approach is viable in the real life. In a sense would it be too cumbersome to add the IP of my phone every time I change my location and so on?
You can use API Gateway for that. It approximatively meets your needs, it's not so flexible and simple.
But it's fully managed and can scale with your traffic.
For a more convenient solution, you have to use software proxy (or API Gateway), or go to the Bank and use Apigee
I set up OpenVPN.
It was not a tedious process because of the various small obstacles but I encourage you to do the same.
Get a host (machine, cluster, or whatever) with the static IP
Setup an OpenVPN instance. I do docker https://hub.docker.com/r/kylemanna/openvpn/ (follow instructions but update a host -u YOUR_IP)
Ensure that VPN setup works from your local machine
To the routes you need limit IP access to the VPN one. Nginx example
allow x.x.x.x;
deny all;
Make sure that nginx treats IP right. I had an issue that the nginx was having Load Balancer IP as client IP's, so I have to put some as trusted. http://nginx.org/en/docs/http/ngx_http_realip_module.html
Test the setup
I have a use case:- where my I have a lot of traffic coming to my webservers so I need greater performs and better latency however there are 2 paths to which traffic is incoming.
as per my understanding this is achievable with aws NLB which scales to 1000's request per second and 100 ms sub latency.
however I have www.jatin.com and www.jatin.com/somepath which means It needs path based routing which Is supported by aws ALB.
I need performance as well as path based routing achievable with NLB?
achievable with NLB?
Sadly its not possible. Concepts of url, paths or dns hostnames are only defined for Layer 7 - Application of the OSI model. However, NLB operates at layer 4 - transport. Subsequently, NLB is not able to differentiate between any url domain names or paths.
The only distribution of incoming traffic you can obtained for NLB, is based on port number, as per my knowledge. So you can have one listener for port 80, other listener for port 88, 443 and so on. This will work because ports, just like IP addresses, are part of layer 4.
Only ALB operates at layer 7 and partially CLB, thus it can do path based routing. So you either have to use ALB, or maybe try to look for a third party load balancer which you can deploy on AWS.
When trying to evaluate how to connect to a Cloud SQL database from a Google Kubernetes Engine pod, there are a couple of ways to do this. One is to use a sidecar cloud proxy agent. Another is using a private IP and using a SSL connection between the two. Is there a clear case for either? Or do they both serve the same functionality? Is there one that is considered "best practice"?
Cloud SQL Proxy sidecar
The cloud sql proxy sidecar establishes a TCP connection into a proxy service that is hosted on Google's infrastructure. This then connects you to your cloud SQL instance on the Google network.
Pros
Establishes a secure connection without you having to manage the crypto material in your application
Connects to the instance and you don't have to manage DNS records or IP addresses
Cons
You have to create a secret that stores a service account key.
You have to manage a sidecar instance along side your pod, which if that fails, you no longer can connect to your database
Latency added due to the number of layers you have to the proxy layers
Private IP + SSL
Using a private IP and connecting the instance to your VPC allows you to use an internal IP address, that is not publicly routed, and keeps traffic in your VPC instance. On top of that, setting up SSL only connections to your database to make sure traffic is secure from point to point.
Pros
Low latency connection to the database because its a point to point connection
You manage the keys between the services
No outside dependencies or systems needed to connect between the two
Cons
You have to manage the SSL certificate inside of the connection
You have to verify that the IP and DNS records setup in your cluster are correct
Am I missing something? Do these two indeed provide the same thing? Is there not an absolutely clear winner between the two and you can pick whichever one you see that best fits your style?
Best practice is to use the Proxy. From a secure standpoint they're both good options, but I've found the mess of managing my own SSL keys just a nuisance I didn't need. Also as John mentioned in his comment, if you shift regions, or change IPs for any reason, you have to change the container content rather than just a flag on the proxy startup. You can mitigate that of course using environment variables on the containers, but it's one more thing.
There's a SLIGHT security edge on the proxy IMO as IF your keys get compromised, the window that the ephemeral key generated by the proxy connection is shorter lived than an SSL key generated by yourself (unless you're using the ephermal key calls in the API). So if a vulnerability is found in your app, and a key gets compromised, there's a smaller window that anyone can do malicious things to your DB. But particularly if you're solely on a VPC that's LESS of a concern, but is still greater than zero.
We're living behind a corporate proxy/firewall, that can only consume static IP rules and not FQDNs.
For our project, we need to access Google Speech To Text API: https://speech.googleapis.com. If outside of corporate network, we use gRPC stream over HTTP/2 to do that.
The ideal scenario looks like:
Corporate network -> static IP in GCP -> forwarded gRPC stream to speech.googleapis.com
What we have tried is creating a global static external IP, but failed when configuring the Load Balancer, as it can only connect to VMs and not APIs.
Alternatively, we were thinking to use output of nslookup speech.googleapis.com IP address ranges and update it daily, though it seems pretty 'dirty'.
I'm aware we can configure a compute engine resource / VM and forward the traffic, but this really doesn't seem like an elegant solution either. Preferably, we can achieve that with existing GCP networking components.
Many thanks for any pointers!
Google does not publish a CIDR block for you to use. You will have daily grief trying to whitelist IP addresses. Most of Google's API services are fronted by the Global Frontend (GFE). This uses HTTP Host headers to route traffic and not IP addresses, which will cause routing to fail.
Trying to lookup the IP addresses can be an issue. DNS does not have to return all IP addresses for name resolution in every call. This means that a DNS lookup might return one set of addresses now and a different set an hour from how. This is an edge example of grief you will cause yourself with whitelisting IP addresses.
Solution: Talk to your firewall vendor.
Found a solution thanks to clever networking engineers from Google, posting here for future reference:
You can use a CNAME in your internal DNS to point *.googleapis.com to private.googleapis.com. This record in public DNS points to two public IP addresses (199.36.153.8/30) that are not reachable from the public internet but through a VPN tunnel or Cloud interconnect only.
So if setting up a VPN tunnel to a project in GCP is possible (and it should be quite easy, see https://cloud.google.com/vpn/docs/how-to/creating-static-vpns), then this should solve the problem.
I am preparing a system of EC2 workers on AWS that use Firebase as a queue of tasks they should work on.
My app in node.js that reads the queue and works on tasks is done and working and I would like to properly setup a firewall (EC2 Security Group) that allows my machines to connect only to my Firebase.
Each rule of that Security Group contains:
protocol
port range
and destination (IP address with mask, so it supports whole subnets)
My question is - how can I setup this rule for Firebase? I suppose that IP address of my Firebase is dynamic (it resolves to different IPs from different instances). Is there a list of possible addresses or how would you address this issue? Can some kind of proxy be a solution that would not slow down my Firebase drastically?
Since using node to interact with Firebase is outbound traffic, the default security group should work fine (you don't need to allow any inbound traffic).
If you want to lock it down further for whatever reason, it's a bit tricky. As you noticed, there are a bunch of IP addresses serving Firebase. You could get a list of them all with "dig -t A firebaseio.com" and add all of them to your firebase rules. That would work for today, but there could be new servers added next week and you'd be broken. To try to be a bit more general, you could perhaps allow all of 75.126.., but that is probably overly permissive and could still break if new Firebase servers were added in a different data center or something.
FWIW, I wouldn't worry about it. Blocking inbound traffic is generally much more important than outbound (since to generate outbound traffic you have to have already managed to somehow run software on the box)