About

When you connect Google Cloud to ControlMap, it scans the Google Cloud project against CIS benchmarks and reports any deviations automatically. This article lists each rule ControlMap scans for, what the rule checks and why it matters, so you know what to expect and what to fix when a check fails.

The rules follow the CIS benchmarks for Google Cloud. We strongly recommend that you read the CIS benchmarks for Google Cloud, which hold the full audit and remediation steps for every rule. Use them for a more detailed understanding of each issue and how to fix it.

See the results in ControlMap

Scan results appear in Monitor once the Google Cloud connection has run its first scan.

1. Go to Monitor › Compliance Checks.
2. To show only benchmark checks, open the check-type filter and choose CIS Benchmarks.
3. Look at the Status column. Each check shows Passing, Failing, Error or No Data.
4. To see the detail behind a result, open the Compliance check actions menu on the row and select View Evidence. The panel has two tabs, Scan results and Evidence reports.

No Data means the check hasn't run yet, or the resources it tests don't exist yet in the connected Google Cloud project.

Rules scanned

Each rule below has a description of what it checks and a rationale for why it matters. Rule numbers match the CIS benchmark numbering.

1.4 Ensure that there are only GCP-managed service account keys for each service account

Rule ID: GCP-CMAP-1-4

Description: User-managed service accounts should not have user-managed keys.

Rationale: Anyone who has access to the keys can reach resources through the service account. GCP-managed keys are used by Cloud Platform services such as App Engine and Compute Engine. These keys can't be downloaded. Google keeps them and rotates them automatically, approximately weekly. User-managed keys are created, downloadable and managed by users, and they expire 10 years after creation.

For user-managed keys, the user takes ownership of these key management activities:

• Key storage
• Key distribution
• Key revocation
• Key rotation
• Protecting the keys from unauthorized users
• Key recovery

Even with careful owners, keys are easily leaked by common development mistakes, such as checking keys into source code, leaving them in a Downloads folder, or accidentally posting them on support blogs or channels. Prevent user-managed service account keys.

1.5 Ensure that Service Account has no Admin privileges

Rule ID: GCP-CMAP-1-5

Description: A service account is a special Google account that belongs to an application or a VM instead of an individual person. The application uses the service account to call Google APIs, so users aren't directly involved. Don't give service accounts admin access.

Rationale: Service accounts represent the service-level security of resources (an application or a VM), which is set by the roles assigned to them. A service account with admin rights has full access to its application or VM. Whoever holds access to that service account can take critical actions, such as deleting or changing settings, without any user intervention. For this reason, service accounts should not have admin rights.

1.6 Ensure that IAM users are not assigned the Service Account User or Service Account Token Creator roles at project level

Description: Assign the Service Account User (iam.serviceAccountUser) and Service Account Token Creator (iam.serviceAccountTokenCreator) roles to a user for a specific service account, not at project level.

Rationale: A service account is a special Google account that belongs to an application or a VM instead of an individual person. The application or VM instance uses the service account to call Google APIs, so users aren't directly involved. A service account is also a resource with IAM policies attached, and those policies decide who can use it.

Users with IAM roles that let them update App Engine and Compute Engine instances (such as App Engine Deployer or Compute Instance Admin) can effectively run code as the service accounts those instances use. That indirectly gives them access to every resource the service accounts can reach. SSH access to a Compute Engine instance can also let someone run code as that instance's service account.

A project can have several user-managed service accounts. Granting the Service Account User or Service Account Token Creator role to a user at project level gives that user access to all service accounts in the project, including ones created in the future. This can lead to privilege escalation through service accounts and their Compute Engine instances.

To follow least-privilege practice, don't assign these roles at project level. Assign them to a user for a specific service account instead. The Service Account User role lets a user bind a service account to a long-running job service. The Service Account Token Creator role lets a user directly impersonate (assert) the identity of a service account.

1.7 Ensure user-managed/external keys for service accounts are rotated every 90 days or less

Rule ID: GCP-CMAP-1-7

Description: Service account keys consist of a key ID (Private_key_Id) and a private key. They are used to sign programmatic requests that users make to the Google Cloud services the service account can reach. Rotate all service account keys regularly.

Rationale: Rotating service account keys shortens the time an access key tied to a compromised or terminated account can be used. It also makes sure data can't be accessed with an old key that might have been lost, cracked or stolen.

Each service account has a key pair managed by Google Cloud Platform (GCP), used for service-to-service authentication within GCP. Google rotates these keys daily. GCP also lets you create user-managed (external) key pairs for use from outside GCP, for example with Application Default Credentials. When you create one, you must download the private key, and Google doesn't keep a copy. With external keys, you are responsible for keeping the private key secure and for management tasks such as rotation. You can manage external keys with the IAM API, the gcloud command-line tool, or the Service Accounts page in the Google Cloud console. GCP allows up to 10 external keys per service account to make rotation easier.

1.8 Ensure that Separation of duties is enforced while assigning service account related roles to users

Rule ID: GCP-CMAP-1-8

Description: Enforce the principle of separation of duties when you assign service-account roles to users.

Rationale: The built-in IAM role Service Account Admin lets a user create, delete and manage service accounts. The built-in IAM role Service Account User lets a user (with enough privileges on Compute Engine and App Engine) assign service accounts to apps and Compute instances.

Separation of duties means no single person holds all the permissions needed to complete a malicious action. With Cloud IAM service accounts, that action could be using a service account to reach resources the user shouldn't normally reach. It is a business control typically used in larger organizations to help avoid security or privacy incidents and errors, and it is considered best practice. No user should have the Service Account Admin and Service Account User roles at the same time.

1.9 Ensure that Cloud KMS cryptokeys are not anonymously or publicly accessible

Rule ID: GCP-CMAP-1-9

Description: The IAM policy on Cloud KMS cryptokeys should restrict anonymous and public access.

Rationale: Granting permissions to allUsers or allAuthenticatedUsers lets anyone access the dataset. That may not be desirable if sensitive data is stored there. Make sure anonymous and public access to a Cloud KMS cryptokey is not allowed.

1.10 Ensure KMS encryption keys are rotated within a period of 90 days

Rule ID: GCP-CMAP-1-10

Description: Google Cloud Key Management Service stores cryptographic keys in a hierarchical structure designed for access control management. The format of the rotation schedule depends on the client library you use. For the gcloud command-line tool, the next rotation time must be in ISO or RFC3339 format, and the rotation period must be in the form INTEGER[UNIT], where the unit is seconds (s), minutes (m), hours (h) or days (d).

Rationale: Set a key rotation period and a starting time. A key can be created with a rotation period, which is the time between automatically generated new key versions. It can also be created with a next rotation time. A key is a named object that represents a cryptographic key used for a specific purpose. The key material, the actual bits used for encryption, can change over time as new key versions are created.

A key protects a body of data. A collection of files could be encrypted with the same key, and anyone with decrypt permission on that key could decrypt those files. That is why the rotation period must be set to a specific time.

3.1 Ensure that the default network does not exist in a project

Rule ID: GCP-CMAP-3-1

Description: To prevent use of the default network, a project should not have one.

Rationale: The default network has a preconfigured setup and automatically creates these insecure firewall rules:

• default-allow-internal: allows ingress connections for all protocols and ports among instances in the network.
• default-allow-ssh: allows ingress connections on TCP port 22 (SSH) from any source to any instance in the network.
• default-allow-rdp: allows ingress connections on TCP port 3389 (RDP) from any source to any instance in the network.
• default-allow-icmp: allows ingress ICMP traffic from any source to any instance in the network.

These automatically created firewall rules aren't audit logged and can't be configured to enable firewall rule logging. The default network is also an auto mode network, so its subnets use the same predefined IP address range. As a result, you can't use Cloud VPN or VPC Network Peering with it. Based on your organization's security and networking requirements, create a new network and delete the default network.

3.6 Ensure that SSH access is restricted from the internet

Rule ID: GCP-CMAP-3-6

Description: GCP firewall rules are specific to a VPC network. Each rule allows or denies traffic when its conditions are met. The conditions let you specify the type of traffic, such as ports and protocols, and the source or destination of the traffic, including IP addresses, subnets and instances.

Firewall rules are defined at the VPC network level and can't be shared among networks. They support only IPv4 traffic. When you specify a source for an ingress rule or a destination for an egress rule by address, you can use only an IPv4 address or an IPv4 block in CIDR notation. Avoid generic (0.0.0.0/0) incoming SSH traffic on port 22 from the internet to a VPC or VM instance.

Rationale: GCP firewall rules within a VPC network apply to outgoing (egress) traffic from instances and incoming (ingress) traffic to instances in the network. Egress and ingress traffic is controlled even when it stays within the network, for example instance-to-instance communication. For an instance to have outgoing internet access, the network needs a valid internet gateway route or a custom route with a specified destination IP. That route defines the path to the internet. To avoid the most general destination range (0.0.0.0/0) reaching instances over SSH on the default port 22, restrict generic access from the internet to a specific IP range.

3.7 Ensure that RDP access is restricted from the Internet

Rule ID: GCP-CMAP-3-7

Description: GCP firewall rules are specific to a VPC network. Each rule allows or denies traffic when its conditions are met. The conditions let you specify the type of traffic, such as ports and protocols, and the source or destination of the traffic, including IP addresses, subnets and instances.

Firewall rules are defined at the VPC network level and can't be shared among networks. They support only IPv4 traffic. When you specify a source for an ingress rule or a destination for an egress rule by address, you can use an IPv4 address or an IPv4 block in CIDR notation. Avoid generic (0.0.0.0/0) incoming RDP traffic on port 3389 from the internet to a VPC or VM instance.

Rationale: GCP firewall rules within a VPC network apply to outgoing (egress) traffic from instances and incoming (ingress) traffic to instances in the network. Egress and ingress traffic is controlled even when it stays within the network, for example instance-to-instance communication. For an instance to have outgoing internet access, the network needs a valid internet gateway route or a custom route with a specified destination IP. That route defines the path to the internet. To avoid the most general destination range (0.0.0.0/0) reaching instances over RDP on the default port 3389, restrict generic access from the internet to a specific IP range.

4.1 Ensure that instances are not configured to use the default service account

Rule ID: GCP-CMAP-4-1

Description: Configure your instances so they don't use the default Compute Engine service account, because it has the Editor role on the project.

Rationale: 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 escalation if a VM is compromised, and to stop an attacker gaining access to your whole project, don't use the default Compute Engine service account. Create a new service account and assign it only the permissions your instance needs. The default Compute Engine service account is named [PROJECT_NUMBER]-compute@developer.gserviceaccount.com.

4.2 Ensure that instances are not configured to use the default service account with full access to all Cloud APIs

Rule ID: GCP-CMAP-4-2

Description: To support least privilege and prevent privilege escalation, don't assign instances to the Compute Engine default service account with the scope Allow full access to all Cloud APIs.

Rationale: Besides letting you create, manage and use your own service accounts, Google Compute Engine provides a default service account that instances use to reach the cloud services they need. The project Editor role is assigned to this default service account, so it has almost all capabilities over all cloud services except billing. When the default service account is assigned to an instance, it can operate in one of three scopes:

• Allow default access: allows only the minimum access needed to run an instance (least privilege).
• Allow full access to all Cloud APIs: allows full access to all cloud APIs and services (too much access).
• Set access for each API: lets the instance administrator choose only the APIs needed for the instance's business function.

When an instance uses the default service account with the scope Allow full access to all Cloud APIs, then depending on the IAM roles of the users who access the instance, those users may be able to perform cloud operations or API calls they shouldn't, which can lead to privilege escalation.

4.3 Ensure "Block Project-wide SSH keys" is enabled for VM instances

Rule ID: GCP-CMAP-4-3

Description: Use instance-specific SSH keys instead of common, shared project-wide SSH keys to access instances.

Rationale: Project-wide SSH keys are stored in Compute project metadata and can be used to log in to all instances in the project. They make SSH key management easier, but if one is compromised, every instance in the project is at risk. Instance-specific SSH keys limit the attack surface if a key is compromised.

4.5 Ensure 'Enable connecting to serial ports' is not enabled for VM Instance

Rule ID: GCP-CMAP-4-5

Description: Interacting with a serial port is often called using the serial console. It is similar to using a terminal window: input and output are text only, with no graphical interface or mouse support. If you enable the interactive serial console on an instance, clients can try to connect to that instance from any IP address, so interactive serial console support should be disabled.

Rationale: A virtual machine instance has four virtual serial ports. The instance's operating system, BIOS and other system-level entities often write output to the serial ports and can accept input such as commands or answers to prompts. Typically these entities use the first serial port (port 1), which is often called the serial console.

The interactive serial console doesn't support IP-based access restrictions such as IP allowlists. If you enable it on an instance, clients can attempt to connect from any IP address. Anybody who knows the correct SSH key, username, project ID, zone and instance name could then connect to that instance. For this reason, interactive serial console support should be disabled.

4.6 Ensure that IP forwarding is not enabled on Instances

Rule ID: GCP-CMAP-4-6

Description: A Compute Engine instance can't forward a packet unless the packet's source IP address matches the instance's IP address. Likewise, GCP won't deliver a packet whose destination IP address differs from the IP address of the instance receiving it. Both capabilities are required if you want instances to help route packets. Disable forwarding of data packets to prevent data loss or information disclosure.

Rationale: To enable the source and destination IP check, disable the canIpForward field, which lets an instance send and receive packets with non-matching destination or source IPs.

4.9 Ensure that Compute instances do not have public IP addresses

Rule ID: GCP-CMAP-4-9

Description: Compute instances should not be configured with external IP addresses.

Rationale: To reduce your attack surface, Compute instances should not have public IP addresses. Place instances behind load balancers instead, to minimize their exposure to the internet.

4.11 Ensure that Compute instances have Confidential Computing enabled

Rule ID: GCP-CMAP-4-11

Description: Google Cloud encrypts data at rest and in transit, but customer data must be decrypted for processing. Confidential Computing encrypts data in use, while it is being processed. Confidential Computing environments keep data encrypted in memory and elsewhere outside the central processing unit (CPU).

Confidential VMs use the Secure Encrypted Virtualization (SEV) feature of AMD EPYC CPUs. Customer data stays encrypted while it is used, indexed, queried or trained on. Encryption keys are generated in hardware, per VM, and can't be exported. Thanks to built-in hardware optimizations for both performance and security, there is no significant performance penalty for Confidential Computing workloads.

Rationale: Confidential Computing keeps your sensitive code and data encrypted in memory during processing. Google doesn't have access to the encryption keys. Confidential VMs can ease concerns about depending on Google infrastructure, or about Google insiders accessing customer data in the clear.

5.1 Ensure that Cloud Storage bucket is not anonymously or publicly accessible

Rule ID: GCP-CMAP-5-1

Description: The IAM policy on a Cloud Storage bucket should not allow anonymous or public access.

Rationale: Allowing anonymous or public access gives anyone permission to read the bucket's content. That may not be desirable if you store sensitive data, so make sure anonymous or public access to a bucket is not allowed.

5.2 Ensure that Cloud Storage buckets have uniform bucket-level access enabled

Rule ID: GCP-CMAP-5-2

Description: Enable uniform bucket-level access on Cloud Storage buckets.

Rationale: Uniform bucket-level access unifies and simplifies how you grant access to your Cloud Storage resources. Cloud Storage offers two systems for granting permission to buckets and objects: Cloud Identity and Access Management (Cloud IAM) and Access Control Lists (ACLs). They work in parallel, so a user needs permission from only one of them to access a Cloud Storage resource. Cloud IAM is used throughout Google Cloud and lets you grant a variety of permissions at the bucket and project levels. ACLs are used only by Cloud Storage and have limited permission options, but they let you grant permissions per object.

Uniform bucket-level access disables ACLs for all Cloud Storage resources, so access is granted only through Cloud IAM. Enabling it guarantees that if a bucket isn't publicly accessible, no object in the bucket is publicly accessible either.

6.4 Ensure that the Cloud SQL database instance requires all incoming connections to use SSL

Rule ID: GCP-CMAP-6-4

Description: Require all incoming connections to a SQL database instance to use SSL.

Rationale: If SQL database connections are intercepted (a man-in-the-middle attack), they can reveal sensitive data such as credentials, database queries and query outputs. For security, always use SSL encryption when connecting to your instance. This applies to PostgreSQL, MySQL generation 1, MySQL generation 2 and SQL Server 2017 instances.

6.5 Ensure that Cloud SQL database instances are not open to the world

Rule ID: GCP-CMAP-6-5

Description: A database server should accept connections only from trusted networks and IPs, and restrict access from the world.

Rationale: To minimize the attack surface of a database server instance, allowlist only the trusted, known and required IPs. An authorized network should not include 0.0.0.0/0, which allows access to the instance from anywhere in the world. Authorized networks apply only to instances with public IPs.

6.6 Ensure that Cloud SQL database instances do not have public IPs

Rule ID: GCP-CMAP-6-6

Description: Configure second generation SQL instances to use private IPs instead of public IPs.

Rationale: To lower your organization's attack surface, Cloud SQL databases should not have public IPs. Private IPs give better network security and lower latency for your application.

6.7 Ensure that Cloud SQL database instances are configured with automated backups

Rule ID: GCP-CMAP-6-7

Description: Enable automated backups on all SQL database instances.

Rationale: Backups let you restore a Cloud SQL instance to recover lost data or recover from a problem with the instance. Set automated backups on any instance that contains data that must be protected from loss or damage. This applies to SQL Server, PostgreSQL, MySQL generation 1 and MySQL generation 2 instances.