Remediating Security Health Analytics findings

This page provides a list of reference guides and techniques for remediating Security Health Analytics findings using Security Command Center.

You need adequate Identity and Access Management (IAM) roles to view or edit findings, and to access or modify Google Cloud resources. If you encounter access errors in the Security Command Center dashboard, ask your administrator for assistance and, to learn about roles, see Access control. To resolve resource errors, read documentation for affected products.

Security Health Analytics remediation

This section includes remediation instructions for all Security Health Analytics findings.

ADMIN_SERVICE_ACCOUNT

A service account in your organization has Admin, Owner, or Editor privileges assigned to it. These roles have broad permissions and shouldn't be assigned to service accounts. To learn about service accounts and the roles available to them, see Service accounts.

Complete the following steps to remediate this finding:

  1. Go to the IAM policy page.
    Go to IAM policy
  2. For each principal identified in the finding:
    1. Click Edit next to the principal.
    2. To remove permissions, click Delete next to the offending role.
    3. Click Save.

Learn about this finding type's supported assets and scan settings.

API_KEY_APIS_UNRESTRICTED

There are API keys being used too broadly.

Unrestricted API keys are insecure because they can be retrieved from devices on which the key is stored or can be seen publicly, for instance, from within a browser. In accordance with the principle of least privilege, configure API keys to only call APIs required by the application. For more information, see Using API keys.

Complete the following steps to remediate this finding:

  1. Go to the API keys page.
    Go to API keys
  2. For each API key:
    1. Click Edit .
    2. Under API restrictions, click Restrict key.
    3. On the Select APIs drop-down list, select which APIs to allow.
    4. Click Save. It might take up to five minutes for settings to take effect.

Learn about this finding type's supported assets and scan settings.

API_KEY_APPS_UNRESTRICTED

There are API keys being used in an unrestricted way, allowing use by any untrusted app.

Unrestricted API keys are insecure because they can be retrieved on devices on which the key is stored or can be seen publicly, for instance, from within a browser. In accordance with the principle of least privilege, restrict API key usage to trusted hosts, HTTP referrers, and apps. For more information, see Adding application restrictions.

Complete the following steps to remediate this finding:

  1. Go to the API keys page.
    Go API keys
  2. For each API key:
    1. Click Edit .
    2. Under Application restrictions, select a restriction category. You can set one application restriction per key.
    3. Click Add an item to add restrictions based on the needs of your application.
    4. Once finished adding items, click Done.
    5. Click Save.

Learn about this finding type's supported assets and scan settings.

API_KEY_EXISTS

A project is using API keys instead of standard authentication.

API keys are insecure because they are simple encrypted strings and easy for others to discover and use. They can be retrieved on devices on which the key is stored or can be seen publicly, for instance, from within a browser. Also, API keys do not uniquely identify users or applications making requests. Use a standard authentication flow instead. For more information, see Authenticating as an end user.

Complete the following steps to remediate this finding:

  1. Ensure your applications are configured with an alternate form of authentication.
  2. Go to the API credentials page.
    Go to API credentials
  3. In the API keys section, click Delete next to every API key.

Learn about this finding type's supported assets and scan settings.

API_KEY_NOT_ROTATED

An API key hasn't been rotated for more than 90 days.

API keys do not expire, so if one is stolen, it might be used indefinitely unless the project owner revokes or rotates the key. Regenerating API keys frequently reduces the amount of time that a stolen API key can be used to access data on a compromised or terminated account. Rotate API keys at least every 90 days. For more information, see Securing an API key.

Complete the following steps to remediate this finding:

  1. Go to the API keys page.
    Go to API keys
  2. For each API key:
    1. Check the date under Creation date.
    2. If the key is over 90 days old, click the name of the key or Edit .
    3. At the top of the page, click the Regenerate key.
    4. Click Replace Key.
    5. To ensure your applications continue working uninterrupted, update them to use the new API key. The old API key works for 24 hours before it is permanently deactivated.

Learn about this finding type's supported assets and scan settings.

AUDIT_CONFIG_NOT_MONITORED

Log metrics and alerts aren't configured to monitor audit configuration changes.

Cloud Logging produces Admin Activity and Data Access logs that enable security analysis, resource change tracking, and compliance auditing. By monitoring audit configuration changes, you ensure that all activities in your project can be audited at any time. For more information, see Overview of logs- based metrics.

Depending on the quantity of information, Cloud Monitoring costs can be significant. To understand your usage of the service and its costs, see Cost optimization for Google Cloud's operations suite.

To remediate this finding, create metrics, if necessary, and alert policies:

Create metric

  1. Go to the Logs-based Metrics page.
    Go to Logs-based Metrics
  2. Click Create Metric.
  3. Under Metric Type, select Counter.
  4. Under Details:
    1. Set a Log metric name.
    2. Add a description.
    3. Set Units to 1.
  5. Under Filter selection, copy and paste the following text into the Build filter box, replacing existing text, if necessary:
      protoPayload.methodName="SetIamPolicy"
      AND protoPayload.serviceData.policyDelta.auditConfigDeltas:*
    
  6. Click Create Metric. You see a confirmation.

Create Alert Policy

  1. Go to the Logs-based Metrics page.
    Go to Logs-based Metrics
  2. Under the User-defined metrics section, select the metric you created in the previous section.
  3. Click More , and then click Create alert from metric. If you are asked to add your project to a workspace, complete that process.
  4. On the page that opens, in the navigation menu, click Alerting.
  5. Under What do you want to track?, click Add Condition and complete the dialog to define what resources are monitored and when alerts are triggered. For information on the fields in a condition, see Specifying conditions.
  6. When done, click Add, and then click Next.
  7. Under Who should be notified?, click the Notification Channels drop-down and select how you would like to be notified. For more information, see Managing notification channels.
  8. Click OK, and then click Next.
  9. Under What are the steps to fix the issue?, set an Alert name.
  10. Click Save.

Learn about this finding type's supported assets and scan settings.

AUDIT_LOGGING_DISABLED

Audit logging has been disabled for this resource.

Enable Cloud Logging for all services to track all admin activities, read access, and write access to user data. Depending on the quantity of information, Cloud Logging costs can be significant. To understand your usage of the service and its cost, see Cost optimization for Google Cloud's operations suite.

Complete the following steps to remediate this finding:

  1. Go to the Default audit configuration page.
    Go to Default audit configuration
  2. Under the Log Type tab, select Admin Read, Data Read, and Data Write.
  3. Click Save.
  4. Under the Exempted Users tab, remove all listed users by clicking Delete next to each name.
  5. Click Save.

Learn about this finding type's supported assets and scan settings.

AUTO_BACKUP_DISABLED

A Cloud SQL database doesn't have automatic backups enabled.

To prevent data loss, turn on automated backups for your SQL instances. For more information, see Creating and managing on-demand and automatic backups.

Complete the following steps to remediate this finding:

  1. Go to the SQL instance backups page.
    Go to SQL instance backups
  2. Next to Settings, click Edit .
  3. Select the box for Automate backups.
  4. In the drop-down menu, choose a window of time for your data to be automatically backed up.
  5. Click Save.

Learn about this finding type's supported assets and scan settings.

AUTO_REPAIR_DISABLED

A Google Kubernetes Engine (GKE) cluster's auto repair feature, which keeps nodes in a healthy, running state, is disabled.

When enabled, GKE makes periodic checks on the health state of each node in your cluster. If a node fails consecutive health checks over an extended time period, GKE initiates a repair process for that node. For more information, see Auto-repairing nodes.

Complete the following steps to remediate this finding:

  1. Go to the Kubernetes clusters page.
    Go to Kubernetes clusters

  2. Click the Nodes tab.

  3. For each node pool:

    1. Click the name of the node pool to go to its detail page.
    2. Click Edit .
    3. Under Management, select Enable auto-repair.
    4. Click Save.

Learn about this finding type's supported assets and scan settings.

AUTO_UPGRADE_DISABLED

A GKE cluster's auto upgrade feature, which keeps clusters and node pools on the latest stable version of Kubernetes, is disabled.

For more information, see Auto-upgrading nodes.

Complete the following steps to remediate this finding:

  1. Go to the Kubernetes clusters page.
    Go to Kubernetes clusters
  2. In the list of clusters, click the name of the cluster.
  3. Click the Nodes tab.
  4. For each node pool:
    1. Click the name of the node pool to go to its detail page.
    2. Click Edit .
    3. Under Management, select Enable auto-upgrade.
    4. Click Save.

Learn about this finding type's supported assets and scan settings.

BUCKET_CMEK_DISABLED

A bucket is not encrypted with customer-managed encryption keys (CMEK).

Setting a default CMEK on a bucket gives you more control over access to your data. For more information, see Customer-managed encryption keys.

To remediate this finding, use CMEK with a bucket by following Using customer-managed encryption keys. CMEK incurs additional costs related to Cloud KMS.

Learn about this finding type's supported assets and scan settings.

BUCKET_IAM_NOT_MONITORED

Log metrics and alerts aren't configured to monitor Cloud Storage IAM permission changes.

Monitoring changes to Cloud Storage bucket permissions helps you identify over-privileged users or suspicious activity. For more information, see Overview of logs-based metrics.

Depending on the quantity of information, Cloud Monitoring costs can be significant. To understand your usage of the service and its costs, see Cost optimization for Google Cloud's operations suite.

Complete the following steps to remediate this finding:

Create metric

  1. Go to the Logs-based Metrics page.
    Go to Logs-based Metrics
  2. Click Create Metric.
  3. Under Metric Type, select Counter.
  4. Under Details:
    1. Set a Log metric name.
    2. Add a description.
    3. Set Units to 1.
  5. Under Filter selection, copy and paste the following text into the Build filter box, replacing existing text, if necessary:
      resource.type=gcs_bucket
      AND protoPayload.methodName="storage.setIamPermissions"
    
  6. Click Create Metric. You see a confirmation.

Create Alert Policy

  1. Go to the Logs-based Metrics page.
    Go to Logs-based Metrics
  2. Under User-defined metrics section, select the metric you created in the previous section.
  3. Click More , and then click Create alert from metric. If you are asked to add your project to a Workspace, complete that process.
  4. On the page that opens, in the navigation menu, click Alerting.
  5. Under What do you want to track?, click Add Condition and complete the dialog to define what resources are monitored and when alerts are triggered. For information on the fields in a condition, see Specifying conditions.
  6. When done, click Add, and then click Next.
  7. Under Who should be notified?, click the Notification Channels drop-down and select how you would like to be notified. For more information, see Managing notification channels.
  8. Click OK, and then click Next.
  9. Under What are the steps to fix the issue?, set an Alert name.
  10. Click Save.

Learn about this finding type's supported assets and scan settings.

BUCKET_LOGGING_DISABLED

There is a storage bucket without logging enabled.

To help investigate security issues and monitor storage consumption, enable access logs and storage information for your Cloud Storage buckets. Access logs provide information for all requests made on a specified bucket, and the storage logs provide information about the storage consumption of that bucket.

To remediate this finding, set up logging for the bucket indicated by the Security Health Analytics finding by completing the usage logs & storage logs guide.

Learn about this finding type's supported assets and scan settings.

BUCKET_POLICY_ONLY_DISABLED

Uniform bucket-level access, previously called Bucket Policy Only, isn't configured.

Uniform bucket-level access simplifies bucket access control by disabling object-level permissions (ACLs). When enabled, only bucket-level IAM permissions grant access to the bucket and the objects it contains. For more information, see Uniform bucket-level access.

Complete the following steps to remediate this finding:

  1. Go to the Cloud Storage browser page.
    Go to Cloud Storage browser
  2. In the list of buckets, click the name of the desired bucket.
  3. Click the Configuration tab.
  4. Under Permissions, in the row for Access control, click the edit icon ().
  5. In the dialog, select Uniform.
  6. Click Save.

Learn about this finding type's supported assets and scan settings.

CLUSTER_LOGGING_DISABLED

Logging isn't enabled for a GKE cluster.

To help investigate security issues and monitor usage, enable Cloud Logging on your clusters.

Depending on the quantity of information, Cloud Logging costs can be significant. To understand your usage of the service and its cost, see Cost optimization for Google Cloud's operations suite.

Complete the following steps to remediate this finding:

  1. Go to the Kubernetes clusters page in the Cloud Console.
    Go to Kubernetes clusters
  2. Select the cluster listed in the Security Health Analytics finding.
  3. Click Edit.

    If the cluster configuration recently changed, the edit button might be disabled. If you aren't able to edit the cluster settings, wait a few minutes and then try again.

  4. On the Legacy Stackdriver Logging or Stackdriver Kubernetes Engine Monitoring drop-down list, select Enabled.

    These options aren't compatible. Make sure that you use either Stackdriver Kubernetes Engine Monitoring alone, or Legacy Stackdriver Logging with Legacy Stackdriver Monitoring.

  5. Click Save.

Learn about this finding type's supported assets and scan settings.

CLUSTER_MONITORING_DISABLED

Monitoring is disabled on GKE clusters.

To help investigate security issues and monitor usage, enable Cloud Monitoring on your clusters.

Depending on the quantity of information, Cloud Monitoring costs can be significant. To understand your usage of the service and its costs, see Cost optimization for Google Cloud's operations suite.

Complete the following steps to remediate this finding:

  1. Go to the Kubernetes clusters page in the Cloud Console.
    Go to Kubernetes clusters
  2. Select the cluster listed in the Security Health Analytics finding.
  3. Click Edit.

    If the cluster configuration recently changed, the edit button might be disabled. If you aren't able to edit the cluster settings, wait a few minutes and then try again.

  4. On the Legacy Stackdriver Monitoring or Stackdriver Kubernetes Engine Monitoring drop-down list, select Enabled.

    These options aren't compatible. Make sure that you use either Stackdriver Kubernetes Engine Monitoring alone, or Legacy Stackdriver Monitoring with Legacy Stackdriver Logging.

  5. Click Save.

Learn about this finding type's supported assets and scan settings.

CLUSTER_PRIVATE_GOOGLE_ACCESS_DISABLED

Cluster hosts are not configured to use only private, internal IP addresses to access Google APIs.

Private Google Access enables virtual machine (VM) instances with only private, internal IP addresses to reach the public IP addresses of Google APIs and services. For more information, see Configuring Google Private Access.

Complete the following steps to remediate this finding:

  1. Go to the Virtual Private Cloud networks page
    Go to VPC networks
  2. In the list of networks, click the name of the desired network.
  3. On the VPC network details page, click the Subnets tab.
  4. In the list of subnets, click the name of the subnet associated with the Kubernetes cluster in the finding.
  5. On the Subnet details page, click Edit .
  6. Under Private Google Access, select On.
  7. Click Save.
  8. To remove public (external) IPs from VM instances whose only external traffic is to Google APIs, see Unassigning a static external IP address.

Learn about this finding type's supported assets and scan settings.

COMPUTE_PROJECT_WIDE_SSH_KEYS_ALLOWED

Project-wide SSH keys are used, allowing login to all instances in the project.

Using project-wide SSH keys makes SSH key management easier but, if compromised, poses a security risk which can impact all instances within a project. You should use instance-specific SSH keys, which limit the attack surface if SSH keys are compromised. For more information, see Managing SSH keys in metadata.

Complete the following steps to remediate this finding:

  1. Go to the VM instances page
    Go to VM instances
  2. In the list of instances, click the name of the instance in the finding.
  3. On the VM instance details page, click Edit.
  4. Under SSH Keys, select Block project-wide SSH keys.
  5. Click Save.

Learn about this finding type's supported assets and scan settings.

COMPUTE_SECURE_BOOT_DISABLED

A Shielded VM does not have Secure Boot enabled.

Using Secure Boot helps protect your virtual machines against rootkits and bootkits. Compute Engine does not enable Secure Boot by default because some unsigned drivers and low-level software are not compatible. If your VM does not use incompatible software and it boots with Secure Boot enabled, Google recommends using Secure Boot. If you are using third-party modules with Nvidia drivers, make sure they are compatible with Secure Boot before your enable it.

For more information, see Secure Boot.

Complete the following steps to remediate this finding:

  1. Go to the VM instances page in the Cloud Console.
    Go to VM instances
  2. In the list of instances, click the name of the instance in the finding.
  3. On the VM instance details page, click Stop.
  4. After the instance stops, click Edit.
  5. Under Shielded VM, select Turn on Secure Boot.
  6. Click Save.
  7. Click Start to start the instance.

Learn about this finding type's supported assets and scan settings.

COMPUTE_SERIAL_PORTS_ENABLED

Serial ports are enabled for an instance, allowing connections to the instance's serial console.

If you enable the interactive serial console on an instance, clients can attempt to connect to that instance from any IP address. Therefore, interactive serial console support should be disabled. For more information, see Enabling access for a project.

Complete the following steps to remediate this finding:

  1. Go to the VM instances page
    Go to VM instances
  2. In the list of instances, click the name of the instance in the finding.
  3. On the VM instance details page, click Edit.
  4. Under Remote access, clear Enable connecting to serial ports.
  5. Click Save.

Learn about this finding type's supported assets and scan settings.

COS_NOT_USED

Compute Engine VMs aren't using the Container-Optimized OS, which is designed to run Docker containers on Google Cloud securely.

Container-Optimized OS is Google's recommended OS for hosting and running containers on Google Cloud. Its small OS footprint minimizes security exposure, while automatic updates patch security vulnerabilities in a timely manner. For more information, see Container-Optimized OS Overview.

Complete the following steps to remediate this finding:

  1. Go to the Kubernetes clusters page.
    Go to Kubernetes clusters
  2. In the list of clusters, click the name of the cluster in the finding.
  3. Click the Nodes tab.
  4. For each node pool:
    1. Click the name of the node pool to go to its detail page.
    2. Click Edit .
    3. Under Nodes -> Image type, click Change.
    4. Select Container-Optimized OS, and then click Change.
    5. Click Save.

Learn about this finding type's supported assets and scan settings.

CUSTOM_ROLE_NOT_MONITORED

Log metrics and alerts aren't configured to monitor custom role changes.

IAM provides predefined and custom roles that grant access to specific Google Cloud resources. By monitoring role creation, deletion, and update activities, you can identify over-privileged roles at early stages. For more information, see Overview of logs-based metrics.

Depending on the quantity of information, Cloud Monitoring costs can be significant. To understand your usage of the service and its costs, see Cost optimization for Google Cloud's operations suite.

Complete the following steps to remediate this finding:

Create metric

  1. Go to the Logs-based Metrics page.
    Go to Logs-based Metrics
  2. Click Create Metric.
  3. Under Metric Type, select Counter.
  4. Under Details:
    1. Set a Log metric name.
    2. Add a description.
    3. Set Units to 1.
  5. Under Filter selection, copy and paste the following text into the Build filter box, replacing existing text, if necessary:
      resource.type="iam_role"
      AND protoPayload.methodName="google.iam.admin.v1.CreateRole"
      OR protoPayload.methodName="google.iam.admin.v1.DeleteRole"
      OR protoPayload.methodName="google.iam.admin.v1.UpdateRole"
    
  6. Click Create Metric. You see a confirmation.

Create Alert Policy

  1. Go to the Logs-based Metrics page.
    Go to Logs-based Metrics
  2. Under User-defined metrics section, select the metric you created in the previous section.
  3. Click More , and then click Create alert from metric. If you are asked to add your project to a Workspace, complete that process.
  4. On the page that opens, in the navigation menu, click Alerting.
  5. Under What do you want to track?, click Add Condition and complete the dialog to define what resources are monitored and when alerts are triggered. For information on the fields in a condition, see Specifying conditions.
  6. When done, click Add, and then click Next.
  7. Under Who should be notified?, click the Notification Channels drop-down and select how you would like to be notified. For more information, see Managing notification channels.
  8. Click OK, and then click Next.
  9. Under What are the steps to fix the issue?, set an Alert name.
  10. Click Save.

Learn about this finding type's supported assets and scan settings.

DATASET_CMEK_DISABLED

A BigQuery dataset is not configured to use a default customer-managed encryption key (CMEK).

With CMEK, keys that you create and manage in Cloud KMS wrap the keys that Google Cloud uses to encrypt your data, giving you more control over access to your data. For more information, see Protecting data with Cloud KMS keys.

Complete the following steps to remediate this finding:

You can't switch a table in place between default encryptions and CMEK encryption. To set a default CMEK key with which to encrypt all new tables in the dataset, follow the instructions to Set a dataset default key.

Setting a default key will not retroactively re-encrypt tables currently in the dataset with a new key. To use CMEK for existing data, do the following:

  1. Create a new dataset.
  2. Set a default CMEK key on the dataset you created.
  3. To copy tables to your CMEK-enabled dataset, follow the instructions for Copying a table.
  4. After copying data successfully, delete the original datasets.

Learn about this finding type's supported assets and scan settings.

DEFAULT_NETWORK

The default network exists in a project.

Default networks have automatically created firewall rules and network configurations which might not be secure. For more information, see Default network.

Complete the following steps to remediate this finding:

  1. Go to the VPC networks page in the Cloud Console.
    Go to VPC networks
  2. In the list of networks, click the name of the default network.
  3. In the VPC network details page, click Delete VPC Network.
  4. To create a new network with custom firewall rules, see Creating networks.

Learn about this finding type's supported assets and scan settings.

DEFAULT_SERVICE_ACCOUNT_USED

A Compute Engine instance is configured to use the default service account.

The default Compute Engine service account has the Editor role on the project, which allows read and write access to most Google Cloud services. To defend against privilege escalations and unauthorized access, don't use the default Compute Engine service account. Instead, create a new service account and assign only the permissions needed by your instance. Read Access control for information on roles and permissions.

Complete the following steps to remediate this finding:

  1. Go to the VM instances page in the Cloud Console.
    Go to VM instances
  2. Select the instance related to the Security Health Analytics finding.
  3. On the Instance details page that loads, click Stop.
  4. After the instance stops, click Edit.
  5. Under the Service Account section, select a service account other than the default Compute Engine service account. You might first need to create a new service account. Read Access control for information on IAM roles and permissions.
  6. Click Save. The new configuration appears on the Instance details page.

Learn about this finding type's supported assets and scan settings.

DISK_CMEK_DISABLED

Disks on this VM are not encrypted with customer-managed encryption keys (CMEK).

With CMEK, keys that you create and manage in Cloud KMS wrap the keys that Google Cloud uses to encrypt your data, giving you more control over access to your data. For more information, see Protecting Resources with Cloud KMS Keys.

Complete the following steps to remediate this finding:

  1. Go to the Compute Engine disks page in the Cloud Console.
    Go to Compute Engine disks
  2. In the list of disks, click the name of the disk indicated in the finding.
  3. On the Manage disk page, click Delete.
  4. To create a new disk with CMEK enabled, see Encrypt a new persistent disk with your own keys. CMEK incurs additional costs related to Cloud KMS.

Learn about this finding type's supported assets and scan settings.

DISK_CSEK_DISABLED

Disks on this VM are not encrypted with Customer-Supplied Encryption Keys (CSEK). Disks for critical VMs should be encrypted with CSEK.

If you provide your own encryption keys, Compute Engine uses your key to protect the Google-generated keys used to encrypt and decrypt your data. For more information, see Customer-Supplied Encryption Keys. CSEK incurs additional costs related to Cloud KMS.

Complete the following steps to remediate this finding:

Delete and create disk

You can only encrypt new persistent disks with your own key. You cannot encrypt existing persistent disks with your own key.

  1. Go to the Compute Engine disks page in the Cloud Console.
    Go to Compute Engine disks
  2. In the list of disks, click the name of the disk indicated in the finding.
  3. On the Manage disk page, click Delete.
  4. To create a new disk with CSEK enabled, see Encrypt disks with customer- supplied encryption keys.
  5. Complete the remaining steps to enable the detector.

Enable the detector

  1. Go to Security Command Center's Assets page in the Cloud Console.
    Go to Assets
  2. Next to View by, click Resource Type.
  3. In the list of resources, select Disk. The table populates with a list of your disks.
  4. Under resourceProperties.name, check the box next to the name of the disk you want to use with CSEK, and then click Set Security Marks.
  5. In the dialog, click Add Mark.
  6. In the key field, enter enforce_customer_supplied_disk_encryption_keys, and in the value field, enter true.
  7. Click Save.

Learn about this finding type's supported assets and scan settings.

DNSSEC_DISABLED

Domain Name System Security Extensions (DNSSEC) is disabled for Cloud DNS zones.

DNSSEC validates DNS responses and mitigates risks, such as DNS hijacking and person-in-the-middle attacks, by cryptographically signing DNS records. You should enable DNSSEC. For more information, see DNS Security Extensions (DNSSEC) overview.

Complete the following steps to remediate this finding:

  1. Go to the Cloud DNS page in the Cloud Console.
    Go to Cloud DNS networks
  2. Locate the row with the DNS zone indicated in the finding.
  3. Click the DNSSEC setting in the row and then, under DNSSEC, select On.
  4. Read the dialog that appears. If satisfied, click Enable.

Learn about this finding type's supported assets and scan settings.

EGRESS_DENY_RULE_NOT_SET

An egress deny rule is not set on a firewall.

A firewall that denies all egress network traffic prevents any unwanted outbound network connections, except those connections other firewalls explicitly authorize. For more information, see Egress cases.

Complete the following steps to remediate this finding:

  1. Go to the Firewall page in the Cloud Console.
    Go to Firewall
  2. Click Create Firewall Rule.
  3. Give the firewall a name and, optionally, a description.
  4. Under Direction of traffic, select Egress.
  5. Under Action on match, select Deny.
  6. In the Targets drop-down menu, select All instances in the network.
  7. In the Destination filter drop-down menu, select IP ranges, and then type 0.0.0.0/0 into the Destination IP ranges box.
  8. Under Protocols and ports, select Deny all.
  9. Click Disable Rule then, under Enforcement, select Enabled.
  10. Click Create.

Learn about this finding type's supported assets and scan settings.

FIREWALL_NOT_MONITORED

Log metrics and alerts aren't configured to monitor VPC Network Firewall rule changes.

Monitoring firewall rules creation and update events gives you insight into network access changes, and can help you quickly detect suspicious activity. For more information, see Overview of logs-based metrics.

Depending on the quantity of information, Cloud Monitoring costs can be significant. To understand your usage of the service and its costs, see Cost optimization for Google Cloud's operations suite.

Complete the following steps to remediate this finding:

Create metric

  1. Go to the Logs-based Metrics page.
    Go to Logs-based Metrics
  2. Click Create Metric.
  3. Under Metric Type, select Counter.
  4. Under Details:
    1. Set a Log metric name.
    2. Add a description.
    3. Set Units to 1.
  5. Under Filter selection, copy and paste the following text into the Build filter box, replacing existing text, if necessary:
      resource.type="gce_firewall_rule"
      AND protoPayload.methodName="compute.firewalls.patch"
      OR protoPayload.methodName="compute.firewalls.insert"
    
  6. Click Create Metric. You see a confirmation.

Create Alert Policy

  1. Go to the Logs-based Metrics page.
    Go to Logs-based Metrics
  2. Under User-defined metrics section, select the metric you created in the previous section.
  3. Click More , and then click Create alert from metric. If you are asked to add your project to a Workspace, complete that process.
  4. On the page that opens, in the navigation menu, click Alerting.
  5. Under What do you want to track?, click Add Condition and complete the dialog to define what resources are monitored and when alerts are triggered. For information on the fields in a condition, see Specifying conditions.
  6. When done, click Add, and then click Next.
  7. Under Who should be notified?, click the Notification Channels drop-down and select how you would like to be notified. For more information, see Managing notification channels.
  8. Click OK, and then click Next.
  9. Under What are the steps to fix the issue?, set an Alert name.
  10. Click Save.

Learn about this finding type's supported assets and scan settings.

FIREWALL_RULE_LOGGING_DISABLED

Firewall rules logging is disabled.

Firewall rules logging lets you audit, verify, and analyze the effects of your firewall rules. It can be useful for auditing network access or providing early warning that the network is being used in an unapproved manner. The cost of logs can be significant. For more information on Firewall Rules Logging and its cost, see Using Firewall Rules Logging.

Complete the following steps to remediate this finding:

  1. Go to the Firewall page in the Cloud Console.
    Go to Firewall
  2. In the list of firewall rules, click the name of the desired firewall rule.
  3. Click Edit.
  4. Under Logs, select On.
  5. Click Save.

Learn about this finding type's supported assets and scan settings.

FLOW_LOGS_DISABLED

There is a VPC subnetwork that has flow logs disabled.

VPC Flow Logs record a sample of network flows sent from and received by VM instances. These logs can be used for network monitoring, forensics, real-time security analysis, and expense optimization. For more information about flow logs and their cost, see Using VPC Flow Logs.

Complete the following steps to remediate this finding:

  1. Go to the VPC networks page.
    Go to VPC networks
  2. In the list of networks, click the name of the desired network.
  3. On the VPC network details page, click the Subnets tab.
  4. In the list of subnets, click the name of the subnet indicated in the finding.
  5. On the Subnet details page, click Edit.
  6. Under Flow logs, select On.

Learn about this finding type's supported assets and scan settings.

FULL_API_ACCESS

A Compute Engine instance is configured to use the default service account with full access to all Google Cloud APIs.

An instance configured with the default service account scope, Allow full access to all Cloud APIs, might allow users to perform operations or API calls for which they don't have IAM permissions. For more information, see Compute Engine default service account.

Complete the following steps to remediate this finding:

  1. Go to the VM instances page in the Cloud Console.
    Go to VM instances
  2. In the list of instances, click the name of the instance in the finding.
  3. Click Stop if the instance is currently started.
  4. After the instance stops, click Edit.
  5. Under Service account, in the drop-down menu, select Compute Engine default service account.
  6. Under Access scopes section, ensure that Allow full access to all Cloud APIs is not selected.
  7. Click Save.
  8. Click Start to start the instance.

Learn about this finding type's supported assets and scan settings.

HTTP_LOAD_BALANCER

A Compute Engine instance uses a load balancer that is configured to use a target HTTP proxy instead of a target HTTPS proxy.

To protect the integrity of your data and prevent intruders from tampering with your communications, configure your HTTP(S) load balancers to allow only HTTPS traffic. For more information, see External HTTP(S) Load Balancing overview.

Complete the following steps to remediate this finding:

  1. Go to the Target proxies page in the Cloud Console.
    Go to Target proxies
  2. In the list of target proxies, click the name of the target proxy in the finding.
  3. Click the link under the URL map.
  4. Click Edit.
  5. Click Frontend configuration.
  6. Delete all Frontend IP and port configurations that allow HTTP traffic and create new ones that allow HTTPS traffic.

Learn about this finding type's supported assets and scan settings.

IP_ALIAS_DISABLED

A GKE cluster was created with alias IP ranges disabled.

When you enable alias IP ranges, GKE clusters allocate IP addresses from a known CIDR block, so your cluster is scalable and interacts better with Google Cloud products and entities. For more information, see Alias IP ranges overview.

Complete the following steps to remediate this finding:

You currently cannot migrate an existing cluster to use alias IPs. To create a new cluster with alias IPs enabled, do the following:

  1. Go to the Kubernetes clusters page in the Cloud Console.
    Go to Kubernetes clusters
  2. Click Create.
  3. From the navigation pane, under Cluster, click Networking.
  4. Under Advanced networking options, select Enable VPC-native traffic routing (uses alias IP).
  5. Click Create.

Learn about this finding type's supported assets and scan settings.

IP_FORWARDING_ENABLED

IP forwarding is enabled on Compute Engine instances.

Prevent data loss or information disclosure by disabling IP forwarding of data packets for your VMs.

Complete the following steps to remediate this finding:

  1. Go to the VM instances page in the Cloud Console.
    Go to VM instances
  2. In the list of instances, check the box next to the name of the instance in the finding.
  3. Click Delete.
  4. Select Create Instance to create a new instance to replace the one you deleted.
  5. To ensure IP forwarding is disabled, click Management, disks, networking, SSH keys, and then click Networking.
  6. Under Network interfaces, click Edit.
  7. Under IP forwarding, in the drop-down menu, ensure that Off is selected.
  8. Specify any other instance parameters, and then click Create. For more information, see Creating and starting a VM instance.

Learn about this finding type's supported assets and scan settings.

KMS_KEY_NOT_ROTATED

Rotation isn't configured on a Cloud KMS encryption key.

Rotating your encryption keys regularly provides protection in case a key gets compromised and limits the number of encrypted messages available to cryptanalysis for a specific key version. For more information, see Key rotation.

Complete the following steps to remediate this finding:

  1. Go to the Cloud KMS keys page in the Cloud Console.
    Go to Cloud KMS keys
  2. Click the name of the key ring indicated in the finding.
  3. Click the name of the key indicated in the finding.
  4. Click Edit Rotation Period.
  5. Set the rotation period to a maximum of 90 days.
  6. Click Save.

Learn about this finding type's supported assets and scan settings.

KMS_PROJECT_HAS_OWNER

A user has roles/Owner permissions on a project that has cryptographic keys. For more information, see Permissions and roles.

Complete the following steps to remediate this finding:

  1. Go to the IAM page.
    Go IAM page
  2. If necessary, select the project in the finding.
  3. For each principal assigned the Owner role:
    1. Click Edit.
    2. In the Edit permissions panel, next to the Owner role, click Delete.
    3. Click Save.

Learn about this finding type's supported assets and scan settings.

KMS_PUBLIC_KEY

A Cloud KMS Cryptokey or Cloud KMS Key Ring is public and accessible to anyone on the internet. For more information, see Using IAM with Cloud KMS.

To remediate this finding, if it is related to a Cryptokey:

  1. Go to the Cryptographic Keys page in the Cloud Console.
    Cryptographic Keys
  2. Under Name, select the key ring that contains the cryptographic key related to the Security Health Analytics finding.
  3. On the Key ring details page that loads, select the checkbox next to the cryptographic key.
  4. If the INFO PANEL is not displayed, click the SHOW INFO PANEL button.
  5. Use the filter box preceding Role / Principal to search principals for allUsers and allAuthenticatedUsers, and click Delete to remove access for these principals.

To remediate this finding, if it is related to a Key Ring:

  1. Go to the Cryptographic Keys page in the Cloud Console.
    Cryptographic Keys
  2. Find the row with the key ring in the finding and select the checkbox.
  3. If the INFO PANEL is not displayed, click the SHOW INFO PANEL button.
  4. Use the filter box preceding Role / Principal to search principals for allUsers and allAuthenticatedUsers, and click Delete to remove access for these principals.

Learn about this finding type's supported assets and scan settings.

KMS_ROLE_SEPARATION

One or more principals have multiple Cloud KMS permissions assigned. It is recommended that no account simultaneously has Cloud KMS Admin along with other Cloud KMS permissions. For more information, see Permissions and roles.

Complete the following steps to remediate this finding:

  1. Go to the IAM page in the Cloud Console.
    Go to IAM
  2. For each principal listed in the finding, do the following:
    1. Check whether the role was inherited from a folder or organization resource by looking at the Inheritance column. If the column contains a link to a parent resource, click on the link to go to the parent resource's IAM page.
    2. Click Edit next to a principal.
    3. To remove permissions, click Delete next to Cloud KMS Admin. If you want to remove all permissions for the principal, click Delete next to all other permissions.
  3. Click Save.

Learn about this finding type's supported assets and scan settings.

LEGACY_AUTHORIZATION_ENABLED

Legacy Authorization is enabled on GKE clusters.

In Kubernetes, role-based access control (RBAC) lets you define roles with rules containing a set of permissions, and grant permissions at the cluster and namespace level. This feature provides better security by ensuring that users only have access to specific resources. Consider disabling legacy attribute-based access control (ABAC).

Complete the following steps to remediate this finding:

  1. Go to the Kubernetes clusters page in the Cloud Console.
    Go to Kubernetes clusters
  2. Select the cluster listed in the Security Health Analytics finding.
  3. Click Edit.

    If the cluster configuration recently changed, the edit button might be disabled. If you aren't able to edit the cluster settings, wait a few minutes and then try again.

  4. On the Legacy Authorization drop-down list, select Disabled.

  5. Click Save.

Learn about this finding type's supported assets and scan settings.

LEGACY_METADATA_ENABLED

Legacy metadata is enabled on GKE clusters.

Compute Engine's instance metadata server exposes legacy /0.1/ and /v1beta1/ endpoints, which do not enforce metadata query headers. This is a feature in the /v1/ APIs that makes it more difficult for a potential attacker to retrieve instance metadata. Unless required, we recommend you disable these legacy /0.1/ and /v1beta1/ APIs.

For more information, see Disabling and transitioning from legacy metadata APIs.

Complete the following steps to remediate this finding:

Currently, you can only disable legacy metadata APIs when creating a new cluster or when adding a new node pool to an existing cluster. To update an existing cluster to disable legacy metadata APIs, see Migrating workloads to different machine types.

Learn about this finding type's supported assets and scan settings.

LEGACY_NETWORK

A legacy network exists in a project.

Legacy networks are not recommended because many new Google Cloud security features are not supported in legacy networks. Instead, use VPC networks. For more information, see Legacy networks.

Complete the following steps to remediate this finding:

  1. Go to the VPC networks page in the Cloud Console.
    Go to VPC networks
  2. To create a new non-legacy network, click Create Network.
  3. Return to the VPC networks page.
  4. In the list of networks, click legacy_network.
  5. In the VPC network details page, click Delete VPC Network.

Learn about this finding type's supported assets and scan settings.

LOCKED_RETENTION_POLICY_NOT_SET

A locked retention policy is not set for logs.

A locked retention policy prevents logs from being overwritten and the log bucket from being deleted. For more information, see Retention policies and retention policy locks.

Complete the following steps to remediate this finding:

  1. Go to the Storage Browser page in the Cloud Console.
    Go to Storage Browser
  2. Select the bucket listed in the Security Health Analytics finding.
  3. On the Bucket details page, click the Retention tab.
  4. If a retention policy has not been set, click Set Retention Policy.
  5. Enter a retention period.
  6. Click Save. The retention policy is shown in the Retention tab.
  7. Click Lock to ensure the retention period is not shortened or removed.

Learn about this finding type's supported assets and scan settings.

LOG_NOT_EXPORTED

A resource doesn't have an appropriate log sink configured.

Cloud Logging helps you quickly find the root cause of issues in your system and applications. However, most logs are only retained for 30 days by default. Export copies of all log entries to extend the storage period. For more information, see Overview of log exports.

Complete the following steps to remediate this finding:

  1. Go to the Log Router page.
    Go to Log Router
  2. Click Create Sink.
  3. Fill out the necessary fields. Inclusion and exclusion filters let you choose which logs to export. To ensure that all logs are exported, leave the inclusion and exclusion filters empty.
  4. Click Create Sink.

Learn about this finding type's supported assets and scan settings.

MASTER_AUTHORIZED_NETWORKS_DISABLED

Control Plane Authorized Networks is not enabled on GKE clusters.

Control Plane Authorized Networks improves security for your container cluster by blocking specified IP addresses from accessing your cluster's control plane. For more information, see Adding authorized networks for control plane access.

Complete the following steps to remediate this finding:

  1. Go to the Kubernetes clusters page in the Cloud Console.
    Go to Kubernetes clusters
  2. Select the cluster listed in the Security Health Analytics finding.
  3. Click Edit.

    If the cluster configuration recently changed, the edit button might be disabled. If you aren't able to edit the cluster settings, wait a few minutes and then try again.

  4. On the Control Plane Authorized Networks drop-down list, select Enabled.

  5. Click Add authorized network.

  6. Specify the authorized networks you want to use.

  7. Click Save.

Learn about this finding type's supported assets and scan settings.

MFA_NOT_ENFORCED

Multi-factor authentication, specifically 2-Step Verification (2SV), is disabled for some users in your organization.

Multi-factor authentication is used to protect accounts from unauthorized access and is the most important tool for protecting your organization against compromised login credentials. For more information, see Protect your business with 2-Step Verification.

Complete the following steps to remediate this finding:

  1. Go to the Admin console page.

    Go to Admin console

  2. Enforce 2-Step Verification for all organizational units.

Use security marks

You can add dedicated security marks to assets so that detectors don't create security findings for those assets.

  • To prevent this finding from being activated again, add the security mark allow_mfa_not_enforced with a value of true to the asset.
  • To ignore potential violations for specific organizational units, add the excluded_orgunits security mark to the asset with a comma-separated list of organizational unit paths in the value field. For example, excluded_orgunits:/people/vendors/vendorA,/people/contractors/contractorA.

Learn about this finding type's supported assets and scan settings.

NETWORK_NOT_MONITORED

Log metrics and alerts aren't configured to monitor VPC network changes.

To detect incorrect or unauthorized changes to your network setup, monitor VPC network changes. For more information, see Overview of logs- based metrics.

Depending on the quantity of information, Cloud Monitoring costs can be significant. To understand your usage of the service and its costs, see Cost optimization for Google Cloud's operations suite.

Complete the following steps to remediate this finding:

Create metric

  1. Go to the Logs-based Metrics page.
    Go to Logs-based Metrics
  2. Click Create Metric.
  3. Under Metric Type, select Counter.
  4. Under Details:
    1. Set a Log metric name.
    2. Add a description.
    3. Set Units to 1.
  5. Under Filter selection, copy and paste the following text into the Build filter box, replacing existing text, if necessary:
      resource.type=gce_network AND protoPayload.methodName="compute.networks.insert"
      OR protoPayload.methodName="compute.networks.patch"
      OR protoPayload.methodName="compute.networks.delete"
      OR protoPayload.methodName="compute.networks.removePeering"
      OR protoPayload.methodName="compute.networks.addPeering"
    
  6. Click Create Metric. You see a confirmation.

Create Alert Policy

  1. Go to the Logs-based Metrics page.
    Go to Logs-based Metrics
  2. Under User-defined metrics section, select the metric you created in the previous section.
  3. Click More , and then click Create alert from metric. If you are asked to add your project to a Workspace, complete that process.
  4. On the page that opens, in the navigation menu, click Alerting.
  5. Under What do you want to track?, click Add Condition and complete the dialog to define what resources are monitored and when alerts are triggered. For information on the fields in a condition, see Specifying conditions.
  6. When done, click Add, and then click Next.
  7. Under Who should be notified?, click the Notification Channels drop-down and select how you would like to be notified. For more information, see Managing notification channels.
  8. Click OK, and then click Next.
  9. Under What are the steps to fix the issue?, set an Alert name.
  10. Click Save.

Learn about this finding type's supported assets and scan settings.

NETWORK_POLICY_DISABLED

Network policy is disabled on GKE clusters.

By default, pod to pod communication is open. Open communication allows pods to connect directly across nodes, with or without network address translation. A NetworkPolicy resource is like a pod-level firewall that restricts connections between pods, unless the NetworkPolicy resource explicitly allows the connection. Learn how to define a network policy.

Complete the following steps to remediate this finding:

  1. Go to the Kubernetes clusters page in the Cloud Console.
    Go to Kubernetes clusters
  2. Click the name of the cluster listed in the Security Health Analytics finding.
  3. Under Networking, in the row for Network policy, click Edit.

    If the cluster configuration recently changed, the edit button might be disabled. If you aren't able to edit the cluster settings, wait a few minutes and then try again.

  4. In the dialog, select Enable network policy for control plane and Enable network policy for nodes.

  5. Click Save Changes.

Learn about this finding type's supported assets and scan settings.

NODEPOOL_BOOT_CMEK_DISABLED

Boot disks in this node pool are not encrypted with customer-managed encryption keys (CMEK). CMEK allows the user to configure the default encryption keys for boot disks in a node pool.

Complete the following steps to remediate this finding:

  1. Go to the Kubernetes clusters page.
    Go to Kubernetes clusters
  2. In the list of clusters, click the name of the cluster in the finding.
  3. Click the Nodes tab.
  4. For each default-pool node pool, click Delete .
  5. To create new node pools using CMEK, see Using customer-managed encryption keys (CMEK). CMEK incurs additional costs related to Cloud KMS.

Learn about this finding type's supported assets and scan settings.

NON_ORG_IAM_MEMBER

A user outside of your organization has IAM permissions on a project or organization. Learn more about IAM permissions.

Complete the following steps to remediate this finding:

  1. Go to the IAM page in the Cloud Console.
    Go to IAM
  2. Select the checkbox next to users outside your organization.
  3. Click Remove.

Learn about this finding type's supported assets and scan settings.

OBJECT_VERSIONING_DISABLED

Object versioning isn't enabled on a storage bucket where sinks are configured.

To support the retrieval of objects that are deleted or overwritten, Cloud Storage offers the Object Versioning feature. Enable Object Versioning to protect your Cloud Storage data from being overwritten or accidentally deleted. Learn how to Enable Object Versioning.

To remediate this finding, use the gsutil versioning set on command with the appropriate value:

    gsutil versioning set on gs://finding.assetDisplayName

Replace finding.assetDisplayName with the name of the relevant bucket.

Learn about this finding type's supported assets and scan settings.

OPEN_CASSANDRA_PORT

Firewall rules that allow any IP address to connect to Cassandra ports might expose your Cassandra services to attackers. For more information, see VPC firewall rules overview.

The Cassandra service ports are:

  • TCP - 7000, 7001, 7199, 8888, 9042, 9160, 61620, 61621

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

Complete the following steps to remediate this finding:

  1. Go to the Firewall page in the Cloud Console.
    Go to Firewall
  2. In the list of firewall rules, click the name of the firewall rule in the finding.
  3. Click Edit.
  4. Under Source IP ranges, delete 0.0.0.0/0.
  5. Add specific IP addresses or IP ranges that you want to let connect to the instance.
  6. Add specific protocols and ports you want to open on your instance.
  7. Click Save.

Learn about this finding type's supported assets and scan settings.

OPEN_CISCOSECURE_WEBSM_PORT

Firewall rules that allow any IP address to connect to CiscoSecure/WebSM ports might expose your CiscoSecure/WebSM services to attackers. For more information, see VPC firewall rules overview.

The CiscoSecure/WebSM service ports are:

  • TCP - 9090

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

Complete the following steps to remediate this finding:

  1. Go to the Firewall page in the Cloud Console.
    Go to Firewall
  2. In the list of firewall rules, click the name of the firewall rule in the finding.
  3. Click Edit.
  4. Under Source IP ranges, delete 0.0.0.0/0.
  5. Add specific IP addresses or IP ranges that you want to let connect to the instance.
  6. Add specific protocols and ports you want to open on your instance.
  7. Click Save.

Learn about this finding type's supported assets and scan settings.

OPEN_DIRECTORY_SERVICES_PORT

Firewall rules that allow any IP address to connect to Directory ports might expose your Directory services to attackers. For more information, see VPC firewall rules overview.

The Directory service ports are:

  • TCP - 445
  • UDP - 445

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

Complete the following steps to remediate this finding:

  1. Go to the Firewall page in the Cloud Console.
    Go to Firewall
  2. In the list of firewall rules, click the name of the firewall rule in the finding.
  3. Click Edit.
  4. Under Source IP ranges, delete 0.0.0.0/0.
  5. Add specific IP addresses or IP ranges that you want to let connect to the instance.
  6. Add specific protocols and ports you want to open on your instance.
  7. Click Save.

Learn about this finding type's supported assets and scan settings.

OPEN_DNS_PORT

Firewall rules that allow any IP address to connect to DNS ports might expose your DNS services to attackers. For more information, see VPC firewall rules overview.

The DNS service ports are:

  • TCP - 53
  • UDP - 53

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

Complete the following steps to remediate this finding:

  1. Go to the Firewall page in the Cloud Console.
    Go to Firewall
  2. In the list of firewall rules, click the name of the firewall rule in the finding.
  3. Click Edit.
  4. Under Source IP ranges, delete 0.0.0.0/0.
  5. Add specific IP addresses or IP ranges that you want to let connect to the instance.
  6. Add specific protocols and ports you want to open on your instance.
  7. Click Save.

Learn about this finding type's supported assets and scan settings.

OPEN_ELASTICSEARCH_PORT

Firewall rules that allow any IP address to connect to Elasticsearch ports might expose your Elasticsearch services to attackers. For more information, see VPC firewall rules overview.

The Elasticsearch service ports are:

  • TCP - 9200, 9300

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

Complete the following steps to remediate this finding:

  1. Go to the Firewall page in the Cloud Console.
    Go to Firewall
  2. In the list of firewall rules, click the name of the firewall rule in the finding.
  3. Click Edit.
  4. Under Source IP ranges, delete 0.0.0.0/0.
  5. Add specific IP addresses or IP ranges that you want to let connect to the instance.
  6. Add specific protocols and ports you want to open on your instance.
  7. Click Save.

Learn about this finding type's supported assets and scan settings.

OPEN_FIREWALL

Firewall rules that allow connections from all IP addresses, like 0.0.0.0/0, or from all ports can unnecessarily expose resources to attacks from unintended sources. These rules should be removed or scoped explicitly to the intended source IP ranges or ports. For example, in applications intended to be public, consider restricting allowed ports to those needed for the application, like 80 and 443. If your application needs to allow connections from all IP addresses or ports, consider adding the asset to an allowlist. Learn more about Updating firewall rules.

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

Complete the following steps to remediate this finding:

  1. Go to the Firewall rules page in the Cloud Console.
    Go to Firewall rules
  2. Click the firewall rule listed in the Security Health Analytics finding, and then click Edit.
  3. Under Source IP ranges, edit the IP values to restrict the range of IPs that is allowed.
  4. Under Protocols and ports, select Specified protocols and ports, select the allowed protocols, and enter ports that are allowed.
  5. Click Save.

Learn about this finding type's supported assets and scan settings.

OPEN_FTP_PORT

Firewall rules that allow any IP address to connect to FTP ports might expose your FTP services to attackers. For more information, see VPC firewall rules overview.

The FTP service ports are:

  • TCP - 21

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

Complete the following steps to remediate this finding:

  1. Go to the Firewall page in the Cloud Console.
    Go to Firewall
  2. In the list of firewall rules, click the name of the firewall rule in the finding.
  3. Click Edit.
  4. Under Source IP ranges, delete 0.0.0.0/0.
  5. Add specific IP addresses or IP ranges that you want to let connect to the instance.
  6. Add specific protocols and ports you want to open on your instance.
  7. Click Save.

Learn about this finding type's supported assets and scan settings.

OPEN_HTTP_PORT

Firewall rules that allow any IP address to connect to HTTP ports might expose your HTTP services to attackers. For more information, see VPC firewall rules overview.

The HTTP service ports are:

  • TCP - 80

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

Complete the following steps to remediate this finding:

  1. Go to the Firewall page in the Cloud Console.
    Go to Firewall
  2. In the list of firewall rules, click the name of the firewall rule in the finding.
  3. Click Edit.
  4. Under Source IP ranges, delete 0.0.0.0/0.
  5. Add specific IP addresses or IP ranges that you want to let connect to the instance.
  6. Add specific protocols and ports you want to open on your instance.
  7. Click Save.

Learn about this finding type's supported assets and scan settings.

OPEN_LDAP_PORT

Firewall rules that allow any IP address to connect to LDAP ports might expose your LDAP services to attackers. For more information, see VPC firewall rules overview.

The LDAP service ports are:

  • TCP - 389, 636
  • UDP - 389

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

Complete the following steps to remediate this finding:

  1. Go to the Firewall page in the Cloud Console.
    Go to Firewall
  2. In the list of firewall rules, click the name of the firewall rule in the finding.
  3. Click Edit.
  4. Under Source IP ranges, delete 0.0.0.0/0.
  5. Add specific IP addresses or IP ranges that you want to let connect to the instance.
  6. Add specific protocols and ports you want to open on your instance.
  7. Click Save.

Learn about this finding type's supported assets and scan settings.

OPEN_MEMCACHED_PORT

Firewall rules that allow any IP address to connect to Memcached ports might expose your Memcached services to attackers. For more information, see VPC firewall rules overview.

The Memcached service ports are:

  • TCP - 11211, 11214, 11215
  • UDP - 11211, 11214, 11215

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

Complete the following steps to remediate this finding:

  1. Go to the Firewall page in the Cloud Console.
    Go to Firewall
  2. In the list of firewall rules, click the name of the firewall rule in the finding.
  3. Click Edit.
  4. Under Source IP ranges, delete 0.0.0.0/0.
  5. Add specific IP addresses or IP ranges that you want to let connect to the instance.
  6. Add specific protocols and ports you want to open on your instance.
  7. Click Save.

Learn about this finding type's supported assets and scan settings.

OPEN_MONGODB_PORT

Firewall rules that allow any IP address to connect to MongoDB ports might expose your MongoDB services to attackers. For more information, see VPC firewall rules overview.

The MongoDB service ports are:

  • TCP - 27017, 27018, 27019

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

Complete the following steps to remediate this finding:

  1. Go to the Firewall page in the Cloud Console.
    Go to Firewall
  2. In the list of firewall rules, click the name of the firewall rule in the finding.
  3. Click Edit.
  4. Under Source IP ranges, delete 0.0.0.0/0.
  5. Add specific IP addresses or IP ranges that you want to let connect to the instance.
  6. Add specific protocols and ports you want to open on your instance.
  7. Click Save.

Learn about this finding type's supported assets and scan settings.

OPEN_MYSQL_PORT

Firewall rules that allow any IP address to connect to MySQL ports might expose your MySQL services to attackers. For more information, see VPC firewall rules overview.

The MySQL service ports are:

  • TCP - 3306

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

Complete the following steps to remediate this finding:

  1. Go to the Firewall page in the Cloud Console.
    Go to Firewall
  2. In the list of firewall rules, click the name of the firewall rule in the finding.
  3. Click Edit.
  4. Under Source IP ranges, delete 0.0.0.0/0.
  5. Add specific IP addresses or IP ranges that you want to let connect to the instance.
  6. Add specific protocols and ports you want to open on your instance.
  7. Click Save.

Learn about this finding type's supported assets and scan settings.

OPEN_NETBIOS_PORT

Firewall rules that allow any IP address to connect to NetBIOS ports might expose your NetBIOS services to attackers. For more information, see VPC firewall rules overview.

The NetBIOS service ports are:

  • TCP - 137, 138, 139
  • UDP - 137, 138, 139

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

Complete the following steps to remediate this finding:

  1. Go to the Firewall page in the Cloud Console.
    Go to Firewall
  2. In the list of firewall rules, click the name of the firewall rule in the finding.
  3. Click Edit.
  4. Under Source IP ranges, delete 0.0.0.0/0.
  5. Add specific IP addresses or IP ranges that you want to let connect to the instance.
  6. Add specific protocols and ports you want to open on your instance.
  7. Click Save.

Learn about this finding type's supported assets and scan settings.

OPEN_ORACLEDB_PORT

Firewall rules that allow any IP address to connect to OracleDB ports might expose your OracleDB services to attackers. SeFor more information, seee VPC firewall rules overview.

The OracleDB service ports are:

  • TCP - 1521, 2483, 2484
  • UDP - 2483, 2484

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

Complete the following steps to remediate this finding:

  1. Go to the Firewall page in the Cloud Console.
    Go to Firewall
  2. In the list of firewall rules, click the name of the firewall rule in the finding.
  3. Click Edit.
  4. Under Source IP ranges, delete 0.0.0.0/0.
  5. Add specific IP addresses or IP ranges that you want to let connect to the instance.
  6. Add specific protocols and ports you want to open on your instance.
  7. Click Save.

Learn about this finding type's supported assets and scan settings.

OPEN_POP3_PORT

Firewall rules that allow any IP address to connect to POP3 ports might expose your POP3 services to attackers. For more information, see VPC firewall rules overview.

The POP3 service ports are:

  • TCP - 110

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

Complete the following steps to remediate this finding:

  1. Go to the Firewall page in the Cloud Console.
    Go to Firewall
  2. In the list of firewall rules, click the name of the firewall rule in the finding.
  3. Click Edit.
  4. Under Source IP ranges, delete 0.0.0.0/0.
  5. Add specific IP addresses or IP ranges that you want to let connect to the instance.
  6. Add specific protocols and ports you want to open on your instance.
  7. Click Save.

Learn about this finding type's supported assets and scan settings.

OPEN_POSTGRESQL_PORT

Firewall rules that allow any IP address to connect to PostgreSQL ports might expose your PostgreSQL services to attackers. For more information, see VPC firewall rules overview.

The PostgreSQL service ports are:

  • TCP - 5432
  • UDP - 5432

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

Complete the following steps to remediate this finding:

  1. Go to the Firewall page in the Cloud Console.
    Go to Firewall
  2. In the list of firewall rules, click the name of the firewall rule in the finding.
  3. Click Edit.
  4. Under Source IP ranges, delete 0.0.0.0/0.
  5. Add specific IP addresses or IP ranges that you want to let connect to the instance.
  6. Add specific protocols and ports you want to open on your instance.
  7. Click Save.

Learn about this finding type's supported assets and scan settings.

OPEN_RDP_PORT

Firewall rules that allow any IP address to connect to RDP ports might expose your RDP services to attackers. For more information, see VPC firewall rules overview.

The RDP service ports are:

  • TCP - 3389
  • UDP - 3389

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

Complete the following steps to remediate this finding:

  1. Go to the Firewall page in the Cloud Console.
    Go to Firewall
  2. In the list of firewall rules, click the name of the firewall rule in the finding.
  3. Click Edit.
  4. Under Source IP ranges, delete 0.0.0.0/0.
  5. Add specific IP addresses or IP ranges that you want to let connect to the instance.
  6. Add specific protocols and ports you want to open on your instance.
  7. Click Save.

Learn about this finding type's supported assets and scan settings.

OPEN_REDIS_PORT

Firewall rules that allow any IP address to connect to Redis ports might expose your Redis services to attackers. For more information, see VPC firewall rules overview.

The Redis service ports are:

  • TCP - 6379

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

Complete the following steps to remediate this finding:

  1. Go to the Firewall page in the Cloud Console.
    Go to Firewall
  2. In the list of firewall rules, click the name of the firewall rule in the finding.
  3. Click Edit.
  4. Under Source IP ranges, delete 0.0.0.0/0.
  5. Add specific IP addresses or IP ranges that you want to let connect to the instance.
  6. Add specific protocols and ports you want to open on your instance.
  7. Click Save.

Learn about this finding type's supported assets and scan settings.

OPEN_SMTP_PORT

Firewall rules that allow any IP address to connect to SMTP ports might expose your SMTP services to attackers. For more information, see VPC firewall rules overview.

The SMTP service ports are:

  • TCP - 25

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

Complete the following steps to remediate this finding:

  1. Go to the Firewall page in the Cloud Console.
    Go to Firewall
  2. In the list of firewall rules, click the name of the firewall rule in the finding.
  3. Click Edit.
  4. Under Source IP ranges, delete 0.0.0.0/0.
  5. Add specific IP addresses or IP ranges that you want to let connect to the instance.
  6. Add specific protocols and ports you want to open on your instance.
  7. Click Save.

Learn about this finding type's supported assets and scan settings.

OPEN_SSH_PORT

Firewall rules that allow any IP address to connect to SSH ports might expose your SSH services to attackers. For more information, see VPC firewall rules overview.

The SSH service ports are:

  • SCTP - 22
  • TCP - 22

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

Complete the following steps to remediate this finding:

  1. Go to the Firewall page in the Cloud Console.
    Go to Firewall
  2. In the list of firewall rules, click the name of the firewall rule in the finding.
  3. Click Edit.
  4. Under Source IP ranges, delete 0.0.0.0/0.
  5. Add specific IP addresses or IP ranges that you want to let connect to the instance.
  6. Add specific protocols and ports you want to open on your instance.
  7. Click Save.

Learn about this finding type's supported assets and scan settings.

OPEN_TELNET_PORT

Firewall rules that allow any IP address to connect to Telnet ports might expose your Telnet services to attackers. For more information, see VPC firewall rules overview.

The Telnet service ports are:

  • TCP - 23

This finding is generated for vulnerable firewall rules, even if you intentionally disable the rules. Active findings for disabled firewall rules alert you to unsafe configurations that will allow undesired traffic if enabled.

Complete the following steps to remediate this finding:

  1. Go to the Firewall page in the Cloud Console.
    Go to Firewall
  2. In the list of firewall rules, click the name of the firewall rule in the finding.
  3. Click Edit.
  4. Under Source IP ranges, delete 0.0.0.0/0.
  5. Add specific IP addresses or IP ranges that you want to let connect to the instance.
  6. Add specific protocols and ports you want to open on your instance.
  7. Click Save.

Learn about this finding type's supported assets and scan settings.

ORG_POLICY_CONFIDENTIAL_VM_POLICY

A Compute Engine resource is out of compliance with the constraints/compute.restrictNonConfidentialComputing organization policy. For more information about this org policy constraint, see Enforcing organization policy constraints.

Your organization requires this VM to have the Confidential VM service enabled. VMs that don't have this service enabled will not use runtime memory encryption, exposing them to runtime memory attacks.

Complete the following steps to remediate this finding:

  1. Go to the VM instances page
    Go to VM instances
  2. In the list of instances, click the name of the instance in the finding.
  3. If the VM doesn't require the Confidential VM service, move it to a new folder or project.
  4. If the VM requires Confidential VM, click Delete.
  5. To create a new instance with Confidential VM enabled, see Quickstart: Creating a Confidential VM instance.

Learn about this finding type's supported assets and scan settings.

ORG_POLICY_LOCATION_RESTRICTION

The Organization Policy gcp.resourceLocations constraint lets you restrict the creation of new resources to Cloud Regions you select. For more information, see Restricting resource locations.

Complete the following steps to remediate this finding:

The ORG_POLICY_LOCATION_RESTRICTION detector covers many resource types and remediation instructions are different for each resource. The general approach to remediate location violations includes the following:

  1. Copy, move, or back up the out-of-region resource or its data into a resource that is in-region. Read the documentation for individual services to get instructions on moving resources.
  2. Delete the original out-of-region resource or its data.

This approach is not possible for all resource types. For guidance, consult the customized recommendations that are provided in the finding.

Additional considerations

Managed resources

The lifecycles of resources are sometimes managed and controlled by other resources. For example, a managed Compute Engine instance group creates and destroys Compute Engine instances in accordance with the instance group's autoscaling policy. If managed and managing resources are in-scope for location enforcement, both might be flagged as violating the Organization Policy. Remediation of findings for managed resources should be done on the managing resource to ensure operational stability.

Resources in-use

Certain resources are used by other resources. For example, a Compute Engine disk that is attached to a running Compute Engine instance is considered to be in-use by the instance. If the resource in-use violates the location Organization Policy, you need to ensure that the resource is not in-use before addressing the location violation.

Learn about this finding type's supported assets and scan settings.

OS_LOGIN_DISABLED

OS Login is disabled on this Compute Engine instance.

OS Login enables centralized SSH key management with IAM, and it disables metadata-based SSH key configuration on all instances in a project. Learn how to set up and configure OS Login.

Complete the following steps to remediate this finding:

  1. Go to the Metadata page in the Cloud Console.
    Go to Metadata
  2. Click Edit, and then click Add item.
  3. Add an item with key enable-oslogin and value TRUE.

Learn about this finding type's supported assets and scan settings.

OVER_PRIVILEGED_ACCOUNT

A GKE node is using the Compute Engine default service node, which has broad access by default and might be over-privileged for running your GKE cluster.

Complete the following steps to remediate this finding:

Follow the instructions to Use least privilege Google service accounts.

Learn about this finding type's supported assets and scan settings.

OVER_PRIVILEGED_SCOPES

A node service account has broad access scopes.

Access scopes are the legacy method of specifying permissions for your instance. To reduce the possibility of a privilege escalation in an attack, create and use a minimally privileged service account to run your GKE cluster.

To remediate this finding, follow the instructions to Use least privilege Google service accounts.

Learn about this finding type's supported assets and scan settings.

OVER_PRIVILEGED_SERVICE_ACCOUNT_USER

A user has the iam.serviceAccountUser or iam.serviceAccountTokenCreator roles at the project, folder, or organization level, instead of for a specific service account.

Granting those roles to a user for a project, folder, or organization gives the user access to all existing and future service accounts at that scope. This situation can result in unintended escalation of privileges. For more information, see Service account permissions.

Complete the following steps to remediate this finding:

  1. Go to the IAM page.
    Go IAM page
  2. If necessary, select the project, folder, or organization in the finding.
  3. For each principal assigned roles/iam.serviceAccountUser or roles/iam.serviceAccountTokenCreator, do the following:
    1. Click Edit.
    2. In the Edit permissions panel, next to the roles, click Delete.
    3. Click Save.
  4. Follow this guide to grant individual users permission to impersonate a single service account. You need to follow the guide for each service account you want to allow chosen users to impersonate.

Learn about this finding type's supported assets and scan settings.

OWNER_NOT_MONITORED

Log metrics and alerts aren't configured to monitor Project Ownership assignments or changes.

The IAM Owner role has the highest level of privilege on a project. To secure your resources, set up alerts to get notified when new owners are added or removed. For more information, see Overview of logs-based metrics.

Depending on the quantity of information, Cloud Monitoring costs can be significant. To understand your usage of the service and its costs, see Cost optimization for Google Cloud's operations suite.

Complete the following steps to remediate this finding:

Create metric

  1. Go to the Logs-based Metrics page.
    Go to Logs-based Metrics
  2. Click Create Metric.
  3. Under Metric Type, select Counter.
  4. Under Details:
    1. Set a Log metric name.
    2. Add a description.
    3. Set Units to 1.
  5. Under Filter selection, copy and paste the following text into the Build filter box, replacing existing text, if necessary:
      (protoPayload.serviceName="cloudresourcemanager.googleapis.com")
      AND (ProjectOwnership OR projectOwnerInvitee)
      OR (protoPayload.serviceData.policyDelta.bindingDeltas.action="REMOVE"
      AND protoPayload.serviceData.policyDelta.bindingDeltas.role="roles/owner")
      OR (protoPayload.serviceData.policyDelta.bindingDeltas.action="ADD"
      AND protoPayload.serviceData.policyDelta.bindingDeltas.role="roles/owner")
    
  6. Click Create Metric. You see a confirmation.

Create Alert Policy

  1. Go to the Logs-based Metrics page.
    Go to Logs-based Metrics
  2. Under User-defined metrics section, select the metric you created in the previous section.
  3. Click More , and then click Create alert from metric. If you are asked to add your project to a Workspace, complete that process.
  4. On the page that opens, in the navigation menu, click Alerting.
  5. Under What do you want to track?, click Add Condition and complete the dialog to define what resources are monitored and when alerts are triggered. For information on the fields in a condition, see Specifying conditions.
  6. When done, click Add, and then click Next.
  7. Under Who should be notified?, click the Notification Channels drop-down and select how you would like to be notified. For more information, see Managing notification channels.
  8. Click OK, and then click Next.
  9. Under What are the steps to fix the issue?, set an Alert name.
  10. Click Save.

Learn about this finding type's supported assets and scan settings.

POD_SECURITY_POLICY_DISABLED

The PodSecurityPolicy is disabled on a GKE cluster.

A PodSecurityPolicy is an admission controller resource that validates requests to create and update pods on a cluster. Clusters won't accept pods that don't meet the conditions defined in the PodSecurityPolicy.

To remediate this finding, define and authorize PodSecurityPolicies, and enable the PodSecurityPolicy controller. For instructions, see Using PodSecurityPolicies.

Learn about this finding type's supported assets and scan settings.

PRIMITIVE_ROLES_USED

A user has one of the following IAM basic roles: roles/owner, roles/editor, or roles/viewer. These roles are too permissive and shouldn't be used. Instead, they should be assigned per project only.

For more information, see Understanding roles.

Complete the following steps to remediate this finding:

  1. Go to the IAM policy page.
    Go to IAM policy
  2. For each user assigned a primitive role, consider using more granular roles instead.

Learn about this finding type's supported assets and scan settings.

PRIVATE_CLUSTER_DISABLED

A GKE cluster has a private cluster disabled.

Private clusters allow nodes to only have internal IP addresses. This feature limits outbound internet access for nodes. If a cluster node doesn't have a public IP address, it isn't discoverable or exposed to the public internet. You can still route traffic to a node by using an internal load balancer. For more information, see Private clusters.

You can't make an existing cluster private. To remediate this finding, create a new private cluster:

  1. Go to the Kubernetes clusters page in the Cloud Console.
    Go to Kubernetes clusters
  2. Click Create Cluster.
  3. In the navigation menu, under Cluster, select Networking.
  4. Select the radio button for Private cluster.
  5. Under Advanced networking options, select the checkbox for Enable VPC-native traffic routing (uses alias IP).
  6. Click Create.

Learn about this finding type's supported assets and scan settings.

PRIVATE_GOOGLE_ACCESS_DISABLED

There are private subnets without access to Google public APIs.

Private Google Access enables VM instances with only internal (private) IP addresses to reach the public IP addresses of Google APIs and services.

For more information, see Configuring Google Private Access.

Complete the following steps to remediate this finding:

  1. Go to the VPC networks page.
    Go to VPC networks
  2. In the list of networks, click the name of the desired network.
  3. On the VPC network details page, click the Subnets tab.
  4. In the list of subnets, click the name of the subnet associated with the Kubernetes cluster in the finding.
  5. On the Subnet details page, click Edit .
  6. Under Private Google Access, select On.
  7. Click Save.
  8. To remove public (external) IPs from VM instances whose only external traffic is to Google APIs, see Unassigning a static external IP address.

Learn about this finding type's supported assets and scan settings.

PUBLIC_BUCKET_ACL

A bucket is public and anyone on the internet can access it.

For more information, see Overview of access control.

Complete the following steps to remediate this finding:

  1. Go to the Storage Browser page in the Cloud Console.
    Go to Storage Browser
  2. Select the bucket listed in the Security Health Analytics finding.
  3. On the Bucket details page, click the Permissions tab.
  4. Next to View by, click Roles.
  5. In the Filter box, search for allUsers and allAuthenticatedUsers.
  6. Click Delete to remove all IAM permissions granted to allUsers and allAuthenticatedUsers.

Learn about this finding type's supported assets and scan settings.

PUBLIC_COMPUTE_IMAGE

A Compute Engine image is public and anyone on the internet can access it. allUsers represents anyone on the internet and allAuthenticatedUsers represents anyone who is authenticated with a Google account; neither is constrained to users within your organization.

Compute Engine images might contain sensitive information like encryption keys or licensed software. Such sensitive information should not be publicly accessible. If you intended to make this Compute Engine image public, ensure that it does not contain any sensitive information.

For more information, see Access control overview.

Complete the following steps to remediate this finding:

  1. Go to the Compute Engine images page in the Cloud Console.
    Go to Compute Engine images
  2. Select the box next to the public-image image, and then click Show Info Panel.
  3. In the Filter box, search principals for allUsers and allAuthenticatedUsers.
  4. Expand the role for which you want to remove users.
  5. Click Delete to remove a user from that role.

Learn about this finding type's supported assets and scan settings.

PUBLIC_DATASET

A BigQuery dataset is public and accessible to anyone on the internet. The IAM principal allUsers represents anyone on the internet and allAuthenticatedUsers represents anyone who is logged into a Google service; neither is constrained to users within your organization.

For more information, see Controlling access to datasets.

Complete the following steps to remediate this finding:

  1. Go to the BigQuery Dataset page
    Go to BigQuery Dataset
  2. Click Share Dataset.
  3. In the Dataset permissions panel, use the Search principals box to search for allUsers and allAuthenticatedUsers, and remove access for these principals.

Learn about this finding type's supported assets and scan settings.

PUBLIC_IP_ADDRESS

A Compute Engine instance has a public IP address.

To reduce your organizations' attack surface, avoid assigning public IP addresses to your VMs. Stopped instances might still be flagged with a Public IP finding, for example, if the network interfaces are configured to assign an ephemeral public IP on start. Ensure the network configurations for stopped instances do not include external access.

For more information, see Securely connecting to VM instances.

Complete the following steps to remediate this finding:

  1. Go to the VM instances page in the Cloud Console.
    Go to VM instances
  2. In the list of instances, check the box next to the name of the instance in the finding.
  3. Click Edit.
  4. For each interface under Network interfaces, click Edit and set External IP to None.
  5. Click Done, and then click Save.

Learn about this finding type's supported assets and scan settings.

PUBLIC_LOG_BUCKET

A storage bucket is public and used as a log sink, meaning that anyone on the internet can access logs stored in this bucket. allUsers represents anyone on the internet and allAuthenticatedUsers represents anyone who is logged into a Google service; neither is constrained to users within your organization.

For more information, see Overview of access control.

Complete the following steps to remediate this finding:

  1. Go to the Cloud Storage browser page.
    Go to Cloud Storage browser
  2. In the list of buckets, click the name of the bucket indicated in the finding.
  3. Click the Permissions tab.
  4. Remove allUsers and allAuthenticatedUsers from the list of principals.

Learn about this finding type's supported assets and scan settings.

PUBLIC_SQL_INSTANCE

Your SQL instance has 0.0.0.0/0 as an allowed network. This occurrence means that any IPv4 client can pass the network firewall and make login attempts to your instance, including clients you might not have intended to allow. Clients still need valid credentials to successfully log in to your instance.

For more information, see Authorizing with authorized networks.

Complete the following steps to remediate this finding:

  1. Go to the Cloud SQL Instances page in the Cloud Console.
    Go to Cloud SQL Instances
  2. Select the instance listed in the Security Health Analytics finding.
  3. Click Edit.
  4. In the navigation panel, click Connections.
  5. Under Authorized networks, delete 0.0.0.0/0 and add specific IP addresses or IP ranges that you want to let connect to your instance.
  6. Click Done, and then click Save.

Learn about this finding type's supported assets and scan settings.

PUBSUB_CMEK_DISABLED

A Pub/Sub topic is not encrypted with customer-managed encryption keys (CMEK).

With CMEK, keys that you create and manage in Cloud KMS wrap the keys that Google uses to encrypt your data, giving you more control over access to your data.

To remediate this finding, delete the existing topic and create a new one:

  1. Go to Pub/Sub's Topics page in the Cloud Console.

    Go to Topics

  2. If necessary, select the project containing the Pub/Sub topic.

  3. Select the checkbox next to the topic listed in the finding, and then click Delete.

  4. To create a new Pub/Sub topic with CMEK enabled, see Using customer-managed encryption keys. CMEK incurs additional costs related to Cloud KMS.

  5. Publish findings or other data to the CMEK-enabled Pub/Sub topic.

Learn about this finding type's supported assets and scan settings.

ROUTE_NOT_MONITORED

Log metrics and alerts aren't configured to monitor VPC network route changes.

Google Cloud routes are destinations and hops that define the path that network traffic takes from a VM instance to a destination IP. By monitoring changes to route tables, you can help ensure that all VPC traffic flows through an expected path.

For more information, see Overview of logs-based metrics.

Depending on the quantity of information, Cloud Monitoring costs can be significant. To understand your usage of the service and its costs, see Cost optimization for Google Cloud's operations suite.

Complete the following steps to remediate this finding:

Create metric

  1. Go to the Logs-based Metrics page.
    Go to Logs-based Metrics
  2. Click Create Metric.
  3. Under Metric Type, select Counter.
  4. Under Details:
    1. Set a Log metric name.
    2. Add a description.
    3. Set Units to 1.
  5. Under Filter selection, copy and paste the following text into the Build filter box, replacing existing text, if necessary:
      resource.type="gce_route"
      AND protoPayload.methodName="compute.routes.delete"
      OR protoPayload.methodName="compute.routes.insert"
    
  6. Click Create Metric. You see a confirmation.

Create Alert Policy

  1. Go to the Logs-based Metrics page.
    Go to Logs-based Metrics
  2. Under User-defined metrics section, select the metric you created in the previous section.
  3. Click More , and then click Create alert from metric. If you are asked to add your project to a Workspace, complete that process.
  4. On the page that opens, in the navigation menu, click Alerting.
  5. Under What do you want to track?, click Add Condition and complete the dialog to define what resources are monitored and when alerts are triggered. For information on the fields in a condition, see Specifying conditions.
  6. When done, click Add, and then click Next.
  7. Under Who should be notified?, click the Notification Channels drop-down and select how you would like to be notified. For more information, see Managing notification channels.
  8. Click OK, and then click Next.
  9. Under What are the steps to fix the issue?, set an Alert name.
  10. Click Save.

Learn about this finding type's supported assets and scan settings.

REDIS_ROLE_USED_ON_ORG

A Redis IAM role is assigned at the organization or folder level.

The following Redis IAM roles should be assigned per project only, not at the organization or folder level:

  • roles/redis.admin
  • roles/redis.viewer
  • roles/redis.editor

For more information, see Access control and permissions.

Complete the following steps to remediate this finding:

  1. Go to the IAM policy page.
    Go to IAM policy
  2. Remove the Redis IAM roles indicated in the finding and add them on the individual projects instead.

Learn about this finding type's supported assets and scan settings.

RSASHA1_FOR_SIGNING

RSASHA1 is used for key signing in Cloud DNS zones. The algorithm used for key signing should not be weak.

To remediate this finding, replace the algorithm with a recommended one by following the Using advanced signing options guide.

Learn about this finding type's supported assets and scan settings.

SERVICE_ACCOUNT_KEY_NOT_ROTATED

A user-managed service account key hasn't been rotated for more than 90 days.

User-managed service account keys should be rotated every 90 days to ensure that data cannot be accessed with an old key which might have been lost, compromised, or stolen. For more information, see Managing service account keys.

Complete the following steps to remediate this finding:

  1. Go to the Service Accounts page.
    Go to Service Accounts
  2. If necessary, select the project indicated in the finding.
  3. In the list of service accounts, find the service account listed in the finding and click Delete. Before proceeding, consider the impact deleting a service account could have on your production resources.
  4. Create a new service account key to replace the old one. For more information, see Creating service account keys.

Learn about this finding type's supported assets and scan settings.

SERVICE_ACCOUNT_ROLE_SEPARATION

One or more principals in your organization have multiple service account permissions assigned. No account should simultaneously have Service Account Admin along with other service account permissions. To learn about service accounts and the roles available to them, see Service accounts.

Complete the following steps to remediate this finding:

  1. Go to the IAM page in the Cloud Console.
    Go to IAM
  2. For each principal listed in the finding, do the following:
    1. Check whether the role was inherited from a folder or organization resource by looking at the Inheritance column. If the column contains a link to a parent resource, click on the link to go to the parent resource's IAM page.
    2. Click Edit next to a principal.
    3. To remove permissions, click Delete next to Service Account Admin. If you want to remove all service account permissions, click Delete next to all other permissions.
  3. Click Save.

Learn about this finding type's supported assets and scan settings.

SHIELDED_VM_DISABLED

Shielded VM is disabled on this Compute Engine instance.

Shielded VM's are virtual machines (VMs) on Google Cloud hardened by a set of security controls that help defend against rootkits and bootkits. Shielded VM's help ensure that the boot loader and firmware are signed and verified. Learn more about Shielded VM.

Complete the following steps to remediate this finding:

  1. Go to the VM instances page in the Cloud Console.
    Go to VM instances
  2. Select the instance related to the Security Health Analytics finding.
  3. On the Instance details page that loads, click Stop.
  4. After the instance stops, click Edit.
  5. In the Shielded VM section, toggle Turn on vTPM and Turn on Integrity Monitoring to enable Shielded VM.
  6. Optionally, if you do not use any custom or unsigned drivers, then also enable Secure Boot.
  7. Click Save. The new configuration appears on the Instance details page.
  8. Click Start to start the instance.

Learn about this finding type's supported assets and scan settings.

SQL_CMEK_DISABLED

A SQL database instance is not using customer-managed encryption keys (CMEK).

With CMEK, keys that you create and manage in Cloud KMS wrap the keys that Google uses to encrypt your data, giving you more control over access to your data. For more information, see CMEK overviews for your product: Cloud SQL for MySQL, Cloud SQL for PostgreSQL, or Cloud SQL for SQL Server. CMEK incurs additional costs related to Cloud KMS.

Complete the following steps to remediate this finding:

  1. Go to the Cloud SQL Instances page in the Cloud Console.
    Go to Cloud SQL Instances
  2. Select the instance listed in the Security Health Analytics finding.
  3. Click Delete.
  4. To create a new instance with CMEK enabled, follow the instructions to configure CMEK for your product:
    1. Cloud SQL for MySQL
    2. Cloud SQL for PostgreSQL
    3. Cloud SQL for SQL Server

Learn about this finding type's supported assets and scan settings.

SQL_CONTAINED_DATABASE_AUTHENTICATION

A Cloud SQL for SQL Server database instance does not have the contained database authentication database flag set to Off.

The contained database authentication flag controls whether you can create or attach contained databases to the Database Engine. A contained database includes all database settings and metadata required to define the database and has no configuration dependencies on the instance of the Database Engine where the database is installed.

Enabling this flag is not recommended because of the following:

  • Users can connect to the database without authentication at the Database Engine level.
  • Isolating the database from the Database Engine makes it possible to move the database to another instance of SQL Server.

Contained databases face unique threats that should be understood and mitigated by SQL Server Database Engine administrators. Most threats result from the USER WITH PASSWORD authentication process, which moves the authentication boundary from the Database Engine level to the database level.

Complete the following steps to remediate this finding:

  1. Go to the Cloud SQL Instances page in the Cloud Console.
    Go to Cloud SQL Instances
  2. Select the instance listed in the Security Health Analytics finding.
  3. Click Edit.
  4. Under the Database flags section, set the contained database authentication database flag with the value Off.
  5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL_CROSS_DB_OWNERSHIP_CHAINING

A Cloud SQL for SQL Server database instance does not have the cross db ownership chaining database flag set to Off.

The cross db ownership chaining flag lets you control cross-database ownership chaining at the database level or allow cross-database ownership chaining for all database statements.

Enabling this flag is not recommended unless all databases hosted by the SQL Server instance participate in cross-database ownership chaining and you are aware of the security implications of this setting.

For more information, see Configuring database flags.

Complete the following steps to remediate this finding:

  1. Go to the Cloud SQL Instances page in the Cloud Console.
    Go to Cloud SQL Instances
  2. Select the instance listed in the Security Health Analytics finding.
  3. Click Edit.
  4. Under the Database flags section, set the cross db ownership chaining database flag with the value Off.
  5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL_INSTANCE_NOT_MONITORED

Log metrics and alerts aren't configured to monitor Cloud SQL instance configuration changes.

Misconfiguration of SQL instance options can cause security risks. Disabling auto backup and high availability options could impact business continuity and not restricting authorized networks could increase exposure to untrusted networks. Monitoring changes to SQL instance configuration helps you reduce the time it takes to detect and correct misconfigurations.

For more information, see Overview of logs- based metrics.

Depending on the quantity of information, Cloud Monitoring costs can be significant. To understand your usage of the service and its costs, see Cost optimization for Google Cloud's operations suite.

Complete the following steps to remediate this finding:

Create metric

  1. Go to the Logs-based Metrics page.
    Go to Logs-based Metrics
  2. Click Create Metric.
  3. Under Metric Type, select Counter.
  4. Under Details:
    1. Set a Log metric name.
    2. Add a description.
    3. Set Units to 1.
  5. Under Filter selection, copy and paste the following text into the Build filter box, replacing existing text, if necessary:
      protoPayload.methodName="cloudsql.instances.update"
    
  6. Click Create Metric. You see a confirmation.

Create Alert Policy

  1. Go to the Logs-based Metrics page.
    Go to Logs-based Metrics
  2. Under User-defined metrics section, select the metric you created in the previous section.
  3. Click More , and then click Create alert from metric. If you are asked to add your project to a Workspace, complete that process.
  4. On the page that opens, in the navigation menu, click Alerting.
  5. Under What do you want to track?, click Add Condition and complete the dialog to define what resources are monitored and when alerts are triggered. For information on the fields in a condition, see Specifying conditions.
  6. When done, click Add, and then click Next.
  7. Under Who should be notified?, click the Notification Channels drop-down and select how you would like to be notified. For more information, see Managing notification channels.
  8. Click OK, and then click Next.
  9. Under What are the steps to fix the issue?, set an Alert name.
  10. Click Save.

Learn about this finding type's supported assets and scan settings.

SQL_LOCAL_INFILE

A Cloud SQL for MySQL database instance does not have the local_infile database flag set to Off. Due to security issues associated with the local_infile flag, it should be disabled. For more information, see Configuring database flags.

Complete the following steps to remediate this finding:

  1. Go to the Cloud SQL Instances page in the Cloud Console.
    Go to Cloud SQL Instances
  2. Select the instance listed in the Security Health Analytics finding.
  3. Click Edit.
  4. Under the Database flags section, set the local_infile database flag with the value Off.
  5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL_LOG_CHECKPOINTS_DISABLED

A Cloud SQL for PostgreSQL database instance does not have the log_checkpoints database flag set to On.

Enabling log_checkpoints causes checkpoints and restart points to be logged in the server log. Some statistics are included in the log messages, including the number of buffers written and the time spent writing them.

For more information, see Configuring database flags.

Complete the following steps to remediate this finding:

  1. Go to the Cloud SQL Instances page in the Cloud Console.
    Go to Cloud SQL Instances
  2. Select the instance listed in the Security Health Analytics finding.
  3. Click Edit.
  4. Under the Database flags section, set the log_checkpoints database flag with the value On.
  5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL_LOG_CONNECTIONS_DISABLED

A Cloud SQL for PostgreSQL database instance does not have the log_connections database flag set to On.

Enabling the log_connections setting causes attempted connections to the server to be logged, along with successful completion of client authentication. The logs can be useful in troubleshooting issues and confirming unusual connection attempts to the server.

For more information, see Configuring database flags.

Complete the following steps to remediate this finding:

  1. Go to the Cloud SQL Instances page in the Cloud Console.
    Go to Cloud SQL Instances
  2. Select the instance listed in the Security Health Analytics finding.
  3. Click Edit.
  4. Under the Database flags section, set the log_connections database flag with the value On.
  5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL_LOG_DISCONNECTIONS_DISABLED

A Cloud SQL for PostgreSQL database instance does not have the log_disconnections database flag set to On.

Enabling the log_disconnections setting creates log entries at the end of each session. The logs are useful in troubleshooting issues and confirming unusual activity across a time period. For more information, see Configuring database flags.

Complete the following steps to remediate this finding:

  1. Go to the Cloud SQL Instances page in the Cloud Console.
    Go to Cloud SQL Instances
  2. Select the instance listed in the Security Health Analytics finding.
  3. Click Edit.
  4. Under the Database flags section, set the log_disconnections database flag with the value On.
  5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL_LOG_LOCK_WAITS_DISABLED

A Cloud SQL for PostgreSQL database instance does not have the log_lock_waits database flag set to On.

Enabling the log_lock_waits setting creates log entries when session waits take longer than the deadlock_timeout time to acquire a lock. The logs are useful in determining whether lock waits are causing poor performance.

For more information, see Configuring database flags.

Complete the following steps to remediate this finding:

  1. Go to the Cloud SQL Instances page in the Cloud Console.
    Go to Cloud SQL Instances
  2. Select the instance listed in the Security Health Analytics finding.
  3. Click Edit.
  4. Under the Database flags section, set the log_lock_waits database flag with the value On.
  5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL_LOG_MIN_DURATION_STATEMENT_ENABLED

A Cloud SQL for PostgreSQL database instance does not have the log_min_duration_statement database flag set to -1.

The log_min_duration_statement flag causes SQL statements that run longer than a specified time to be logged. Consider disabling this setting because SQL statements might contain sensitive information that should not be logged. For more information, see Configuring database flags.

Complete the following steps to remediate this finding:

  1. Go to the Cloud SQL Instances page in the Cloud Console.
    Go to Cloud SQL Instances
  2. Select the instance listed in the Security Health Analytics finding.
  3. Click Edit.
  4. Under the Database flags section, set the log_min_duration_statement database flag with the value -1.
  5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL_LOG_MIN_ERROR_STATEMENT

A Cloud SQL for PostgreSQL database instance does not have the log_min_duration_statement database flag set appropriately.

The log_min_error_statement flag controls whether SQL statements that cause error conditions are recorded in server logs. SQL statements of the specified severity or higher are logged with messages for the error statements. The greater the severity, the more messages that are recorded.

If log_min_error_statement is not set to the correct value, messages might not be classified as error messages. A severity set too low would increase the number of messages and make it difficult to find actual errors. A severity set too high might cause error messages for actual errors to not be logged.

For more information, see Configuring database flags.

Complete the following steps to remediate this finding:

  1. Go to the Cloud SQL Instances page in the Cloud Console.
    Go to Cloud SQL Instances
  2. Select the instance listed in the Security Health Analytics finding.
  3. Click Edit.
  4. Under the Database flags section, set the log_min_duration_statement database flag with one of the following recommended values, according to your organization's logging policy.
    • debug5
    • debug4
    • debug3
    • debug2
    • debug1
    • info
    • notice
    • warning
    • error
  5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL_LOG_TEMP_FILES

A Cloud SQL for PostgreSQL database instance does not have the log_temp_files database flag set to 0.

Temporary files can be created for sorts, hashes, and temporary query results. Setting the log_temp_files flag to 0 causes all temporary files information to be logged. Logging all temporary files is useful for identifying potential performance issues. For more information, see Configuring database flags.

Complete the following steps to remediate this finding:

  1. Go to the Cloud SQL Instances page in the Cloud Console.
    Go to Cloud SQL Instances
  2. Select the instance listed in the Security Health Analytics finding.
  3. Click Edit.
  4. Under the Database flags section, set the log_temp_files database flag with the value 0.
  5. Click Save. The new configuration appears on the Instance overview page.

Learn about this finding type's supported assets and scan settings.

SQL_NO_ROOT_PASSWORD

A MySQL database instance does not have a password set for the root account. You should add a password to the MySQL database instance. For more information, see MySQL users.

Complete the following steps to remediate this finding:

  1. Go to the Cloud SQL Instances page in the Cloud Console.
    Go to SQL Instances
  2. Select the instance listed in the Security Health Analytics finding.
  3. On the Instance details page that loads, select the Users tab.
  4. Next to the root user, click More , and then select Change Password.
  5. Enter a new, strong password, and then click OK.

Learn about this finding type's supported assets and scan settings.

SQL_PUBLIC_IP

A Cloud SQL database has a public IP address.

To reduce your organization's attack surface, Cloud SQL databases should not have public IP addresses. Private IP addresses provide improved network security and lower latency for your application.

Complete the following steps to remediate this finding:

  1. Go to the Cloud SQL Instances page in the Cloud Console.
    Go to SQL Instances
  2. Select the instance listed in the Security Health Analytics finding.
  3. On the Connections tab, clear the Public IP check box.
  4. If the instance is not already configured to use a private IP, see Configuring private IP for an existing instance.

Learn about this finding type's supported assets and scan settings.

SQL_WEAK_ROOT_PASSWORD

A MySQL database instance has a weak password set for the root account. You should set a strong password for the instance. For more information, see MySQL users.

Complete the following steps to remediate this finding:

  1. Go to the Cloud SQL Instances page in the Cloud Console.
    Go to SQL Instances
  2. Select the instance listed in the Security Health Analytics finding.
  3. On the Instance details page that loads, select the Users tab.
  4. Next to the root user, click More , and then select Change Password.
  5. Enter a new, strong password, and then click OK.

Learn about this finding type's supported assets and scan settings.

SSL_NOT_ENFORCED

A Cloud SQL database instance doesn't require all incoming connections to use SSL.

To avoid leaking sensitive data in transit through unencrypted communications, all incoming connections to your SQL database instance should use SSL. Learn more about Configuring SSL/TLS.

To remediate this finding, allow only SSL connections for your SQL instances:

  1. Go to the Cloud SQL Instances page in the Cloud Console.
    Go to SQL Instances
  2. Select the instance listed in the Security Health Analytics finding.
  3. On the Connections tab, click Allow only SSL connections.

Learn about this finding type's supported assets and scan settings.

TOO_MANY_KMS_USERS

Limit the number of principal users that can use cryptographic keys to three. The following predefined roles grant permissions to encrypt, decrypt, or sign data using cryptographic keys:

  • roles/owner
  • roles/cloudkms.cryptoKeyEncrypterDecrypter
  • roles/cloudkms.cryptoKeyEncrypter
  • roles/cloudkms.cryptoKeyDecrypter
  • roles/cloudkms.signer
  • roles/cloudkms.signerVerifier

For more information, see Permissions and roles.

Complete the following steps to remediate this finding:

  1. Go to the Cloud KMS keys page in the Cloud Console.
    Go to Cloud KMS keys
  2. Click the name of the key ring indicated in the finding.
  3. Click the name of the key indicated in the finding.
  4. Select the box next to the primary version, and then click Show Info Panel.
  5. Reduce the number of principals having permissions to encrypt, decrypt, or sign data to three or fewer. To revoke permissions, click Delete next to each principal.

Learn about this finding type's supported assets and scan settings.

USER_MANAGED_SERVICE_ACCOUNT_KEY

A user manages a service account key.

Service accounts should not have user-managed keys because they can be easily leaked. For more information, see Managing service account keys.

Complete the following steps to remediate this finding:

  1. Go to the Service Accounts page.
    Go to Service Accounts
  2. If necessary, select the project indicated in the finding.
  3. Delete user-managed service account keys indicated in the finding, if they are not used by any application.

Learn about this finding type's supported assets and scan settings.

WEAK_SSL_POLICY

A Compute Engine instance has a weak SSL policy.

HTTPS and SSL Proxy load balancers use SSL policies to determine the protocol and cipher suites used in the TLS connections established between users and the internet. These connections encrypt sensitive data to prevent malicious eavesdroppers from accessing it. A weak SSL policy permits clients using outdated versions of TLS to connect with a less secure cipher suite or protocol. For a list of recommended and outdated cipher suites, visit the [iana.org TLS parameters page]. (https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4)

Complete the following steps to remediate this finding:

  1. Go to the Target proxies page in the Cloud Console.
    Go to Target proxies
  2. Find the target proxy indicated in the finding and note forwarding rules in the In use by column.
  3. To create a new or update an existing SSL policy, see Using SSL policies. The policy should have a Minimum TLS version of 1.2 and a Modern or Restricted Profile.
  4. To use a Custom profile , ensure the following cipher suites are disabled:
    • TLS_RSA_WITH_AES_128_GCM_SHA256
    • TLS_RSA_WITH_AES_256_GCM_SHA384
    • TLS_RSA_WITH_AES_128_CBC_SHA
    • TLS_RSA_WITH_AES_256_CBC_SHA
    • TLS_RSA_WITH_3DES_EDE_CBC_SHA
  5. Apply the SSL policy to each forwarding rule you previously noted.

Learn about this finding type's supported assets and scan settings.

WEB_UI_ENABLED

The GKE web UI (dashboard) is enabled.

A highly privileged Kubernetes Service Accounts backs the Kubernetes web interface. If compromised, the service account can be abused. If you are already using the Cloud Console, the Kubernetes web interface extends your attack surface unnecessarily. Learn about Disabling the Kubernetes web interface.

To remediate this finding, disable the Kubernetes web interface:

  1. Go to the Kubernetes clusters page in the Cloud Console.
    Go to Kubernetes clusters
  2. Click the name of the cluster listed in the Security Health Analytics finding.
  3. Click Edit.

    If the cluster configuration recently changed, the edit button might be disabled. If you aren't able to edit the cluster settings, wait a few minutes and then try again.

  4. Click Add-ons. The section expands to display available add-ons.

  5. On the Kubernetes dashboard drop-down list, select Disabled.

  6. Click Save.

Learn about this finding type's supported assets and scan settings.

WORKLOAD_IDENTITY_DISABLED

Workload Identity is disabled on a GKE cluster.

Workload Identity is the recommended way to access Google Cloud services from within GKE because it offers improved security properties and manageability. Enabling it protects some potentially sensitive system metadata from user workloads running on your cluster. Learn about Metadata concealment.

To remediate this finding, follow the guide to Enable Workload Identity on a cluster.

Learn about this finding type's supported assets and scan settings.