connecting to VM instance having no external IP - google-cloud-platform

I am trying to connect to a google cloud VM instance having no external IP address via cloud shell and cloud SDK.
Google document says that we can connect it using IAP
Connecting through IAP: refer using IAP
a) Grant the roles/iap.tunnelResourceAccessor role to the user that wants to connect to the VM.
b) Connect to the VM using below command
gcloud compute ssh instance-name --zone zone
OR
Using IAP for TCP forwarding: refer using TCP forwarding
we can also connect by setting a ingress firewall rule for IP '35.235.240.0/20' with port TCP:22
and select a IAM role Select Cloud IAP > IAP-Secured Tunnel User
what's the difference between these two different approach and what's the difference in these two separate IAM roles
roles/iap.tunnelResourceAccessor
IAP-secured Tunnel User
I am new to cloud so please bear with my basic knowledge.

It's exactly the same thing. Look at this page
IAP-Secured Tunnel User (roles/iap.tunnelResourceAccessor)
You have the display name of the role: IAP-Secured Tunnel User that you see in the GUI, and you have the technical name of the role roles/iap.tunnelResourceAccessor that you have to use in the script and CLI

The link mentioned in the question ("refer using IAP") actually points to the
Connecting to instances that do not have external IP addresses > Connecting through a bastion host.
Connection through a bastion host is another method apart from access via IAP.
As described in the document Connecting to instances that do not have external IP addresses > Connecting through IAP,
IAP's TCP forwarding feature wraps an SSH connection inside HTTPS.
IAP's TCP forwarding feature then sends it to the remote instance.
Therefore both parts of the question (before OR and after OR) belong to the same access method: Connect using Identity-Aware Proxy for TCP forwarding. Hence the answer to the first question is "no difference" because all of that describes how the IAP TCP forwarding works and those are the steps to set it up and use:
1. Create a firewall rule that:
applies to all VM instances that you want to be accessible by using IAP;
allows ingress traffic from the IP range 35.235.240.0/20 (this range contains all IP addresses that IAP uses for TCP forwarding);
allows connections to all ports that you want to be accessible by using IAP TCP forwarding, for example, port 22 for SSH.
2. Grant permissions to use IAP:
Use GCP Console or gcloud to add a role IAP-Secured Tunnel User (roles/iap.tunnelResourceAccessor) to users.
Note: Users with Owner access to a project always have permission to use IAP for TCP forwarding.
3. Connect to the target VM with one of the following tools:
GCP Console: use the SSH button in the Cloud Console;
gcloud compute ssh INSTANCE_NAME
There's an important explanation of how IAP TCP forwarding is invoked for accessing a VM instance without Public IP. See Identity-Aware Proxy > Doc > Using IAP for TCP forwarding:
NOTE. If the instance doesn't have a Public IP address, the connection automatically uses IAP TCP tunneling. If the instance does have a public IP address, the connection uses the public IP address instead of IAP TCP tunneling.
You can use the --tunnel-through-iap flag so that gcloud compute ssh always uses IAP TCP tunneling.
As already noted by guillaume blaquiere, roles/iap.tunnelResourceAccessor and IAP-secured Tunnel User are not the different IAM roles, but the Role Name and the Role Title of the same Role. There is one more resource that represents this in a convenient form:
Cloud IAM > Doc > Understanding roles > Predefined roles > Cloud IAP roles

Related

AWS: can't connect to Amazon Linux EC2 instance

I'm working with AWS, I have an EC2 instance (Amazon Linux) but I can't connect to it, I've checked all VPC parameters and they are enabled as well as the instance, but when I try to connect it using EC2 Instance Connect I get this message:
I'm using the default user account, also I generated a key pair however I'm getting this other message:
Also, session manager can't connect.
So my question is: what settings do I need to update or check in order to connect to my EC2 instance?
Thanks a lot for your comments.
There are multiple ways to login to an Amazon EC2 instance.
SSH
Your screenshot shows that you are wanting to login via SSH, but it is saying that no Keypair was selected when the instance was launched. Therefore, this option is not available for you.
EC2 Instance Connect
If you ware wanting to login to the Amazon EC2 instance using EC2 Instance Connect and you are experiencing connectivity problems, then make sure that your Security Group permits Inbound access on port 22 from the IP address range of the EC2 Instance Connect service (not your own IP address).
This is because the EC2 Instance Connect client on your computer connects to AWS on port 443 (as a web connection), and then the traffic goes from the EC2 Instance Connect service to the EC2 instance as a normal SSH connection on port 22. Therefore, the Security Group needs to permit Inbound connections on port 22 from the IP address range of the EC2 Instance Connect service (or you can be lazy and just select 0.0.0.0/0, but that is a lower level of security).
You can find the IP address ranges for AWS services at: AWS IP address ranges - AWS General Reference
Please note that your EC2 instance must be in a public subnet and you must connect via a public IP address.
AWS Systems Manager Session Manager
The Session Manager connects in a totally different way, without using SSH. It requires an Agent to be installed on the EC2 instance (and it is there by default if you launched from an Amazon Linux AMI). This Agent then creates an Outbound connection to AWS, so it does not require any Inbound security rules (but it does require the default "Allow All" Outbound rule).
Session Manager has the additional benefit that it allows you to connect to EC2 instances that are in private subnets, as long as the EC2 instance can access the Internet via a NAT Gateway or if the VPC has a VPC endpoint for Systems Manager.

vm instance failed to connect to backend with ssh

I created a VM instance in Google cloud and configured it properly with all the necessary software. then, I cloned its disk and created a new VM instance, utilizing the cloned disk; however, when I tried to connect ot the new instance via the SSH button, it does not succeed with a code 4003. Reason: failed to connect with backend. Connection via Cloud Identity-Aware Proxy Failed.
When an instance does not have a public IP address, SSH in a Browser needs to forward the SSH connection through IAP. The error "failed to connect to backend" indicates that the IAP proxy service was unable to open a TCP connection to the instance.
Ensure you have a firewall rule to allow Cloud Identity-Aware Proxy (IAP) to connect to port 22 on the instance.
Create a firewall rule
To allow IAP to connect to your VM instances, create a firewall rule that:
applies to all VM instances that you want to be accessible by using IAP. \
allows ingress traffic from the IP range 35.235.240.0/20. This range contains all IP addresses that IAP uses for TCP forwarding. \
allows connections to all ports that you want to be accessible by using IAP TCP forwarding, for example, port 22 for SSH and port 3389 for RDP.
To allow RDP and SSH access to all VM instances in your network, do the following:
Open the Firewall Rules page and click Create firewall rule
Configure the following settings:
Name: allow-ingress-from-iap
Direction of traffic: Ingress
Target: All instances in the network
Source filter: IP ranges
Source IP ranges: 35.235.240.0/20
Protocols and ports: Select TCP and enter 22,3389 to allow both RDP and SSH.
Click Create.
In Case you haven't enable your IAP you may refer on this link Enabling IAP for Compute Engine. You may check/browse also other related IAP guides on the left hand pane.

When I use SSH with web browser on AWS Console. How I can set my security group source?

Recently new SSH access method comes up on AWS Console.
Just I select my instance and click connect button and SSH web console shows up!
But if I wanna using that I have to set security group source from all.
When I set that just from my IP. SSH web console doesn't work.
I don't want to set that from all.
How can I set that just from aws network or my ip?
I think you mean SSH connection (not SSL; I edited your question to change that) through EC2 Instance Connect. This would explain why it does not work when you use your IP.
To limit SSH traffic when using EC2 Instance Connect you have to use AWS API ranges for the service:
(Browser-based client) We recommend that your instance allows inbound SSH traffic from the recommended IP block published for the service. Use the EC2_INSTANCE_CONNECT filter for the service parameter to get the IP address ranges in the EC2 Instance Connect subset.
Thus, you have to allow IP ranges used by the service, not your home/work address.

Connection to Compute Engine with No External IP Possible?

I am not sure if is a strange behavior of Google Compute Engine. I have a VM without External IP.
Now, where I click the ssh button I can still connect to it and I see the log:
External IP address was not found; defaulting to using IAP tunneling.
I have not configured any IAP though. So how can that be possible? Is then IAP tunnelling always on?
Identity Aware Proxy is a managed Google Cloud service. This service is always running. Access is controlled through IAM roles. The CLI is connecting to an IAP endpoint, requesting the creation of a TCP tunnel and then forwarding traffic to your instance via this tunnel.
If you don't set an external IP address to your VM Instance as you can see on this documentation, you will have to set any of this 3 methods to connect to your Instance: 1.- Creating a VPN, 2.- Using a Bastion Host, 3.- Using Identity and Aware Proxy
The must common is to use IAP or VPN, Bastion host method is more complicated and expensive.

GCP open firewall only to cloud shell

Is there a way in GCP to explicitly allow firewall rule only from cloud shell. All the GCP demos and videos add the rule allow 22 to 0.0.0.0/0 to ssh to the instance from cloud shell.
However is there a way we could restrict the access only from cloud shell - either using cloud shell's IP range or service account ?
Google does not publish the public IP address range for Cloud Shell.
VPC firewall rules allow specifying the service account of the source and target. However, Cloud Shell does not use a service account. Cloud Shell uses the identity of the person logged into the Google Cloud Console. This means OAuth 2 User Credentials. User Credentials are not supported for VPC Firewall rules.
My recommendation is to use TCP forwarding and tunnel SSH through IAP (Identity Aware Proxy). Google makes this easy in the Cloud SDK CLI.
Open a Cloud Shell in the Google Cloud Console. Then run this command:
gcloud compute ssh NAME_OF_VM_INSTANCE --tunnel-through-iap
This also works for VM instances that do not have public IP addresses.
The Identity Aware Proxy CIDR netblock is 35.235.240.0/20. Create a VPC Firewall rule that allows SSH traffic from this block. This rule will prevent public SSH traffic and only allow authorized traffic thru Identity Aware Proxy.
Google has published the detailed info in this article - Configuring secure remote access for Compute Engine VMs
From the admin console, click Security then select Identity-Aware Proxy.
If you haven’t used Cloud IAP before, you’ll need to configure the oAuth screen:
Configure the consent screen to only allow internal users in your domain, and click Save.
Next, you need to define users who are allowed to use Cloud IAP to connect remotely. Add a user to the “IAP-secured Tunnel User” role on the resource you’d like to connect to.
Then, connect to the machine via the ssh button in the web UI or gcloud.
When using the web UI, notice the URL parameter useAdminProxy=true.
Tip: If you don’t have gcloud installed locally, you can also use Cloud Shell:
gcloud beta compute ssh {VM-NAME} --tunnel-through-iap
You should now be connected! You can verify that you don’t have internet connectivity by attempting to ping out. 8.8.8.8 (Google’s Honest DNS) is a good address to try this with.