Google Cloud Platform Security Checklist : Part 4/7 — Compute Engine
Welcome to the fourth article of our series on Google Cloud Platform (GCP) security best practices. So far, we’ve delved into crucial aspects of Identity and Access Management (IAM), the Key Management System (KMS), and Network Security. Each of these components plays an integral role in creating a robust and secure GCP environment. Today, we will be turning our focus towards Compute Engine, another vital piece in the vast puzzle of GCP security. But as always lets start with the fundamentals.
Definition
Google Compute Engine (GCE) serves as a key constituent of Google Cloud Platform (GCP), providing Infrastructure as a Service (IaaS). Essentially, it facilitates users in operating virtual machines (VMs) within the framework of Google’s expansive infrastructure.
Best Practices Checklist
1. Block Project-wide SSH Keys
Avoid using SSH keys that provide access to all instances within a Google Cloud project. Using instance-specific SSH keys helps reduce the potential attack surface. In the case that one key is compromised, it doesn’t jeopardize the entire project, only the specific instance associated with that key.
2. Use Identity-Aware Proxy (IAP) and OS Login
Leveraging Identity-Aware Proxy (IAP) and OS Login when accessing to the Vms ensures a secure and centrally managed authentication mechanism for accessing these critical servers. IAP provides context-aware access control, while OS Login allows you to manage SSH access to your instances using IAM roles.
Prevention: There isn’t a direct organization policy for enforcing IAP, but the “Require OS Login (constraints/compute.requireOsLogin)” policy can help enforce the use of OS Login.
3. Avoid Using Default Service Account
Every Google Cloud project comes with a default service account that has broad access to Cloud APIs. It’s best practice to avoid using this service account for instances, and instead create and use specific service accounts with the least privileges necessary for the operation of the instance. This follows the principle of least privilege, reducing the potential impact if a service account gets compromised.
Prevention: This is in line with the “Disable Automatic IAM Grants for Default Service Accounts (constraints/iam.automaticIamGrantsForDefaultServiceAccounts)” organisation policy.
4. Disable IP Forwarding
IP forwarding allows an instance to send and receive network packets pretending to be a different IP. This can be a security risk if misused. Unless necessary for your application, it’s recommended to disable IP forwarding on your instances.
Prevention: This can be enforced using the “Restrict VM IP Forwarding (constraints/compute.vmCanIpForward)” policy.
5. Avoid Public IP Addresses
Public IP addresses can expose your instances to the internet, making them potentially vulnerable to attacks. If possible, use private IPs within a Virtual Private Cloud (VPC) for communication between instances and services.
Prevention: This can be enforced using the “Disable using external IP addresses (constraints/compute.vmExternalIpAccess)” policy.
6. Regularly Update and Patch VM Instances
Keeping your VM instances updated and patched is crucial for security. Regular updates help protect your instances from known vulnerabilities that could be exploited by attackers.
7. Use Trusted and Secured/Hardened OS Images
It’s best practice to only use OS images that have been vetted and secured. This might include images that have passed security vulnerability tests, or images from projects that contain golden images, which are base images that have been configured with specific settings or software by security teams. If you need to use custom OS images, make sure they are hardened. Hardening is the process of securing a system by reducing its surface of vulnerability. This might involve disabling unnecessary services, limiting access, and setting up monitoring.
Prevention: The “Restrict the list of sources for VM images (constraints/compute.trustedImageProjects)” policy can be used here.
8. Regularly Deprecate Older OS Versions
Enforce lifecycle policies on images to ensure that outdated images with vulnerabilities cannot be used. As new security vulnerabilities are discovered and software updates are released, these older images can quickly become outdated and potentially insecure. They might contain versions of software with known vulnerabilities, outdated configuration settings, or even deprecated software that is no longer supported by the vendor.
Prevention: The “Restrict the list of sources for VM images (constraints/compute.trustedImageProjects)” policy can be used here.
9. Avoid Storing Sensitive Data in VM Custom Metadata
Any user or application within the instance can read the metadata values for that specific instance. Storing sensitive data in Compute Engine metadata can pose a security risk if the instance or any user with read access to the instance is compromised.
Prevention: Cant not totally prevent this but you can use the “Disable Guest Attributes of Compute Engine metadata (constraints/compute.disableGuestAttributesAccess)” policy to limit access to guest attributes like projet, folder...
Conclusion
In conclusion, the security of Google Cloud Platform’s Compute Engine relies heavily on the correct implementation of security best practices and organization policies. From blocking project-wide SSH keys, using IAP and OS Login, avoiding default service accounts, and disabling IP forwarding, to keeping VM instances regularly updated, using hardened OS images, and avoiding sensitive data storage in custom metadata, each practice contributes to a more robust security posture.
However, these best practices and policies are not a one-and-done solution. They require regular review, updates, and audits to ensure their effectiveness and to adapt to the evolving cybersecurity landscape. By doing so, organizations can better protect their resources and data, ensuring a safer and more secure operation in the cloud.
Originally published at https://hassene.belgacem.io .
