GCP Recommendations 

1. Enable Automatic Storage Increase(Priority: Moderate)

Baseline:

If Automated Backups are enabled, whenever your resource nears the full capacity, storage limit will be increased (permanently).

Recommendation:

In the Edit Configurations section, check whether the automatic storage increase is enabled under Storage settings.

2. Unlabeled instances (Priority: Low)

Baseline:

Checks if CloudSQL instances have labels applied to them.

Description:

Labels are key-value pairs that help you organize your Google Cloud resources. They can be used for filtering resources in the console, managing billing, and creating resource policies. Unlabeled CloudSQL instances can be difficult to manage, track, and allocate costs in large environments.

Recommendation:

Apply appropriate labels to your CloudSQL instances to improve resource organization, cost tracking, and governance capabilities. Consider implementing a consistent labeling strategy across your Google Cloud resources with labels such as environment, application, department, cost center, or project.

1. Unlabeled compute instances (Priority: Low)

Baseline:

Checks whether the instance labels are empty.

Description:

GCP allows users to assign metadata in the form of labels (key-value pair) to better track and manage instances. Organizations come up with relevant label groupings and practical labeling strategies to manage their VM resource farm efficiently.

Recommendation:

Create a labeling strategy adhering to the GCP best practices.

1. Unlabeled clusters (Priority: Low)

Baseline:

Checks whether the cluster labels are empty.

Description:

As Google Cloud projects grow in complexity, user-defined labels enhance visibility and organization. Strategically labeling GKE clusters streamlines management and simplifies searches and group-related services, like production, staging, and development, for efficient control.

Recommendation:

Create a labeling strategy adhering to Google Cloud best practices.

1. Unlabeled functions (Priority: Low)

Baseline:

Checks whether the functions have user-defined labels.

Description:

Assigning labels to Cloud Run Functions helps in the better management and organization of resources. Labels can be used for cost tracking, resource grouping, and applying policies.

Recommendation:

Create and assign labels to your Cloud Run Functions to improve resource management and organization.

1. Unlabeled services (Priority: Low)

Baseline:

Checks whether the service labels are empty.

Description:

As GCP projects grow in complexity, user-defined labels enhance visibility and organization. Strategically, labeling cloud run services streamlines management, simplifies searches, and groups related services, such as production, staging, and development, for efficient control.

Recommendation:

Create a labeling strategy adhering to GCP best practices.

1. Enable life cycle management (Priority: Moderate)

Baseline:

Checks the disabled life cycle management policies of your GCP storage buckets.

Description:

Life cycle management policies help manage the life cycle of objects in your storage buckets, such as transitioning objects to different storage classes or deleting them after a certain period.

Recommendation:

Implement life cycle management policies to optimize storage costs and manage object life cycles effectively.

1. Unlabeled topics (Priority: Low)

Baseline:

Checks Cloud Pub/Sub topics to identify those without user-defined labels.

Description:

Labels are key-value pairs that help organize and categorize your Pub/Sub resources. Using labels enables better resource management, cost tracking, and filtering capabilities across your Google Cloud environment.

Recommendation:

Apply meaningful labels to your Pub/Sub topics to improve resource organization, simplify management, and enhance cost allocation.

1. Unlabeled zones (Priority: Low)

Baseline:

Checks whether the managed zone labels are empty.

Description:

Labels help organize and categorize Cloud DNS resources, making them easier to filter, track, and manage for cost allocation and operations.

Recommendation:

Apply meaningful labels to your Cloud DNS managed zones following Google Cloud best practices for resource organization and management.

1. Firewall logs include sensitive metadata (Priority: Medium)

Baseline:

Checks if firewall rule logging is configured to exclude sensitive metadata.

Description:

When firewall logs include all metadata, they might capture sensitive information that could potentially expose security details or violate data privacy requirements. Logging all metadata increases the risk of exposing sensitive data that could be exploited if logs are compromised.

Recommendation:

Configure firewall rule logging to exclude metadata or include only necessary metadata. Use the "EXCLUDE_ALL_METADATA" option when configuring log settings for firewall rules, or selectively include only the required metadata.

1. Enable Automated Backups (Priority: High)

Baseline:

Automated backups ensure the protection of your valuable data by creating regular, scheduled backups of your Cloud SQL databases. In case of accidental data loss, database corruption, or other unforeseen issues, you can easily restore your data to the previous state.

Recommendation:

In the Backups section, check whether Automated Backups are enabled.

2. Enable High Availability (Priority: High)

Baseline:

Checks the instances that have configured ZONAL availability.

Description:

Data redundancy is maintained during planned maintenance or outages by enabling a High Availability (HA) configuration or database cluster in Google Cloud SQL. As it operates across both a primary and secondary zone within the designated Google Cloud region, a Cloud SQL instance configured for high availability is referred to as a regional instance.

Recommendation:

Make sure that HA and automatic failover support are set up for all of your production and mission-critical Google Cloud SQL database instances.

3. Enable Point-in-Time Recovery (Priority: Moderate)

Baseline:

Checks the instances that have not configured a Point-in-Time Recovery flag.

Description:

Point-in-Time Recovery (PITR) allows you to restore a Google Cloud MySQL database instance to a precise moment—even down to the exact second. This feature is particularly valuable if data loss occurs due to an error or if the database becomes corrupted, enabling you to revert the database to its operational state before the issue.

Recommendation:

Ensure that the Point-in-Time Recovery (PITR) feature is enabled for all MySQL database instances in your GCP account. This allows you to restore data from a specific point in time while maintaining cost efficiency. Before enabling PITR, ensure that automated backups and binary logging are both activated for your MySQL database instances.

4. Enable slow_query_log flag in MySQL (Priority: Medium)

Baseline:

Checks if the slow_query_log flag is enabled for MySQL instances.

Description:

The slow_query_log flag enables the logging of queries that exceed a defined execution time. This helps identify performance issues and potential optimization opportunities in your database.

Recommendation:

Enable the slow_query_log flag in your CloudSQL MySQL instance to identify and optimize slow-performing queries.

5. Set log_error_verbosity flag in PostgreSQL (Priority: Medium)

Baseline:

Checks if the log_error_verbosity flag is set to verbose for PostgreSQL instances.

Description:

The log_error_verbosity flag controls the detail level of messages logged. The verbose setting includes function names, line numbers, and other details that are crucial for effective debugging and troubleshooting.

Recommendation:

Set the log_error_verbosity flag to verbose in your CloudSQL PostgreSQL instance to ensure comprehensive error information is captured in logs.

6. Disable log_planner_stats flag in PostgreSQL (Priority: Medium)

Baseline:

Checks if the log_planner_stats flag is disabled for PostgreSQL instances.

Description:

The log_planner_stats flag logs query planner performance statistics, which can generate excessive log entries in production environments. This level of detail is typically only needed during specific debugging or optimization sessions.

Recommendation:

Disable the log_planner_stats flag in your CloudSQL PostgreSQL instance for production environments to prevent excessive logging and potential performance impact.

1. Underutilized Compute instance (Priority: Moderate)

Baseline:

Checks the resource utilization of Google Compute Engine instances and labels them as underutilized, if the CPU usage is less than 2% for the past 48 hours.

Recommendation:

For Google Compute Engine, you are billed based on the instance type and the number of consumed hours. You can lower your costs by identifying and stopping under utilized instances. In addition, Site24x7's Guidance Report also shows the Current Machine Type and recommend the desired instance type (Suggested Machine Type) that you can downgrade to, for better cost cutting.

2. High utilized Compute instance (Priority: High)

Baseline:

Checks the performance counters for GCP Compute and identifies instances that appear to be highly utilized.

Description:

A Compute instance is deemed as overutilized if it meets the following criteria:

• The average daily CPU usage for the Compute instance is more than 90% for the last seven days.
• The average daily memory utilization for the Compute instance is more than 90% for the last seven days (applicable only if you've deployed our agent on the Compute instance).

Recommendation:

Consider changing the instance size or add the instance to an autoscaling group.

3. Compute maintenance configuration (Priority: High)

Baseline:

Checks whether the instance On host maintenance is marked as TERMINATE.

Description:

Google Cloud Compute Engine enables VM instances to be migrated during infrastructure maintenance without any downtime. Set the On host maintenance option under the Availability policies to Migrate to ensure VMs are moved to a new hardware.

Recommendation:

Configure VM instances for live migration to ensure that they are moved to a new host, preventing downtime during maintenance.

4. Preemptible instances (Priority: High)

Baseline:

Checks whether the instance's preemptible flag is enabled.

Description:

Preemptible instances are cost-effective, short-lived VMs that Google Cloud can stop at any moment. Designed for interruptible workloads, they provide substantial cost savings but have a maximum runtime of 24 hours.

Recommendation:

To ensure that your instances are not preemptible, follow these steps:

1. Navigate to the GCP console > Compute Engine section.
2. Stop the VM instance you wish to modify.
3. Edit the VM instance settings and set Preemptibility to Regular instead of Preemptible.
4. Save the changes and restart the instance.

5. Auto-restart disabled instances (Priority: Moderate)

Baseline:

Checks whether the instance's automaticRestart flag is enabled.

Description:

The Google Cloud Compute Engine service may stop due to non-user-initiated reasons, including maintenance events, hardware issues, and software failures.

Recommendations:

• Enable automatic restart to ensure that your instance is automatically restarted in case of VM host failure. 
• Automatic restart helps maintain availability by recovering instances without manual intervention.

1. Unattached Disks (Priority: Moderate)

Baseline: 

Check Compute Engine disk configuration for the associated instance ID.

Description:

Compute Engine disks can persist independently even after instance termination or after you explicitly unmount and detach the volume from the instance. As you may know, unattached volumes are still charged based on the provisioned storage and for input/output operations per second (IOPS).

Recommendation:

Associate the configured Compute Engine disks with an active instance or delete the disk.

1. Enable auto repair cluster nodes (Priority: Moderate)

Baseline:

Checks whether the cluster node auto repair property is disabled.

Description:

Auto-repair helps maintain the health of your GKE cluster nodes. When enabled, GKE periodically checks the health of each node, and if a node fails multiple health checks within a set timeframe, GKE automatically initiates a repair process.

Recommendation:

Enable the auto-repair feature for all GKE cluster nodes to maintain their health and ensure smooth operation.

1. Restrict unauthorized access (Priority:High)

Baseline:

Checks whether Filestore's access control is restricted to an IP address or range.

Description:

By default, Filestore allows unrestricted access for clients in the same project and VPC network, which can result in data breaches. To enhance security, implement IP-based access control to limit access to trusted IP addresses and block all others.

Recommendation:

Ensure that you establish trusted IP addresses or ranges to prevent any unauthorized access to sensitive data.

1. Enable CMEKs (Priority: High)

Baseline:

Checks whether the functions' CMEKs are configured.

Description:

Google Cloud automatically encrypts data stored with Google-managed keys. For additional control, consider using CMEKs through Cloud KMS for secure key management, rotation, and revocation.

Recommendation:

Use CMEKs instead of Google-managed encryption keys for greater control and compliance.

2. Minimum instance configuration (Priority: Moderate)

Baseline:

Checks whether the functions are configured for minimum instance settings.

Description:

Cloud Run functions can experience cold starts, increasing latency. To minimize this, set a minimum number of function instances. This ensures faster response times and better reliability by keeping some instances warm and ready, reducing latency. This is important for production workloads with consistent traffic or low-latency needs.

Recommendation:

Reduce cold start times and improve performance by setting enough warm instances for Cloud Run functions.

1. Enable end-to-end HTTP/2 (Priority: Moderate)

Baseline:

Checks whether end-to-end HTTP/2 is disabled for Cloud Run services.

Description:

Enabling end-to-end HTTP/2 improves performance by allowing multiplexing of requests and reducing latency, which can enhance the user experience for applications running on Cloud Run.

Recommendation:

Enable end-to-end HTTP/2 for your Cloud Run services to improve performance and reduce latency.

2. Minimum instances (Priority: Moderate)

Baseline:

Checks whether the minimum number of instances is configured for Cloud Run services.

Description:

Configuring the minimum number of instances helps to ensure that your Cloud Run services are always available and can handle sudden spikes in traffic.

Recommendation:

Set a minimum number of instances for your Cloud Run services to ensure availability and handle traffic spikes effectively.

1. Enable versioning (Priority: Moderate)

Baseline:

Checks whether the versioning settings are enabled for your GCP storage buckets.

Description:

Enabling versioning helps protect against accidental deletions and overwrites by keeping multiple versions of an object.

Recommendation:

Enable versioning for your storage buckets to protect against data loss and maintain object history.

1. Dead letter policy disabled (Priority: Low)

Baseline:

Checks Cloud Pub/Sub subscriptions to identify those without a dead letter policy configured.

Description:

Dead letter policies provide a mechanism to handle messages that cannot be processed after repeated attempts. Without a dead letter policy, problem messages can block processing and cause delivery delays for other messages in the subscription.

Recommendation:

Configure dead letter policies for your Pub/Sub subscriptions to ensure proper message handling and prevent unprocessable messages from causing service disruptions.

1. Auto-healing disabled instance groups (Priority: High)

Baseline:

Checks whether the instance group's auto-healing configuration is disabled.

Description:

Auto-healing helps maintain the health and availability of your managed instance groups by automatically repairing unhealthy VMs. When enabled, Google Cloud regularly checks the health of each instance and recreates instances that fail health checks, ensuring your applications remain available and resilient.

Recommendation:

Enable auto-healing for your managed instance groups to increase application reliability and reduce manual intervention during instance failures.

2. Single-zone instance groups (Priority: Low)

Baseline:

Checks whether the instance group is deployed in a single zone.

Description:

Single-zone instance groups are vulnerable to zone-specific outages, which can affect application availability. Regional (multi-zone) managed instance groups distribute VM instances across multiple zones within a region, providing higher availability and resilience against zone failures.

Recommendation:

Convert single-zone managed instance groups to regional managed instance groups to improve application availability and protect against zone-level failures.

1. Cloud CDN not enabled (Priority: Medium)

Baseline:

Checks if Cloud CDN is enabled for Google Cloud load balancers.

Description:

Cloud Content Delivery Network(CDN) caches content at Google's edge locations to reduce latency, minimize origin server load, and reduce serving costs. Without Cloud CDN, your applications might experience increased latency, higher origin server load, and higher data transfer costs, especially for static content.

Recommendation:

Enable Cloud CDN for your HTTP(S) load balancers to improve performance and reduce costs. Configure appropriate cache settings based on your application's content characteristics. For dynamic content that must be served from the origin, consider using cache control headers to optimize caching behavior.

1. Hanged jobs (Priority: Medium)

Baseline:

Checks if any Dataflow jobs have been running for more than six hours.

Description:

Dataflow jobs that run for extended periods of time might be stuck or experiencing issues, which can lead to unnecessary resource consumption and costs.

Recommendation:

Review long-running Dataflow jobs to determine if they are functioning correctly or need to be terminated. Consider implementing job timeouts or monitoring to detect automatically and address potentially hanged jobs.

1. VM instance deletion protection (Priority: High)

Baseline:

Check the configuration of VM instances to see whether the Deletion protection option is enabled or not in the GCP console.

Description:

To protect your instance from accidental deletion, you can enable the Deletion protection option in the GCP console.

Recommendation:

The Deletion protection option is disabled by default. Enable this option to prevent unexpected instance termination.

2. Public IP instances (Priority: High)

Baseline:

Checks whether the network interface's External IPv4 is assigned and named as External NAT.

Description:

Assigning public IP addresses to your Google Cloud Compute Engine instances can expose them to unnecessary security risks.

Recommendation:

Consider using any of the alternate approaches below instead of public IP.

• Use private IPs for internal communication.
• Use Cloud NAT for secure outbound traffic.
• Apply firewalls & IAM to restrict access.

3. Auto-delete for attached disks (Priority: Moderate)

Baseline:

Checks whether the instance's attached disks have the autoDelete flag enabled.

Description:

By default, Google Cloud deletes persistent disks when a Compute Engine instance is deleted. It may result in unintentional data loss.

Recommendations:

• Disable the autoDelete flag when deleting an instance to avoid accidental data loss.
• Manually manage disk deletion for data retention and backup.

4. IP forwarding for VM instances (Priority: Moderate)

Baseline:

Checks whether the instance's IP forward flag is enabled.

Description:

IP forwarding allows a VM to route traffic between different networks. When enabled, the VM can forward packets from one network to another, acting like a router.

Recommendations:

• Disable IP forwarding for instances that don’t need to route traffic between different networks in compliance with GCP’s security best practices.
• Enable IP forwarding only when necessary for use cases like gateways or routers, ensuring alignment with GCP's least-privilege access model.

5. Interactive serial console support (Priority: Moderate)

Baseline:

Checks whether the instance metadata's serial-port-enable key is set to True.

Description:

The IP-based access controls are not supported by the interactive serial console. Enabling it allows anyone with the correct username, SSH key, project ID, instance name, and zone to attempt a connection, regardless of the IP address.

Recommendation:

You can explicitly disable it by setting the serial-port-enable key to False.

1. Check for MySQL Major Version (Priority: Moderate)

Baseline:

Ensure that your Google Cloud MySQL database instances are using the latest major version of MySQL database in order to receive the latest database features and benefit from enhanced performance and security.

Recommendation:

Upgrade the database version.

2. Check for PostgreSQL Major Version (Priority: Moderate)

Baseline:

Ensure that your Google Cloud PostgreSQL database instances are using the latest major version of PostgreSQL database in order to receive the latest database features and benefit from enhanced performance and security.

Recommendation:

Upgrade the database version.

3. Rotate server certificate (Priority: High)

Baseline:

Checks whether the instance's serverCaCert expiration time is less than 30 days.

Description:

If the SSL/TLS protocol is mandatory for all incoming connections to Cloud SQL database instances, access is restricted to authenticated clients with valid SSL certificates. Failure to renew (rotate) SSL certificates before they expire will render them invalid, potentially disrupting secure communication between clients and database instances.

Recommendation:

Make sure to rotate all server certificates configured for your Cloud SQL database instances before they expire. This helps maintain secure incoming connections and ensures that web clients use valid SSL certificates to access your databases.

4. Enable customer-managed encryption (Priority: High)

Baseline:

Checks whether the instances are encrypted using Customer Master Keys (CMKs) instead of GCP managed-keys.

Description:

Google Cloud SQL encrypts data at rest using Google-managed keys by default, without any user intervention. However, if you require full control over encryption, you can use CMKs through Cloud Key Management Service (Cloud KMS), which is ideal for sensitive or mission-critical data, especially in enterprise environments with strict security and compliance needs.

Recommendation:

Ensure that your Google Cloud SQL database instances are encrypted with CMKs to enhance control over your data's encryption and decryption processes. You can create and manage these CMKs through Cloud KMS, which offers secure and efficient key management, along with controlled key rotation and revocation features.

5. Allow SSL/TLS connections only (Priority: Moderate)

Baseline:

Checks whether the instances allow connections in unencrypted mode.

Description:

When Cloud SQL database connections are vulnerable to Man-in-the-Middle (MITM) attacks, sensitive data like user credentials, queries, and results can be exposed. To protect data in transit, it is strongly advised to enforce SSL/TLS for all incoming connections to Cloud SQL database instances, especially when using public IP addresses.

Recommendation:

Ensure that SSL/TLS encryption is applied to all incoming connections to your Cloud SQL database instances to prevent unauthorized access and eavesdropping. To enforce SSL/TLS, configure the SSL enforcement mode to "ENCRYPTED_ONLY" for all SQL database instances.

6. Public IP enabled SQL instances (Priority: Moderate)

Baseline:

Checks whether any of the instance's ipAddress type is configured as PRIMARY.

Description:

Each Google Cloud SQL database instance is assigned a public IP address by default. To minimize the attack surface of your application, it's recommended to only use private IPs for Cloud SQL databases. Private IPs enhance cloud network security and reduce latency for your database applications.

Recommendation:

Ensure that your Google Cloud SQL database instances are configured to use private IP addresses instead of public IPs to enhance security and reduce exposure to potential threats.

7. Publicly accessible SQL instances (Priority: Moderate)

Baseline:

Checks whether the instance is configured as IPv4 enabled and authorized Network IP address is wild-card.

Description:

Allowing public access (e.g., 0.0.0.0/0) to an SQL database instance lets any IPv4 client attempt to log in, though valid credentials are still required. To reduce the attack surface, only trusted IPs and networks should be whitelisted for access.

Recommendation:

Make that your Google Cloud SQL database instances are set up only to accept connections from authorized IP addresses and trusted networks.

8. Delete protection disabled instances (Priority: High)

Baseline:

Checks whether the instance's configuration has disabled the delete protection.

Description:

Instance deletion protection enables you to prevent the accidental removal of existing and new instances. Using instance deletion protection, you can safeguard instances that are important to your applications and services.

Recommendation:

Enable delete protection to prevent accidental instance removal.

9. Disable local_infile flag in MySQL (Priority: Medium)

Baseline:

Checks if the local_infile flag is set to off for MySQL instances.

Description:

The local_infile flag in MySQL controls whether the LOAD DATA INFILE statement can load data from files on the client side. When enabled, this feature could potentially allow attackers to read arbitrary files from the server, presenting a security risk.

Recommendation:

Disable the local_infile flag by setting it to off in your CloudSQL MySQL instance configuration to prevent potential security vulnerabilities.

10. Enable skip_show_database flag in MySQL (Priority: Medium)

Baseline:

Checks if the skip_show_database flag is enabled for MySQL instances.

Description:

The skip_show_database flag prevents users without the SHOW DATABASES privilege from seeing database names through the SHOW DATABASES statement. This restricts unauthorized users from discovering database names in your CloudSQL instance.

Recommendation:

Enable the skip_show_database flag in your CloudSQL MySQL instance to prevent unauthorized users from discovering database names.

11. Enable log_checkpoints flag in PostgreSQL (Priority: Medium)

Baseline:

Checks if the log_checkpoints flag is enabled for PostgreSQL instances.

Description:

The log_checkpoints flag logs checkpoint operations to the server log. Checkpoint operations write all modified data to disk to ensure data durability. Logging these operations helps monitor database performance and recovery processes.

Recommendation:

Enable the log_checkpoints flag in your CloudSQL PostgreSQL instance to track checkpoint operations for better performance monitoring and troubleshooting.

12. Enable log_connections flag in PostgreSQL (Priority: Medium)

Baseline:

Checks if the log_connections flag is enabled for PostgreSQL instances.

Description:

The log_connections flag logs each successful client connection to the server log. This helps track who is accessing your database, enhancing security monitoring and audit capabilities.

Recommendation:

Enable the log_connections flag in your CloudSQL PostgreSQL instance for better security monitoring and connection tracking.

13. Enable log_disconnections flag in PostgreSQL (Priority: Medium)

Baseline:

Checks if the log_disconnections flag is enabled for PostgreSQL instances.

Description:

The log_disconnections flag logs session terminations to the server log, including the duration of each session. This complements the log_connections flag by providing a complete picture of the database session life cycle.

Recommendation:

Enable the log_disconnections flag in your CloudSQL PostgreSQL instance to track session duration and terminations for security monitoring.

14. Disable log_executor_stats flag in PostgreSQL (Priority: Medium)

Baseline:

Checks if the log_executor_stats flag is disabled for PostgreSQL instances.

Description:

The log_executor_stats flag logs executor performance statistics, which can generate excessive log entries in production environments and potentially impact performance. This level of detail is typically only needed during specific debugging sessions.

Recommendation:

Disable the log_executor_stats flag in your CloudSQL PostgreSQL instance for production environments to prevent excessive logging and potential performance impact.

15. Enable log_hostname flag in PostgreSQL (Priority: Medium)

Baseline:

Checks if the log_hostname flag is enabled for PostgreSQL instances.

Description:

The log_hostname flag logs the client hostname in connection and disconnection messages instead of just the IP address. This provides more detailed information for security monitoring and auditing purposes.

Recommendation:

Enable the log_hostname flag in your CloudSQL PostgreSQL instance to capture client hostnames in connection logs for better security tracking.

16. Enable log_lock_waits flag in PostgreSQL (Priority: Medium)

Baseline:

Checks if the log_lock_waits flag is enabled for PostgreSQL instances.

Description:

The log_lock_waits flag logs long lock wait times, which helps identify potential database deadlocks and performance bottlenecks caused by lock contentions.

Recommendation:

Enable the log_lock_waits flag in your CloudSQL PostgreSQL instance to detect and troubleshoot lock-related performance issues.

17. Disable log_min_duration_statement flag in PostgreSQL (Priority: Medium)

Baseline:

Checks if the log_min_duration_statement flag is disabled for PostgreSQL instances.

Description:

The log_min_duration_statement flag logs statements running longer than a specified duration. While useful for performance tuning, it can lead to sensitive data exposure in logs if SQL statements contain sensitive information.

Recommendation:

Disable the log_min_duration_statement flag in your CloudSQL PostgreSQL instance in production environments when handling sensitive data, or set it to a high value to capture only truly problematic queries.

18. Disable log_parser_stats flag in PostgreSQL (Priority: Medium)

Baseline:

Checks if the log_parser_stats flag is disabled for PostgreSQL instances.

Description:

The log_parser_stats flag logs parser performance statistics, which can generate excessive log entries in production environments. This level of detail is typically only needed during specific debugging sessions.

Recommendation:

Disable the log_parser_stats flag in your CloudSQL PostgreSQL instance for production environments to prevent excessive logging and potential performance impact.

19. Enable log_temp_files flag in PostgreSQL (Priority: Medium)

Baseline:

Checks if the log_temp_files flag is properly configured for PostgreSQL instances.

Description:

The log_temp_files flag logs the use of temporary files above a specified size. This helps identify queries that require excessive disk space for temporary operations, which can impact database performance.

Recommendation:

Configure the log_temp_files flag in your CloudSQL PostgreSQL instance to track large temporary file usage and identify queries that may need optimization.

20. Enable pgAudit extension in PostgreSQL (Priority: Medium)

Baseline:

Checks if the pgAudit extension is enabled for PostgreSQL instances.

Description:

The pgAudit extension provides detailed session and object audit logging capabilities that are often required for regulatory compliance. It provides more comprehensive auditing than PostgreSQL's native logging functionality.

Recommendation:

Enable the pgAudit extension in your CloudSQL PostgreSQL instance to meet compliance requirements and enhance security monitoring capabilities.

21. Disable contained database authentication in SQL Server (Priority: Medium)

Baseline:

Checks if the contained database authentication is disabled for SQL Server instances.

Description:

Contained database authentication stores user credentials within the database itself rather than in the server's master database. This can create security risks, including potential credential exposure and challenges with centralized authentication management.

Recommendation:

Turn off contained database authentication for your CloudSQL SQL Server instances by setting the contained database authentication flag to off in order to keep centralized control over authentication.

22. Disable cross-database ownership chaining in SQL Server (Priority: Medium)

Baseline:

Checks if cross-database ownership chaining is disabled for SQL Server instances.

Description:

Cross-database ownership chaining allows users with permissions in one database to access objects in another database without explicit permissions. This can lead to privilege escalation and unintended data access across database boundaries.

Recommendation:

Turn off cross-database ownership chaining for your CloudSQL SQL Server instances by setting the cross db ownership chaining flag to off to ensure correct permission boundaries between databases.

23. Disable external script execution in SQL Server (Priority: Medium)

Baseline:

Checks if external script execution is disabled for SQL Server instances.

Description:

The external scripts enabled flag allows execution of scripts in languages like R and Python within SQL Server. While powerful for data analysis, this feature expands the attack surface by allowing potentially malicious code execution outside SQL Server's security boundaries.

Recommendation:

Disable external script execution for your CloudSQL SQL Server instances by setting the external scripts enabled flag to off unless specifically required, and if enabled, implement strict controls over who can execute external scripts.

24. Disable remote access in SQL Server (Priority: Medium)

Baseline:

Checks if remote access is disabled for SQL Server instances.

Description:

The remote access flag enables stored procedures to be run from remote servers. When enabled, this could expose your database to potential security risks by allowing remote execution of code.

Recommendation:

Prevent unauthorized stored procedure execution from remote servers by disabling remote access for your CloudSQL SQL Server instances by setting the remote access flag to off.

25. Disable trace flag 3625 in SQL Server (Priority: Medium)

Baseline:

Checks if trace flag 3625 is disabled for SQL Server instances.

Description:

Trace flag 3625 limits the information returned to users when SQL Server exceptions occur. While this can be useful in production to prevent potential exposure of sensitive information, it can also hide details needed for proper auditing and security monitoring.

Recommendation:

Ensure trace flag 3625 is properly configured according to your environment's security requirements. For environments requiring comprehensive audit logs, consider disabling this flag to ensure full error information is captured.

26. User options not configured in SQL Server (Priority: Medium)

Baseline:

Checks if the user options flag is not configured for SQL Server instances.

Description:

The user options flag sets default settings for all users. Configuring this at the server level can lead to unexpected behavior and potential security issues. It's better to manage user options at more granular levels.

Recommendation:

Ensure the user options flag is not configured by removing any database flag with name user options to maintain security best practices for your CloudSQL SQL Server instance.

 

1. Enable critical notifications (Priority: Moderate)

Baseline:

Checks whether the cluster's Pub/Sub notifications are disabled.

Description:

Configuring Google Kubernetes Engine (GKE) cluster notifications via Pub/Sub ensures timely alerts for upgrades, security updates, and new releases, minimizing downtime and keeping you informed of risks and optimization opportunities.

Recommendation:

Enable critical alert notifications for your GKE clusters to receive essential Pub/Sub messages from Google Cloud regarding upgrades, security updates, and other important information.

2. Enable intranode visibility (Priority: Moderate)

Baseline:

Checks whether the cluster's intranode visibility is disabled.

Description:

Intranode visibility routes all pod-to-pod traffic through the Google Cloud Virtual Private Cloud (VPC) network, even on the same node, ensuring consistent firewall rules, flow logs, and packet mirroring.

Benefits:

• Complete flow logs: Capture all pod traffic, including intranode traffic.
• Uniform firewall rules: Apply rules to all pod communication.
• Full traffic inspection: Mirror and analyze all traffic, even intranode traffic.

Recommendation:

Enable intranode visibility on your GKE clusters to monitor and secure intranode pod traffic using VPC flow logs and tools.

3. Enable workload vulnerability scanning (Priority: Moderate)

Baseline:

Checks whether the cluster's workload vulnerability scanning is disabled.

Description:

Enable GKE workload vulnerability scanning to detect and fix security issues in container images and packages, reducing risks. Choose basic or advanced scanning, with a scanning pod deployed to each node.

Recommendation:

Enable workload vulnerability scanning for your GKE clusters to identify vulnerabilities in container images, ensure security compliance, and safeguard your clusters from potential threats.

4. Enable cluster logging (Priority: Moderate)

Baseline:

Checks whether the cluster's logging feature is disabled.

Description:

Cloud Logging, a GKE add-on, collects logs and metrics and sends them to a remote aggregator, reducing tampering risks. It provides insights into cluster health, performance, and security, aiding troubleshooting, proactive maintenance, and compliance.

Recommendation:

Enable logging for your GKE clusters to collect logs from your Kubernetes applications and the underlying GKE infrastructure.

5. Enable cluster monitoring (Priority: Moderate)

Baseline:

Checks whether the cluster's monitoring feature is disabled.

Description:

Cloud Monitoring, a GKE add-on, collects metrics from applications and infrastructures. Without it, identifying performance issues, security threats, and failures is challenging. Enabling monitoring provides insights into cluster health, reliability, and performance, aiding troubleshooting, proactive maintenance, and compliance.

Recommendation:

Make sure to enable Cloud Monitoring for your GKE clusters to gather metrics from both your Kubernetes applications and the underlying GKE infrastructure supporting them.

6. Enable the security posture feature (Priority: Moderate)

Baseline:

Checks whether the cluster's security posture feature is disabled.

Description:

Security posture auditing evaluates GKE workloads against best practices, providing a centralized view of vulnerabilities to help you address issues proactively. It ensures a secure containerized environment and is available only for GKE Enterprise edition clusters.

Recommendation:

Enable the Security Posture dashboard for your GKE clusters. It integrates with Cloud Logging, Policy Controller, and Binary Authorization to identify vulnerabilities, misconfigurations, and compliance risks, enhancing security and adherence to regulations.

7. Enable Integrity Monitoring for Cluster Nodes (Priority: Moderate)

Baseline:

In the Google Cloud console's Security section, check the Integrity monitoring feature status. Ensure that the Integrity Monitoring feature is enabled for your Google Kubernetes Engine (GKE) cluster nodes in order to monitor and automatically check the runtime boot integrity of your shielded cluster nodes using Google Cloud Monitoring service.

Recommendation:

Enable Integrity Monitoring for Cluster Nodes.

8. Configure Shielded GKE Cluster Nodes (Priority: Moderate)

Baseline:

Ensure that your Google Kubernetes Engine (GKE) cluster pool nodes are shielded in order to provide strong cryptographic identity. This limits the ability of an attacker to impersonate a node in your GKE cluster even if the attacker is able to extract the node credentials.

Recommendation:

Configure Shielded GKE Cluster Nodes. Check the Shielded GKE Nodes configuration attribute value.

9. Restrict Network Access to GKE Clusters (Priority: Moderate)

Baseline:

Adding master authorized networks can provide network level protection and additional security benefits for your Google Kubernetes Engine (GKE) cluster. Authorized networks grant access to a specific set of trusted IP addresses, such as those that originate from a secure network. This can help protect access to your GKE cluster in case of a vulnerability in the cluster's authentication or authorization mechanism.

Recommendation:

Check the Master authorized networks attribute value. If the Master authorized networks value is set to Disabled, anyone on the Internet can perform network connections to the cluster control plane.

10. Enable release channel for version upgrade (Priority: Moderate)

Baseline:

Checks whether the instance has configured the release channel as Rapid.

Description:

Google Kubernetes Engine (GKE) release channels automatically choose cluster versions to maintain a balance between new features and stability. The Stable channel offers fewer updates for proven reliability, ideal for production. The Regular channel provides more frequent updates with newer features but less validation. All channels receive critical security patches.

Recommendation:

To simplify version management and automate GKE cluster upgrades, subscribe to the Regular or Stable release channel.

11. Enable auto-upgrade cluster nodes (Priority: Moderate)

Baseline:

Checks whether the cluster node auto upgrade property is disabled.

Description:

Turning on auto-upgrades for your GKE cluster nodes streamlines upgrade management by automatically and securely updating Kubernetes to the latest supported version. This ensures access to the most recent security fixes, features, and enhancements.

Recommendation:

Enable the auto-upgrade feature for all nodes in your GKE clusters to ensure they stay up to date with the latest supported Kubernetes version.

12. Enable application secrets encryption (Priority: High)

Baseline:

Checks whether the cluster's application-layer secrets encryption is disabled.

Description:

By default, Kubernetes stores secrets as base64-encoded plaintext in etcd. Enabling application-layer secrets encryption adds an extra layer of security by encrypting secrets with a Google-managed key or a customer-managed encryption key. This prevents unauthorized access to sensitive information like passwords, OAuth tokens, and SSH keys even if someone gains access to etcd storage.

Recommendation:

Enable application-layer secrets encryption for your GKE clusters to protect sensitive Kubernetes secrets. For enhanced control, consider using customer-managed encryption keys.

13. Enable Network Policy (Priority: Medium)

Baseline:

Checks whether Network Policy is enabled on your GKE clusters.

Description:

Network Policy allows you to control pod-to-pod communication within your cluster. Without Network Policy enabled, all pods can communicate with each other, which could lead to unauthorized access between application components.

Recommendation:

Enable Network Policy on your GKE clusters to implement fine-grained control over pod-to-pod communication and improve your cluster's security posture.

1. Enable deletion protection (Priority: Moderate)

Baseline:

Checks whether Filestore's deletion protection is disabled.

Description:

With deletion protection enabled, your Filestore instances are safeguarded from accidental deletion. This prevents users from deleting instances via the Google Cloud console, CLI, or API unless the feature is explicitly disabled.

Recommendation:

Enable the deletion protection feature in your Filestore instances to prevent accidental deletion.

2. Configure on-demand backup and restoration (Priority: Moderate)

Baseline:

Checks whether Filestore's on-demand backup and restoration are configured.

Description:

On-demand Filestore backups are stored externally, with the first backup being a full copy, and subsequent ones capturing only changes. They provide essential data protection by enabling point-in-time recovery and quick restoration in case of accidental deletion, corruption, or disasters, ensuring minimal downtime and business continuity.

Recommendation:

Utilize on-demand backup and restoration for Filestore to improve data protection, aid in disaster recovery, and adhere to compliance regulations without affecting the provisioned capacity or application performance.

3. Enable customer-managed encryption keys (Priority: High)

Baseline:

Checks whether Filestore's customer-managed encryption keys (CMEKs) are configured.

Description:

Google Cloud automatically encrypts data stored with Google-managed keys. For additional control, consider using CMEKs through Google Cloud Key Management Service (KMS) for secure key management, rotation, and revocation.

Recommendation:

Use CMEKs instead of Google-managed encryption keys for greater control and security compliance.

1. Key rotation (Priority: Low)

Baseline:

Checks whether the Cloud KMS key rotation interval is less than 90 days.

Description:

Rotate Cloud KMS keys every 90 days to align with security and compliance requirements. These keys are used for encrypting and decrypting data, and new versions with updated key material are automatically created at set intervals for rotation.

Recommendation:

User-managed Cloud KMS keys are powerful but risky if mishandled. Optimal rotation reduces the chance of compromise.

2. Publicly accessible keys (Priority: High)

Baseline:

Checks whether Cloud KMS keys are publicly accessible.

Description:

Make sure the IAM policy for Cloud KMS keys limits access to prevent anonymous or public users from accessing them. Remove permissions for allUsers and allAuthenticatedUsers to prevent access by these users. The allUsers role includes internet users, while the allAuthenticatedUsers role includes users and service accounts with a Google Cloud login.

Recommendation:

Make sure that Cloud KMS resources do not grant access to the allUsers and allAuthenticatedUsers roles in order to avoid data breaches.

1. Enable automatic runtime security updates (Priority: Moderate)

Baseline:

Checks whether automatic runtime security updates are configured for Cloud Run functions.

Description:

Google updates and secures Cloud Run functions through regular maintenance and stability testing. This includes updates to the execution environment, such as the OS and packages, to ensure a safe environment for your functions. Google Cloud also automatically manages security updates for your function runtime environment.

Recommendation:

Enable automatic runtime security updates for Cloud Run functions to ensure continuous security and protection against vulnerabilities without requiring manual intervention.

2. Enable Serverless VPC Access (Priority: High)

Baseline:

Checks whether Serverless VPC Access is configured for the functions.

Description:

Serverless VPC Access allows for a secure, speedy connection between your VPC network and a serverless environment, like Cloud Run functions. Connectors handle traffic between the two setups. Simply create a VPC connector in your Google Cloud project, link it to a VPC network and region, and set up your serverless services to use the connector for fast, secure outbound network traffic.

Recommendation:

Configure Cloud Run functions with Serverless VPC Access for a direct connection to your VPC network. This enables connectivity to other VPC resources, such as VM instances, Memorystore instances, and internal IP addresses of other cloud resources.

3. Secure outbound network access (Priority: High)

Baseline:

Checks whether the functions have unrestricted network access.

Description:

Unrestricted outbound network access can lead to harmful actions, such as data theft, manipulator-in-the-middle attacks, and denial-of-service attacks. Limiting access to the necessary resources reduces these risks.

Recommendation:

Limit outbound network access to protect your functions and save on costs. Utilize VpcConnectorEgressSettings to limit external traffic and avoid external network communication.

4. A deprecated execution runtime environment version (Priority: High)

Baseline:

Checks whether the functions are using an outdated execution runtime environment.

Description:

Cloud Run functions' second generation has major improvements compared to the first generation, including faster cold starts and execution times, a wider range of runtime environments, enhanced networking and integrations with Google Cloud services, and better monitoring and debugging tools. Upgrading to the second generation is highly recommended for better performance, better flexibility, and smoother development and operations processes. It combines the strengths of Google Cloud Run and Google Cloud Eventarc, offering features like concurrent processing, traffic distribution, and a longer processing duration.

Recommendation:

Upgrade Cloud Run functions to the latest runtime version for improved security, improved performance, and access to new features. Older versions are no longer supported and may be less secure and efficient.

5. A deprecated runtime version (Priority: High)

Baseline:

Checks whether the functions are using a deprecated runtime version.

Description:

Updating to the latest language runtime for Cloud Run functions is essential for improved security, improved performance, and access to new features and libraries. This ensures that bug fixes, optimizations, and compatibility with other services are in place, minimizing vulnerabilities and keeping serverless applications smooth and efficient.

Recommendation:

Always use the latest language runtime for Cloud Run functions to follow best practices and access new features.

1. Maximum instances (Priority: Moderate)

Baseline:

Checks whether the maximum number of instances are configured for Cloud Run services.

Description:

Configuring the maximum number of instances helps to control costs and ensure that the service does not scale beyond a certain limit, which is crucial for budget management and resource allocation.

Recommendation:

Set a maximum number of instances for your Cloud Run services to manage costs and resource usage effectively.

2. Automatic runtime security updates (Priority: High)

Baseline:

Checks whether the automatic runtime security updates are disabled for Cloud Run services.

Description:

Enabling automatic runtime security updates ensures that your Cloud Run services are always running the latest security patches, reducing the risk of vulnerabilities and improving overall security.

Recommendation:

Enable automatic runtime security updates for your Cloud Run services to maintain security and compliance.

3. Enable binary authorization (Priority: High)

Baseline:

Checks whether binary authorization is disabled for Cloud Run services.

Description:

Binary authorization ensures that only trusted container images are deployed to your Cloud Run services, enhancing security by preventing the execution of unverified or potentially harmful code.

Recommendation:

Enable binary authorization for your Cloud Run services to ensure that only trusted and verified container images are deployed.

4. Use CMEK encryption (Priority: High)

Baseline:

Checks whether customer-managed encryption keys (CMEKs) are used for Cloud Run services.

Description:

Using CMEKs allows you to have full control over the encryption keys used to protect your data, enhancing security and compliance with regulatory requirements.

Recommendation:

Use CMEKs for your Cloud Run services to enhance security and compliance.

5. Restrict outbound network (Priority: High)

Baseline:

Checks whether outbound network access is restricted for Cloud Run services.

Description:

Restricting outbound network access helps to minimize the attack surface and prevent unauthorized data exfiltration from your Cloud Run services.

Recommendation:

Restrict outbound network access for your Cloud Run services to enhance security and prevent unauthorized data exfiltration.

6. Deprecated runtime version (Priority: High)

Baseline:

Checks whether the runtime version used for Cloud Run services is deprecated.

Description:

Using a deprecated runtime version can expose your Cloud Run services to security vulnerabilities and compatibility issues. It is important to use the latest supported runtime version to ensure security and stability.

Recommendation:

Update your Cloud Run services to use the latest supported runtime version to ensure security and stability.

7. Publicly accessible (Priority: High)

Baseline:

Checks whether Cloud Run services are publicly accessible.

Description:

Making Cloud Run services publicly accessible can expose them to potential security risks. It is important to restrict public access to sensitive services to enhance security.

Recommendation:

Restrict public access to your Cloud Run services to enhance security and prevent unauthorized access.

1. Bucket policies with admin permissions (Priority: High)

Baseline:

Checks the IAM policies of your GCP storage buckets for policies that grant admin permissions.

Description:

Granting admin permissions to storage buckets can lead to unauthorized access and potential data breaches.

Recommendation:

Restrict admin permissions to only those users who absolutely need it.

2. Publicly accessible buckets (Priority: High)

Baseline:

Checks the access policies of your GCP storage buckets for public accessibility.

Description:

Publicly accessible storage buckets can expose sensitive data to unauthorized users.

Recommendation:

Restrict public access to storage buckets and ensure that only authorized users have access.

3. Enable object encryption with CMEKs (Priority: High)

Baseline:

Checks the encryption settings of your GCP storage buckets for object encryption with customer-managed encryption keys (CMEKs).

Description:

Enabling object encryption with CMEKs provides an additional layer of security for your data.

Recommendation:

Enable object encryption with CMEKs for all storage buckets to enhance data security.

4. Enable usage and logs (Priority: Moderate)

Baseline:

Checks the logging settings of your GCP storage buckets for usage and storage logs.

Description:

Enabling usage and storage logs helps monitor access and usage patterns, providing insights for security and optimization.

Recommendation:

Enable usage and storage logs for all storage buckets to monitor and analyze access and usage patterns.

5. Enable uniform access (Priority: High)

Baseline:

Checks the uniform bucket-level access settings of your GCP storage buckets.

Description:

Uniform bucket-level access simplifies permissions management by applying IAM policies uniformly across all objects in a bucket.

Recommendation:

Enable uniform bucket-level access to simplify permissions management and enhance security.

6. Configure CORS (Priority: Low)

Baseline:

Checks the cross-origin resource sharing (CORS) configurations of your GCP storage buckets.

Description:

CORS configurations allow your storage buckets to handle cross-origin requests, which can be necessary for web applications.

Recommendation:

Configure CORS settings appropriately to enable cross-origin requests while maintaining security.

1. Enable encryption with CMEKs (Priority: High)

Baseline:

Checks Pub/Sub topics to ensure they are encrypted using customer-managed encryption keys (CMEKs) via Cloud KMS.

Description:

Cloud Pub/Sub topics use Google-managed keys by default. For greater control over data encryption and compliance, configure topics to use CMEKs through Cloud KMS.

Recommendation:

Configure your Cloud Pub/Sub topics to use CMEKs via Cloud KMS to enhance data security and key management.

2. Publicly accessible topics (Priority: High)

Baseline:

Checks the IAM policies of your Cloud Pub/Sub topics to identify topics with public access.

Description:

Allowing public access to Cloud Pub/Sub topics may expose sensitive data and permit unauthorized publishing or subscribing. This configuration could introduce significant security risks.

Recommendation:

Restrict access to your Cloud Pub/Sub topics by ensuring that only authorized principals have permissions and removing any public access.

1. DNSSEC disabled (Priority: Medium)

Baseline:

Checks whether the DNSSEC is disabled for Cloud DNS managed zones.

Description:

DNSSEC adds security to the Domain Name System (DNS) protocol by enabling DNS responses to be validated. It ensures that web traffic is routed to the correct servers, protecting against DNS spoofing and cache poisoning attacks.

Recommendation:

Enable DNSSEC for your Cloud DNS zones to enhance DNS security and protect against DNS spoofing and other attacks.

2. Key signing algorithm (Priority: Medium)

Baseline:

Checks whether deprecated algorithms are used for key signing in Cloud DNS managed zones.

Description:

The key signing algorithm is crucial for DNSSEC security. Using deprecated algorithms like RSASHA1 could compromise the security of your DNS infrastructure as they are considered less secure against modern cryptographic attacks.

Recommendation:

Update your key signing algorithm to use more secure algorithms such as RSASHA256 or RSA-SHA512 instead of deprecated ones like RSASHA1.

3. Zone signing algorithm (Priority: Medium)

Baseline:

Checks whether deprecated algorithms are used for zone signing in Cloud DNS managed zones.

Description:

The zone signing algorithm is essential for DNSSEC security. Using deprecated algorithms like RSASHA1 could weaken the security posture of your DNS zones against cryptographic attacks.

Recommendation:

Update your zone signing algorithm to use more secure algorithms such as RSASHA256 or RSASHA512 instead of deprecated ones like RSASHA1.

1.Service account admin access (Priority: Medium)

Baseline:

Checks for principals with the roles/iam.serviceAccountUser or roles/iam.serviceAccountTokenCreator roles.

Description:

The Service Account User and Token Creator roles grant principals the ability to impersonate service accounts and create OAuth tokens. These powerful permissions could enable privilege escalation if assigned inappropriately.

Recommendation:

Limit these roles to only trusted principals who absolutely require the ability to act as service accounts. Review assignments regularly and implement the principle of least privilege.

2. Essential contacts (Priority: Medium)

Baseline:

Checks if essential contacts are configured for notifications about operations, security, and billing.

Description:

Essential contacts ensure that critical notifications reach the appropriate teams. Without proper configuration, important alerts about security issues, billing problems, or operational incidents may go unnoticed.

Recommendation:

Configure essential contacts for your project to ensure that notifications are routed to the appropriate people or teams responsible for different aspects of your GCP resources.

3. Audit logging (Priority: Medium)

Baseline:

Checks if all three audit log types (Admin Activity, Data Access, and System Event) are enabled.

Description:

Comprehensive audit logging is essential for security monitoring, incident response, and compliance. Without proper audit logs, it becomes difficult to investigate security incidents or provide evidence for compliance audits.

Recommendation:

Enable all three types of audit logs (Admin Activity, Data Access, and System Event) for all services to maintain a complete audit trail of activities within your GCP environment.

4. Corporate credentials (Priority: Medium)

Baseline:

Checks if consumer email domains (gmail.com, yahoo.com, hotmail.com, or outlook.com) are used for access to GCP resources.

Description:

Using personal email accounts for cloud resource access creates security and management challenges. These accounts lack centralized control, complicate offboarding processes, and may not meet organizational security policies.

Recommendation:

Use corporate email accounts or a federated identity with your organization's identity provider instead of personal email accounts for accessing GCP resources.

5. Access approval (Priority: High)

Baseline:

Checks if Access Approval is configured for the project.

Description:

Access Approval allows you to approve access to your data or configurations explicitly by Google personnel. Without Access Approval, Google staff might access your content during troubleshooting or support activities without your explicit approval.

Recommendation:

Enable Access Approval for your project to maintain control over when Google personnel can access your content, particularly for sensitive workloads or regulated environments.

6. Key Management Service role separation (Priority: Medium)

Baseline:

Checks if any principals have been assigned to both KMS Admin and KMS CryptoKey roles.

Description:

Separation of duties is a security principle that prevents a single individual from controlling an entire process. When a principal has both Key Management Service (KMS) admin and crypto operation roles, they can create keys and use them, bypassing security checks and balances.

Recommendation:

Implement separation of duties by ensuring that different principals are responsible for KMS administration and cryptographic operations. This enhances security through mutual oversight.

7. Primitive roles (Priority: Medium)

Baseline:

Checks if principals are assigned primitive roles (roles/owner, roles/editor, roles/viewer).

Description:

Primitive roles provide broad permissions that violate the principle of least privilege. They grant access to all resources within a project rather than to specific services or actions, increasing the risk of accidental or malicious misuse.

Recommendation:

Replace primitive roles with predefined or custom roles that grant only the permissions required for specific tasks. This reduces the risk surface and improves security posture.

8. Service account admin roles (Priority: Medium)

Baseline:

Checks if service accounts have been granted administrative or privileged roles.

Description:

Service accounts with administrative roles can perform privileged operations, potentially enabling privilege escalation if the service account is compromised. Service accounts should follow the principle of least privilege.

Recommendation:

Review service accounts with admin roles and reduce permissions to only those necessary for their function. Consider using a workload identity for GKE or managed identities for compute resources instead of service account keys.

9. Service account key rotation (Priority: Low)

Baseline:

Checks if service account keys are older than 90 days.

Description:

Regular rotation of service account keys limits the window of opportunity for attackers if a key is compromised. Long-lived keys present a security risk, especially if they have been downloaded or shared.

Recommendation:

Implement a key rotation policy for service account keys and rotate them at least every 90 days. Consider using alternative authentication methods, like workload identity federation, when possible.

10. Service account managed keys (Priority: Medium)

Baseline:

Checks if user-managed keys exist for internal Google Cloud service accounts.

Description:

User-managed keys for internal service accounts (like those ending with iam.gserviceaccount.com) create unnecessary security risks. These internal service accounts are meant to be managed by Google Cloud services, and manual key management introduces potential misconfigurations.

Recommendation:

Avoid creating user-managed keys for internal service accounts. Use alternative authentication methods appropriate for the service, such as workload identity federation, impersonation, or attached service accounts.

11. BigQuery admin (Priority: Medium)

Baseline:

Checks for principals with BigQuery admin, dataEditor, or dataOwner roles.

Description:

BigQuery administrative roles grant extensive permissions to manage datasets, tables, and query data. These powerful roles should be limited to a small number of trusted administrators to prevent unauthorized data access or modification.

Recommendation:

Limit the number of principals with BigQuery admin roles. Consider using more granular roles like bigquery.dataViewer or custom roles with only the necessary permissions for specific tasks.

12. Pub/Sub admin (Priority: Medium)

Baseline:

Checks for principals with the roles/pubsub.admin role.

Description:

The Pub/Sub admin role grants full control over topics and subscriptions, including the ability to create, modify, delete, and manage access to these resources. Excessive admins increase the risk of unauthorized changes to message delivery systems.

Recommendation:

Limit the number of principals with Pub/Sub admin roles. Use more specific roles, like pubsub.publisher or pubsub.subscriber, for accounts that only need to publish or consume messages.

13. Bigtable admin (Priority: Medium)

Baseline:

Checks for principals with the roles/bigtable.admin role.

Description:

The Bigtable admin role grants full control over Bigtable instances, including the ability to create, modify, and delete instances and tables as well as manage access controls. Excessive admin privileges increase the risk of data loss or unauthorized access.

Recommendation:

Limit the number of principals with Bigtable admin roles. Consider using more specific roles, like bigtable.reader or bigtable.user, for accounts that only need read or read/write access to data.

1. Default network in use (Priority: Medium)

Baseline:

Checks if the default network is being used in your VPC configuration.

Description:

A default network is automatically created for each project with predefined settings that may not align with security best practices. It includes default firewall rules that allow ingress traffic on common ports and create subnets in each region with predetermined IP ranges.

Recommendation:

Create custom VPC networks with properly defined subnets and firewall rules instead of using the default network. Consider deleting the default network if not needed to reduce the attack surface.

2. Legacy network in use (Priority: Medium)

Baseline:

Checks if the legacy network routing mode is being used in your VPC configuration.

Description:

Legacy network mode uses an older routing configuration that lacks the advanced features and security controls available in more current VPC implementations. Legacy networks are single global networks with automatically generated IPv4 prefixes for all regions.

Recommendation:

Migrate from legacy networks to VPC networks with regional subnets to take advantage of improved routing capabilities, better security controls, and more flexible IP address management.

3. Unrestricted DNS access (Priority: High)

Baseline:

Checks for firewall rules that allow unrestricted access to DNS ports (TCP/UDP port 53).

Description:

Firewall rules that allow unrestricted DNS access from the internet can be exploited for DNS amplification attacks, data exfiltration, or DNS tunneling. Such open access provides potential pathways for attackers to query internal DNS information or leverage the DNS for command and control communications.

Recommendation:

Restrict DNS access to specific IP ranges or internal networks. If external DNS access is required, implement strict filtering and monitoring to detect and prevent abuse.

4. Unrestricted FTP access (Priority: High)

Baseline:

Checks for firewall rules that allow unrestricted access to FTP ports (TCP ports 20 and 21).

Description:

Unrestricted FTP access from the internet poses significant security risks because FTP transmits credentials and data in plaintext. This can lead to credential theft, unauthorized data access, and potential data breaches. FTP also lacks modern authentication and encryption capabilities.

Recommendation:

Restrict FTP access to specific trusted IP ranges or migrate to more secure file transfer protocols, like SFTP or FTPS. Consider implementing a VPN for secure access to file transfer services.

5. Unrestricted ICMP access (Priority: High)

Baseline:

Checks for firewall rules that allow unrestricted ICMP traffic from the internet.

Description:

Allowing unrestricted ICMP traffic can expose your network to reconnaissance techniques, potential denial-of-service attacks, and ICMP tunneling. While ICMP has legitimate uses for network diagnostics, unrestricted access from the internet is generally unnecessary and increases security risk.

Recommendation:

Restrict ICMP traffic to specific trusted IP ranges or internal networks. If external ICMP access is required for specific purposes, implement strict filtering to allow only necessary ICMP types and codes.

6. Unrestricted MySQL access (Priority: High)

Baseline:

Checks for firewall rules that allow unrestricted access to MySQL ports (TCP port 3306).

Description:

Exposing MySQL database ports directly to the internet creates significant security risks, including brute-force attacks, exploitation of vulnerabilities, and unauthorized data access. Database services should typically be accessible only from authorized application servers or through secure channels.

Recommendation:

Restrict MySQL access to specific application servers or internal networks. Use Cloud SQL proxy, private connectivity, or a VPN for external access requirements. Implement strong authentication and encryption for all database connections.

7. Unrestricted Oracle access (Priority: High)

Baseline:

Checks for firewall rules that allow unrestricted access to Oracle database ports (TCP port 1521).

Description:

Exposing Oracle database ports directly to the internet creates significant security risks, including brute-force attacks, exploitation of vulnerabilities, and unauthorized data access. Database services should typically be accessible only from authorized application servers or through secure channels.

Recommendation:

Restrict Oracle database access to specific application servers or internal networks. Use private connectivity or a VPN for external access requirements. Implement strong authentication and encryption for all database connections.

8. Unrestricted uncommon ports (Priority: High)

Baseline:

Checks for firewall rules that allow unrestricted access to uncommon or non-standard ports from the internet.

Description:

Firewall rules allowing access to uncommon ports from the internet could indicate services running on non-standard ports, potential backdoors, or security evasion techniques. These ports might be used for running unauthorized services or providing alternative access to legitimate services.

Recommendation:

Review and restrict access to any uncommon ports. Follow the principle of least privilege by allowing access only to necessary services from specific trusted sources. Standardize service port usage and document any legitimate use of non-standard ports.

9. Unrestricted outbound access (Priority: High)

Baseline:

Checks for firewall rules that allow unrestricted outbound access to the internet.

Description:

Allowing unrestricted outbound access from your VPC can enable data exfiltration and command and control communication from compromised instances. While outbound access is typically less restricted than inbound access, allowing any instance to connect to any destination increases your security risk.

Recommendation:

Restrict outbound traffic to only required destinations and ports. Implement egress filtering to control what traffic can leave your VPC networks and limit the potential for data exfiltration.

10. Unrestricted PostgreSQL access (Priority: High)

Baseline:

Checks for firewall rules that allow unrestricted access to PostgreSQL ports (TCP port 5432).

Description:

Exposing PostgreSQL database ports directly to the internet creates significant security risks, including brute-force attacks, exploitation of vulnerabilities, and unauthorized data access. Database services should typically be accessible only from authorized application servers or through secure channels.

Recommendation:

Restrict PostgreSQL access to specific application servers or internal networks. Use Cloud SQL proxy, private connectivity, or VPN for external access requirements. Implement strong authentication and encryption for all database connections.

11. Unrestricted SSH access (Priority: High)

Baseline:

Checks for firewall rules that allow unrestricted SSH access (TCP port 22) from the internet.

Description:

Allowing unrestricted SSH access from the internet exposes your instances to brute-force attacks and unauthorized access attempts. SSH is a common target for automated scanning and exploitation due to its role in providing administrative access to systems.

Recommendation:

Restrict SSH access to specific trusted IP ranges or use more secure access methods like Identity-Aware Proxy (IAP) or bastion hosts. Consider implementing additional security controls like multi-factor authentication for SSH access.

12. Unrestricted RDP access (Priority: High)

Baseline:

Checks for firewall rules that allow unrestricted Remote Desktop Protocol (RDP) access (TCP port 3389) from the internet.

Description:

Allowing unrestricted RDP access from the internet exposes your Windows instances to brute-force attacks and exploitation attempts. RDP is a common target for threat actors seeking to gain unauthorized access to Windows systems.

Recommendation:

Restrict RDP access to specific trusted IP ranges or use more secure access methods like IAP or bastion hosts. Consider implementing additional security controls like multi-factor authentication for RDP access.

13. Unrestricted RPC access (Priority: High)

Baseline:

Checks for firewall rules that allow unrestricted access to Remote Procedure Call (RPC) ports (TCP ports 135, 137-139, 445) from the internet.

Description:

Allowing unrestricted access to RPC and related SMB/CIFS ports creates significant security risks. These protocols are commonly targeted in network attacks and have historically been associated with many critical vulnerabilities. Exposing these ports to the internet can lead to unauthorized access, data breaches, and system compromise.

Recommendation:

Block or strictly limit access to RPC and SMB/CIFS ports (135, 137-139, 445) from the internet. If these services are required for specific use cases, restrict access to trusted networks and implement additional security controls like VPN or private connectivity.

14. Unrestricted SMTP access (Priority: High)

Baseline:

Checks for firewall rules that allow unrestricted access to SMTP ports (TCP ports 25, 465, 587).

Description:

Unrestricted SMTP access from the internet increases the risk of mail server exploitation, including spam relay, email spoofing, and other mail-related attacks. Open SMTP ports can be used by attackers for malicious email campaigns or to compromise mail services.

Recommendation:

Restrict SMTP access to specific trusted IP ranges or restrict inbound SMTP traffic to authorized mail relay servers. Implement email security controls such as Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) to protect against email-based attacks.

15. Unrestricted SQL Server access (Priority: High)

Baseline:

Checks for firewall rules that allow unrestricted access to SQL Server ports (TCP ports 1433, 1434).

Description:

Exposing SQL Server database ports directly to the internet creates significant security risks, including brute-force attacks, exploitation of vulnerabilities, and unauthorized data access. Database services should typically be accessible only from authorized application servers or through secure channels.

Recommendation:

Restrict SQL Server access to specific application servers or internal networks. Use private connectivity or VPN for external access requirements. Implement strong authentication and encryption for all database connections.

16. Excessive port ranges (Priority: Medium)

Baseline:

Checks for firewall rules that define overly broad port ranges (more than 100 ports in a single rule).

Description:

Firewall rules with large port ranges violate the principle of least privilege by allowing access to more ports than necessary. This increases the attack surface and might expose unintended services or ports that could be exploited by attackers.

Recommendation:

Restrict firewall rules to only the specific ports required for your applications. Break down large port ranges into smaller, more specific rules that precisely define the required access. Regularly review and audit firewall rules to ensure they remain as restrictive as possible.

17. DNS logging not enabled (Priority: Medium)

Baseline:

Checks if DNS logging is enabled for VPC networks.

Description:

DNS logging provides valuable visibility into DNS queries within your VPC, which can help identify potential security threats, malware communication, data exfiltration attempts, and policy violations. Without DNS logging, you lose critical security telemetry that could help detect and investigate security incidents.

Recommendation:

Enable DNS logging for all VPC networks to capture DNS queries for security monitoring and threat detection. Configure logs to be sent to appropriate logging and monitoring systems for analysis.

18. Firewall rule logging is not enabled (Priority: Medium)

Baseline:

Checks if logging is enabled for firewall rules.

Description:

Firewall rule logging provides visibility into network traffic patterns, including blocked and allowed connections. This information is crucial for security monitoring, troubleshooting, and forensic investigations. Without firewall logging, it becomes difficult to detect and investigate potential security breaches or network issues.

Recommendation:

Enable logging for all firewall rules, especially those that control access to sensitive systems or services. Configure logs to be sent to appropriate logging and monitoring systems for analysis.

19. Flow logs are not enabled (Priority: Medium)

Baseline:

Checks if VPC Flow Logs are enabled for VPC subnets.

Description:

VPC Flow Logs record information about the IP traffic going to and from network interfaces in your VPC. This data is essential for network monitoring, forensic analysis, and security investigations. Without flow logs, you lack visibility into network traffic patterns that could indicate security issues or performance problems.

Recommendation:

Enable VPC Flow Logs for all subnets to capture detailed network traffic metadata. Configure appropriate log retention periods and integrate with security monitoring systems. Consider sampling settings to balance visibility with cost if necessary.

1. Security policy not configured (Priority: Medium)

Baseline:

Checks if Google Cloud Armor security policies are configured for load balancers.

Description:

Google Cloud Armor security policies provide protection against distributed denial-of-service (DDoS) attacks and application-layer attacks such as cross-site scripting (XSS) and SQL injection. Without security policies, your applications are more vulnerable to these common attack vectors, potentially leading to service disruptions or data breaches.

Recommendation:

Configure Google Cloud Armor security policies for your load balancers to protect against common web attacks and DDoS threats. Implement appropriate predefined rules, create custom rules based on your application's security requirements, and configure rate limiting to mitigate potential attacks.

2. Logging is not enabled (Priority: High)

Baseline:

Checks if logging is enabled for Google Cloud load balancers.

Description:

Load balancer logs provide valuable information about request patterns, client IP addresses, response status codes, and latency metrics. Without logging, you lose visibility into traffic patterns, making it difficult to troubleshoot issues, detect security incidents, or optimize performance.

Recommendation:

Enable logging for all load balancers to capture request and response data. Configure appropriate sample rates to balance visibility with cost if necessary. Integrate logs with monitoring and security tools to gain insights into traffic patterns and potential security issues.

3. HTTPS is not enabled (Priority: High)

Baseline:

Checks if load balancers are configured to use HTTPS rather than unencrypted HTTP.

Description:

Using unencrypted HTTP for load balancers exposes traffic to potential eavesdropping, data tampering, and manipulator-in-the-middle attacks. Without HTTPS encryption, sensitive information such as authentication credentials, session tokens, or personal data might be transmitted in clear text across the network.

Recommendation:

Configure load balancers to use HTTPS instead of HTTP to encrypt traffic between clients and your applications. Implement SSL certificates from a trusted certificate authority or use Google-managed certificates. Consider implementing HTTP-to-HTTPS redirection to ensure all traffic is encrypted and configure appropriate SSL/TLS protocol versions and cipher suites.

1. Dataflow - Deprecated SDK (Priority: Medium)

Baseline:

Checks if Dataflow jobs are using SDK versions that have been marked as deprecated.

Description:

Using deprecated SDK versions for Dataflow jobs might lead to compatibility issues, reduced functionality, and eventual failure as support is discontinued.

Recommendation:

Update Dataflow jobs to use the latest supported SDK version to ensure continued functionality, security, and access to new features.