Your company runs its Linux workloads on Compute Engine instances. Your company will be working with a new operations partner that does not use Google
Accounts. You need to grant access to the instances to your operations partner so they can maintain the installed tooling. What should you do?
To grant access to the instances without requiring the operations partner to use Google Accounts, the best approach is to use SSH keys. The operations partner can generate SSH key pairs, and then their public keys can be added to the VM instances. This allows secure access without making any assumptions about the partner's use of Google services. This method is straightforward and directly grants the necessary access to maintain the installed tooling on the instances.
A - https://cloud.google.com/iap/docs/external-identities
full of confusions for any reader.... You guys all say A, B, C & D but which one is correct ?
nothing
A is the correct answer, IAP controls access to your App Engine apps and Compute Engine VMs running on Google Cloud. It leverages user identity and the context of a request to determine if a user should be allowed access. IAP is a building block toward BeyondCorp, an enterprise security model that enables employees to work from untrusted networks without using a VPN. By default, IAP uses Google identities and IAM. By leveraging Identity Platform instead, you can authenticate users with a wide range of external identity providers, such as: Email/password OAuth (Google, Facebook, Twitter, GitHub, Microsoft, etc.) SAML OIDC Phone number Custom Anonymous This is useful if your application is already using an external authentication system, and migrating your users to Google accounts is impractical.
IAP controls access to your App Engine apps and Compute Engine VMs running on Google Cloud. It leverages user identity and the context of a request to determine if a user should be allowed access. IAP is a building block toward BeyondCorp, an enterprise security model that enables employees to work from untrusted networks without using a VPN. By default, IAP uses Google identities and IAM. By leveraging Identity Platform instead, you can authenticate users with a wide range of external identity providers, such as: Email/password OAuth (Google, Facebook, Twitter, GitHub, Microsoft, etc.) SAML OIDC Phone number Custom Anonymous This is useful if your application is already using an external authentication system, and migrating your users to Google accounts is impractical.
The answer is A: Enable Cloud IAP for the Compute Engine instances, and add the operations partner as a Cloud IAP Tunnel User as per [1] and [2]. [1]:https://cloud.google.com/iap/docs/tcp-forwarding-overview#:~:text=To%20learn%20how%20to%20grant%20principals%20access%20to%20tunneled%20resources%20and%20how%20to%20create%20tunnels%20that%20route%20TCP%20traffic%2C%20see%20Using%20IAP%20for%20TCP%20forwarding. [2]: https://cloud.google.com/iap/docs/tcp-forwarding-overview#:~:text=IAP%27s%20TCP%20forwarding%20feature%20lets%20you%20control%20who%20can%20access%20administrative%20services%20like%20SSH%20and%20RDP%20on%20your%20backends%20from%20the%20public%20internet.
Please watch this video. https://www.youtube.com/watch?v=jZdXyWQuIW0
A - To control which users and groups are allowed to use IAP TCP forwarding and which VM instances they're allowed to connect to, configure Identity and Access Management (IAM) permissions. How to: Open the IAP admin page and select the SSH and TCP Resources tab. Open the IAP admin page Select the VM instances that you want to configure. Click Show info panel if the info panel is not visible. Click Add member and configure the following: New members: Specify the user or group you want to grant access. Select a role Select Cloud IAP > IAP-Secured Tunnel User. https://cloud.google.com/iap/docs/using-tcp-forwarding#grant-permission
A is right. IAP will allow you to connect compute engine without GCP account .
B is the straight forward answer to allow the partner to access via SSH without a Google account. For those suggesting A, carefully read https://cloud.google.com/iap/docs/external-identities and you'll notice that external identity isn't available from IAP out of the box and requires Identity Platform.
A is clean: https://cloud.google.com/iap/docs/concepts-overview#when_to_use_iap
Very consfusing quesiton, whats final answer?
Question ask about granting access to new operations partner and that can be done by first option only.
https://cloud.google.com/iap/docs/concepts-overview IAP is only for google accounts and applies to access to AppEngine, HTTP(s) LB. It explicitly doesn't protect VMs.
please ignore..Answer should be A..https://cloud.google.com/iap/docs/external-identities..this page shows it works for VMs and non-google accounts.
Ignore you, A is not possible, because the question does not say since now the partner will use google accounts....
ok, if it is C, then the partner is in the same internal network, How can they enter the linux vms? they need ssh access....
Answer is A. Although to enable IAP, you do need to create a firewall rule on tcp 22. But if this question wasn't multiple choice then A is correct. "IAP is a building block toward BeyondCorp, an enterprise security model that enables employees to work from untrusted networks without using a VPN." - So C is not required when A can suffice.
A seems more corrrect, as to provide the access
"new operations partner that does not use Google Accounts." All answering A, but the question does not say that the new partner is going to use Google Accounts now. So it is D. Is not a good idea to enter with ssh key pairs, but there is not other option if the new partner has to enter vms and does not have Google accounts.
If you go with answer A, explain please what credentials will be used to authentication?