OSConfigAgent Error main.go:88: context deadline exceeded

[gnezdo]

I set up a GCP project and the VMs in it use OS policies for configuration management. This works great with the default service account that's created with my GCE project. Now I want to have a distinct service account and use it for the VMs that have a dedicated function. I created a new service account and made it a "Viewer" of the project during the second step of SA creation. The VMs can still be created with this service account assigned via `--service-account` flag. Unfortunately, the VMs can't be configured via project policies. I see these entries in /var/log/messages instead:

Mar 29 22:25:33 snps2 OSConfigAgent[1016]: 2024-03-29T22:25:33.0585Z OSConfigAgent Error main.go:88: context deadline exceeded
Mar 29 22:31:33 snps2 OSConfigAgent[1016]: 2024-03-29T22:31:33.0614Z OSConfigAgent Error main.go:88: context deadline exceeded

So clearly, some roles are missing for this account, but I can't figure out what they are. Where's the list of roles documented?

[lawrencenelson · Accepted solution]

Hi @gnezdo,

Welcome to the Google Cloud Community!

Does the impacted VM have an external IP?

Thank you.

[gnezdo]

I feel bad now. I was confused about the configuration of two similar VMs. One of which does have an external IP. I just realized that the other one that I was trying to set up did not have access to the internet. Now that I enabled external network access, the os config policy is working. I guess my question becomes what's the minimal level of external network connectivity is required for osconfig to work, but that's a separate issue.

[gnezdo]

The answer to my "minimal network access" questions is likely:

If your VM is running within a private VPC network and does not have public internet access, check that you have enabled Private Google Access.

According to the docs.

[lawrencenelson]

Glad it worked! 🙂

[gnezdo]

Yes, it does have an external IP assigned.

[lawrencenelson]

Can you please apply the roles roles/osconfig.osPolicyAssignmentAdmin, roles/osconfig.osPolicyAssignmentEditor, and roles/osconfig.osPolicyAssignmentViewer to the service account [1]. The Admin role has all the permissions of the Editor and Viewer, but you can try applying it all just for the sake of testing purposes.

• OSPolicyAssignment Admin (roles/osconfig.osPolicyAssignmentAdmin). Contains permissions to create, delete, update, get and list OS policy assignments.
• OSPolicyAssignment Editor (roles/osconfig.osPolicyAssignmentEditor). Contains permissions to update, get, and list OS policy assignments.
• OSPolicyAssignment Viewer (roles/osconfig.osPolicyAssignmentViewer). Contains permissions for read-only access to get and list OS policy assignments.

[1]. https://cloud.google.com/compute/docs/os-configuration-management/manage-os-policy

[gnezdo]

These permissions don't seem to be required. The service account only has roles/viewer now and that's enough for osconfig to work (though maybe too much).

[gnezdo]

Thanks @lawrencenelson. I don't think this worked. Despite having the roles listed below I'm still seeing the original error `Error main.go:88: context deadline exceeded` on the newly created VM:

```

$ gcloud projects get-iam-policy PROJECT --format json | grep -B 1 -A 2 "serviceAccount:vendor"
"members": [
"serviceAccount:vendor-vm@PROJECT.iam.gserviceaccount.com"
],
"role": "roles/osconfig.osPolicyAssignmentAdmin"
--
"members": [
"serviceAccount:vendor-vm@PROJECT.iam.gserviceaccount.com"
],
"role": "roles/osconfig.osPolicyAssignmentEditor"
--
"members": [
"serviceAccount:vendor-vm@PROJECT.iam.gserviceaccount.com"
],
"role": "roles/osconfig.osPolicyAssignmentViewer"
--
"members": [
"serviceAccount:vendor-vm@PROJECT.iam.gserviceaccount.com"
],
"role": "roles/viewer"

```

[lawrencenelson]

Hi @gnezdo,

Can you please run through this document and check for a possible misconfiguration in your setup - Verifying VM Manager setup. 

[lawrencenelson]

Another possible cause of this issue is that you have Secure Boot on. You may try turning it off by:

1. Stop the VM
2. Turned off the Secure Boot

3. Start the VM
4. Connect to the VM