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:
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
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/"
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)"