You are developing a web application that will be accessible over both HTTP and HTTPS and will run on Compute Engine instances. On occasion, you will need to SSH from your remote laptop into one of the Compute Engine instances to conduct maintenance on the app. How should you configure the instances while following Google-recommended best practices?
Configuring the Compute Engine instances behind an HTTP(S) load balancer ensures that the web server instances are not directly exposed to the internet, improving security. This also aligns with Google's best practices for security and scalability. For SSH access, using a bastion host with a public IP address provides a secure entry point, which is often termed a 'jump box'. The bastion host is the only instance exposed to SSH traffic, and firewall rules can be tightly controlled to only allow SSH access from authorized IP addresses to the bastion host, thereby further reducing the attack surface.
I vote C
D. is a recommended way to configure the instances while following Google-recommended best practices. This approach provides several benefits: The web server instances are only accessible through the load balancer and not directly via their private IP addresses, which improves security. The bastion host acts as a secure jump box that allows you to SSH into the web server instances, while only allowing incoming SSH connections on a specific IP address (the bastion host's public IP). The firewall rules on the web server instances can be configured to only allow connections from the bastion host's IP, further reducing the attack surface. It is a more recommended to have a bastion host that is authorized by your organization to connect to private instances this way it can provide a better security to your instances. And also in terms of compliance, it will also follow the best practices of your organization.
C is a valid approach, but it may not be the best option for all use cases. Cloud IAP allows you to control access to resources in your project by using identity and access management (IAM) roles, which is a good way to secure SSH access. However, this option does not address the issue of securing incoming web traffic, which is a separate concern. Configuring the servers with private IP addresses behind an HTTP(s) load balancer would help with securing the web traffic, but it does not provide an additional layer of security for SSH access. Additionally, it does not have the concept of secure jump host, which is a security best practice in protecting your instances from unwanted incoming connections.
https://cloud.google.com/solutions/connecting-securely#storing_host_keys_by_enabling_guest_attributes Answer C
C is correct
C is my answer, guys
D should be the answer (https://cloud.google.com/solutions/connecting-securely#external) But the bastion host should also be protected by IAP
Ans is D
https://cloud.google.com/solutions/connecting-securely#external
Option D: The Best Practice Security: Using a bastion host with a public IP address provides a secure jump point. Your web servers remain behind a firewall with private IP addresses, making them less vulnerable to direct attacks. Scalability: Bastion hosts can be easily scaled and managed, allowing you to control access to your web server instances. SSH Access: You can securely SSH into the bastion host and then tunnel to your web server instances.
Option A: TCP Proxy Load Balancer Not Ideal for Web Applications: TCP load balancers are better suited for applications that use TCP protocols, not HTTP/HTTPS. SSH Access: While you could potentially use a TCP load balancer for SSH, it's not the recommended approach. Option B: Open Firewall Rules Major Security Risk: Exposing your web servers directly to the internet with public IP addresses is a significant security vulnerability. Option C: Cloud Identity-Aware Proxy (IAP) for SSH Not Designed for SSH: IAP is primarily designed for secure access to web applications, not for SSH. While you could potentially use IAP for SSH, it's not a standard or recommended practice.
VM can only connect through IAM with public IP so C wouldn't work bastion host is one of options instead - https://cloud.google.com/compute/docs/connect/ssh-internal-ip
"This document describes how to connect to a virtual machine (VM) instance through its internal IP address, using Identity-Aware Proxy (IAP) TCP forwarding." https://cloud.google.com/compute/docs/connect/ssh-using-iap
C is correct
i go for C https://cloud.google.com/compute/docs/connect/ssh-using-iap IAP TCP forwarding enables you to establish an encrypted tunnel over which you can forward SSH connections to VMs. When you connect to a VM that uses IAP, IAP wraps the SSH connection inside HTTPS before forwarding the connection to the VM. Then, IAP checks if the you have the required IAM permissions and if you do, grants access to the VM. If you need to connect to a VM that doesn't have external IP addresses and you can't use IAP, review the other methods listed in Connection options for internal-only VMs.
D is wrong. Bastion host VMs You have a specific use case, like session recording, and you can't use IAP
i would choose C: https://medium.com/@larry_nguyen/use-identity-aware-proxy-iap-instead-of-bastion-host-to-connect-to-private-virtual-machines-in-9885bc7c12dd
C is the answer. https://cloud.google.com/iap
I feel both C and D are correct for this scenario. The only reason I would go with option C is that it would be easier to set up than setting up a bastion host.
With TCP forwarding, IAP can protect SSH and RDP access to your VMs hosted on Google Cloud. Your VM instances don't even need public IP addresses. https://cloud.google.com/iap
C should be correct (https://cloud.google.com/iap/docs/using-tcp-forwarding#tunneling_ssh_connections)