About
SSH keys can be stored project-wide in the project metadata. In that case, any user who has their SSH key in the project metadata can SSH into instances that don't explicitely block it.
Understanding Impact
Business Impact
instances that do not block project-wide SSH keys are potentially vulnerable to unauthorized access, especially from users who have left the organization.
Technical Impact
When an instance does not block project-wide SSH keys, any user who has their SSH key in the project metadata can SSH into the instance. This makes managing, auditing and revoking access challenging and error-prone since SSH keys are long-lived and not tied to a specific user.
For instance, disabling a user account in GCP does not prevent the user from accessing the instance if their SSH key is in the project metadata.
Identify affected resources
You can use the following gcloud CLI command to list instances that do not block project-wide SSH keys:
gcloud compute instances list --filter="-metadata.block-project-ssh-keys:true" --format="table(name, zone)"
Remediate vulnerable resources
Disable project-wide SSH keys for the instance by setting the block-project-ssh-keys metadata key to true:
gcloud compute instances add-metadata VIRTUAL_MACHINE --metadata "block-project-ssh-keys=true"
Alternatively, you can turn on OS Login on the instance, which disables metadata-based SSH keys. For a more systematic approach, you can enforce OS Login at the organization level using an organization policy.
How Datadog can help
Cloud Security Management
Datadog Cloud Security Management detects this vulnerability using the out-of-the-box rule "Datadog CSM Misconfigurations Rule | Instances should use instance-specific SSH keys instead of project-wide keys".
References
Metadata-managed SSH connections
gcp documentation
Add or remove project-wide public SSH keys
gcp documentation
Enable OS Login for an organization using an organization policy
gcp documentation
Set up OS Login
gcp documentation