I am learning cloud computing but i am still confused in some basics. While it is accessible from the internet, what exactly makes a Virtual Private Cloud (VPC) private? Is it the VPN connection, the solution architecture, or the virtual network?
Is it necessary for it to be an on-prem solution boosted with some cloud services to be considered a VPC?
What's the difference between an application that allows some clients to access it over the internet using cURL or a browser's HTTP/HTTPS protocol in a public cloud and an application in a private cloud?
Suppose a web application is hosted in a public cloud, but it uses a private network to establish network connections between some services, such as invoking some analytical jobs. Is that part considered a private cloud?
If so, what if a third party wants to use the analytics results of my application? Is it still considered a private cloud?
I have a basic understanding of the cloud and have done some labs with scaling options, private network firewalls, and load balancers. However, the distinction between private and public clouds remains unclear to me. Could you please clarify?
Public Cloud is a cloud computing service that is offered to everyone who wants to avail their services over the internet. While the Private Cloud is a service that is completely controlled by a single organization and not shared with others. You can check this link for more information about public and private cloud.
You can still create a public network or private network under either Public cloud or Private cloud. For example you choose to use a public cloud which is GCP (Google Cloud Platform) . You have an option if you want your resources to be publicly accessed through the internet.
One way is the one that you mentioned and that is VPN but it is not the only way to access it. There are other options that will depend on what type of access that you need. One example is a compute engine, once compute engine is created, by default there will be an external IP address that will be assigned in your compute engine. In this way you can open a port and allow traffic access by using a firewall.
If you want your network to be private, same example from compute engine there is an option wherein you can disable assigning an external IP address in your compute engine or by the use of firewall you can close all access from outside your network (public) to remain private. For a brief explanation you can check up on this link since your tagging is google cloud platform, please be informed that the shared link is not under google cloud platform documentation. The reason why I share this link with you is to explain the concept of public and private network.
A Virtual Private Cloud (VPC) is considered private because it provides a secure, isolated network environment within a public cloud infrastructure. The main factors that make a VPC private include:
Network Isolation:
A VPC is isolated from the public internet, and can only be accessed by authorized users via a VPN connection, a secure connection to a private network, or through a Virtual Private Network (VPN) gateway.
Access Control:
Access to resources within a VPC is tightly controlled through firewall rules, security groups, and network access control lists (ACLs). This allows administrators to restrict access to the VPC and its resources based on specific security requirements.
Encryption:
Data transmitted within a VPC can be encrypted using industry-standard encryption protocols, making it more secure and less susceptible to unauthorized access.
Dedicated Resources:
A VPC provides dedicated resources, such as compute, storage, and network, which are isolated from other customers' resources and less susceptible to interference from other workloads.
To summarize, the combination of network isolation, access control, encryption, and dedicated resources makes a VPC private and make it secure.
Related
I have a GCP Workflows accessing an API served on a GCP Compute Instance using the public IP and it is working fine.
Now I want to use the same Workflows but accessing by private IP and I get a ConnectionError.
Is there any limitation of the GCP Workflows to access by private IP to the GCP Compute Instance?
Workflows are not part of your VPC, therefore no access is possible to private IP addresses. Workflows do not yet support VPC access connectors, which would allow for VPC access.
On connecting my on-prem network with GCP VPC using GCP VPN. From the on-prem network can i access the resources in GCP VPC using the internal ip address of resources.
If the answer is yes, does this apply to all VPN's in general.
I have searched this page for "internal" but found no clue - Cloud VPN overview
Yes, it's the principle of a VPN: bridge 2 networks, through the public internet, but with encrypted communication to keep the traffic secret.
Of course, there are limits and constraints: IP range overlap, routing, network announcement (BGE protocol if supported), firewalls,...
Yes you can access the GCP resources with internal IP addresses from on-premises network.
There are 4 types of private access options. These private access options can be used to allow VM instances with internal IP addresses to communicate with certain API’s and services. To choose an option that supports the APIs and services that you need to access refer to the documentation private-access-options. You can configure one or all of these options. They operate independently of each other.
4 types of private access options are:
Private google access
Private google access for on-prem hosts
Private service access
Serverless VPC access
Private google access for on-prem hosts:
Private google access for on-prem hosts used with on-prem hosts. Private Google Access for on-premises hosts is an alternative to connecting to Google APIs and services over the internet by routing traffic through a Cloud VPN tunnel or a Cloud Interconnect attachment (VLAN). Such on-prem hosts may or may not be configured with external IP addresses.You can use this option when you want to connect to Google API’s and services through VPC network. When using private google access for on-prem hosts your on-prem hosts do not need to have external IP addresses assigned to them.
For more information refer to the documentation private google access for on-premises hosts.
AWS recommends using private subnets for private resources.
Use private subnets for your instances if they should not be accessed directly from the internet. Use a bastion host or NAT gateway for internet access from an instance in a private subnet.
However, I want to understand the rationale on how is this better on putting the resource, lets say an EC2 instance on a public subnet. Then add some very strict security group to prevent public access. How is this the less secure approach? Or is it technically the same outcome security wise?
I've never heard of a security group failing, so if you properly configure your security group with a restricted list of IP addresses/ports, you should be secure.
BUT
In a typical cloud-deployed application, you do not have or want strictly-controlled access. Instead, the typical cloud-deployed application is a web-app that exposes port 80 to the world.
And once you expose any port to the world, your security is entirely dependent on what is listening to that port. Do you have a vulnerability in your web-server? You've now given your attacker the ability to access resources inside your network. If your server has AWS access keys, then the attacker has them as well.
The goal of putting your servers in a private subnet, with a load balancer in front of them, is to reduce your attack surface. It's presumably less likely that attackers will be able to find an exploit in an ALB (versus Apache, nginx, or whatever you're using), and presumably more likely that AWS will be able to mitigate any such exploit faster than you can (because they don't need to wait for patches to become available from an external maintainer).
Of course, the code you wrote could have an exploit that's triggered from a standard HTTP(S) request. However, even in this case, you can reduce blast radius by controlling what your application can access. An instance with a public IP can access anything on the Internet unless you strictly control the egress rules in its security group. In a private subnet, it can only access stuff within the VPC.
So, ultimately, it's a matter of simplicity: yes, you can craft a secure environment where every host is on the Internet. That was, in fact, the way that AWS worked prior to the introduction of VPCs. But it's easier to rely on the VPC to provide a base level of security (just like, in non-cloud deployments, you rely on the corporate firewall to provide a base level of security).
I want a Cloud Function on GCP to connect to a Google API (eg, compute.googleapis.com) privately. That is, not over the internet. I also want this Cloud Function to egress all traffic into a VPC through a Serverless VPC Accessor.
For VMs to connect privately to Google APIs, one enables Private Google Access for the subnet that the VM lives on. But, for Functions, the "serverless connector" is not a subnet per se, and so one can't enable Private Google Access for this connector. With Private Google Access, the call to a Google API originating from a Function eventually heads out the default internet gateway to the public internet.
How can I get my Function to make calls to Google APIs privately after egressing onto my VPC?
When you are in the Google network, you never go to the internet for reaching a Google service. In the worst case, because it's not in the same region, you go into the Google global fiber network.
If you are in the same region, you stay inside it.
Thus, your call are private by default. You don't have Google Cloud Functions to enforce this, it's by default.
But, if you prefer to be sure, you can use the private DNS of Google by adding private like this: compute.private.googleapis.com
What i understand from Cloud is , it is something to share computing resources (RAM,CPU,Network etc) among several virtual instances on that cloud infrastructure. read here
But in case of AWS VPC , it have nothing to do with RAM,CPU etc, It is just something Like VPN, where we create our private network.
So why it is named as Virtual Private Cloud?
Its mostly a networking and security model. Classic, which existed before VPC, had very limited control of network and security. VPC allows you control of subnets, network interfaces, inbound and outbound security rules.