Customers report the following observed sudo behavior of VMs when OS Login is enabled is as follows:
If the user logs in with a key registered in OS Login (most typically via gcloud compute ssh) and the user has roles/compute.osAdminLogin, then the AuthorizedKeysCommand / google_authorized_keys binary adds a per-user sudoers file to /var/google-sudoers.d/ and the user is able to run sudo.
If the user subsequently logs in with a key not registered in OS Login, but has been manually added to the user's authorized_keys file, then they may retain sudo access from step 1 for a period of hours, but it is eventually lost and they must repeat Step 1.
If Step 2 is accurate, then this is probably being reset by OS Login cache systemd timer. Perhaps VMs are rebooting without their awareness? I'd like some insight if you have any.
Step 2 is common enough in clusters of VMs with shared filesystems, especially when user /home directories are shared for purposes of large-scale workloads. Could sudo escalation occur by a PAM-based mechanism rather than set by sshd at initial authentication? I see this mentioned in the README:
* **PAM Modules** which provide authorization (and authentication if
two-factor support is enabled) support allowing the system to use Google
Cloud IAM permissions to control the ability to log into an instance or to
perform operations as root (via `sudo`).
but I was not able to find the file pam_oslogin_login.so anywhere within the OS. We have been using recent copies of the guest-oslogin package. If you need a specific version for reproduction purposes, please let me know. I believe the gap in PAM may be a known issue.
Customers report the following observed sudo behavior of VMs when OS Login is enabled is as follows:
gcloud compute ssh) and the user hasroles/compute.osAdminLogin, then the AuthorizedKeysCommand / google_authorized_keys binary adds a per-user sudoers file to /var/google-sudoers.d/ and the user is able to run sudo.If Step 2 is accurate, then this is probably being reset by OS Login cache systemd timer. Perhaps VMs are rebooting without their awareness? I'd like some insight if you have any.
Step 2 is common enough in clusters of VMs with shared filesystems, especially when user
/homedirectories are shared for purposes of large-scale workloads. Could sudo escalation occur by a PAM-based mechanism rather than set by sshd at initial authentication? I see this mentioned in the README:but I was not able to find the file
pam_oslogin_login.soanywhere within the OS. We have been using recent copies of the guest-oslogin package. If you need a specific version for reproduction purposes, please let me know. I believe the gap in PAM may be a known issue.