OsLogin API to verify authorized users about compute-image-tools

[illfelder]

The OS Login API isn't appropriate for that check. In your script that runs inside a VM, you can poll against the metadata server's authorize endpoint.

EMAIL=<service account Login Profile name or email>
curl "http://metadata.google.internal/computeMetadata/v1/oslogin/authorize?email=${EMAIL}&policy=login" -H "Metadata-Flavor: Google"
curl "http://metadata.google.internal/computeMetadata/v1/oslogin/authorize?email=${EMAIL}&policy=adminLogin" -H "Metadata-Flavor: Google"

[helen-fornazier]

Great, thanks

[helen-fornazier]

Hi, sorry about reopening this. I found the issue regarding tests on u16, tests fails because ssh-guard blocks the connection from the testers after some attempts, so polling metadata before trying ssh is the best alternative.

I would like to ask if I can retrieve this same information but using https://www.googleapis.com/ instead of http://metadata.google.internal/ to allow me to poll this information from a tester machine without the need to add logic on the testee.
I was using:
https://www.googleapis.com/compute/v1/projects/myproject/zones/us-central1-a/instances/example-instance
But is seems this doesn't show the oslogin/authorize information
Otherwise I can use a python script in the testee

[illfelder]

The authorize endpoint is only available from inside the VM. You won't be able to do the polling check from outside of the instance. You can determine whether OS Login is (theoretically) enabled from outside of the instance by checking instance and project level metadata.

[helen-fornazier]

If you mean checking enable-oslogin in instance and project level metadata, then this doesn't work for me because is the test script who sets or unsets enable-oslogin and tests if ssh gained or lost access accordingly, so I already know the state of enable-oslogin in the metadata.

I solved it in another way by disabling sshguard at boot using service sshguard stop and I ignore if this command fails (in case the service doesn't exist), but this won't work in case the distro doesn't have the service command, but most of distros do provide the service command and those who doesn't provide it probably don't use sshguard.