Google Cloud Platform Keywords

The following keywords are supported in Google Cloud Platform (GCP) audits:




Uses JQ to transform the aggregate JSON file from GCP into a format that is easier to understand and evaluate. See JQ Example.


Specifies the plugin should return a data set.


regex Filters the JQ outputs to a smaller set of lines of text based on the regular expression. It is an optional transformation.
expect and not_expect

The evaluation is based on expect or not_expect. Use only one of these fields in a check.

For expect, if the regular expression matches a line of text, the check results as PASSED. If there are no matches, the check results as FAILED.

For not_expect, if the regular expression matches a line of text, the check results as FAILED. If there are no matches, the check results as PASSED.

match_all Setting match_all to YES requires the item to match all lines of text, and not just a single line of text. If match_all is set to the default NO, only one line must match for the check to pass.
match_case Setting match_case to YES performs a case sensitive match of the output against the expect/not expect. If match_case is set to the default NO, expect and not_expect matching is case insensitive.

The GCP plugin utilizes the GCP REST API in order to obtain configuration information for your cloud environment. At the Tenable audit and check level, action types are used in the request field. These action types correlate to documented API endpoints with some modifications. If there are prerequisites for a given API call (the project or location, for example), that information is queried for and prepopulated into an aggregate JSON document before attaching the specified action type’s information. This aggregate JSON document is then filtered using JQ in order to format the configuration data for evaluation and review.

Note: When writing your own checks for GCP, you can list the aggregate JSON document by using a request type with no json_transform, regexor expect fields. For more information, see Request Types.

Aggregate JSON Example

The following is an example of the aggregate JSON document:

JQ Example

The following is an example of how an aggregate JSON document gets transformed into JQ:

json_transform: ".projects[] | \"Name: \(.name), Number: \(.projectNumber)\""


Name: my-project-1, Number: 295700069523

Name: my-project-2, Number: 992398048003

Example Checks

Example 1:

type : REST_API

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

request : "listIamServiceAccountKeys"

json_transform : ".projects[].value.accounts[].value.keys[] | select(.keyType == \"USER_MANAGED\") | \"Type: \(.keyType), Name: \(.name)\""

regex : "Type: USER_MANAGED"

not_expect : "Name: .*\.iam\.gserviceaccount\.com/keys/"

Example 2:

type : REST_API

description : "1.5 Ensure that Service Account has no Admin privileges"

break functionality that uses impacted service accounts. Required role(s) should be assigned to impacted service accounts in order to restore broken functionalities."

request : "listProjectIAM"

json_transform : ".projects[] | .projectNumber as $projectNumber | .projectId as $projectId | .value.bindings[] | \"Project Number: \($projectNumber), Project ID: \($projectId), Member: \(.members[]), Role: \(.role)\""

regex : "Member: serviceAccount:.*\.iam\.gserviceaccount\.com"

not_expect : "Role: roles/.*(admin|editor|owner)"