Governance Specification Language (GSL)

Use Case

GSL is used to create compliance rules and Intelligence queries that you can run on your cloud environments to assess them. CloudGuard provides a graphical interface called GSL Builder or GSL Editor that helps you build the rule in the applicable context. For more information, see GSL Builder.

Rule Syntax

GSL rules have the form:

<Target> should <Condition>

The Target is the cloud entity type that the rule checks, for example, instance or SecurityGroup. Each rule can check only one target.

You can qualify the target to match a smaller set of entities that you add with the where keyword.

The formal definition of the target is:

<entity_type> where <expression>

Where:

  • entity_type - The pivot cloud entity type that CloudGuard checks, for example, Instance, SecurityGroup, ELB.

  • expression - Can be any complex GSL expression to match the target entity type.

Examples:

SecurityGroup where name='default' should...

Instance where (tags contain [key='env' and value='prod'] and not name='test') should ...

The Condition is the actual essence of the rule. It contains the attributes of the target that CloudGuard examines. The condition can be a complex GSL expression that tests some attributes related to the target.

Context Travel

When you use a command that references an array (with, contain, contain-any, contain-all, contain-none, groupBy, and so on), you execute an action that searches in the array's internal objects.

Each time you use array commands, you create a new context and delve deeper into the array. In a sense, you travel deeper into the child objects of the array which themselves can also be arrays. This is called child context travel.

You can use commands to refer back to the parent context and return to the parent array.

To do this, you can use some types of commands. Each command has a text representation and a symbol representation.

Command Symbol

Command Text

Description

Reference the current array context level.

The current array you have reached in the GSL query

Reference the topmost level of the array context.

The root level of any GSL query is the asset itself.

^

Reference the n level above the current array context.

To travel more than one context level, type more than one symbol (^^ or ^^^) or use its text equivalents, such as parent(2) or parent(3).

Examples

  1. The $ refers to each role in the roles array.

    ServiceAccount should not have roles contain-any [ $ like 'roles/iam.serviceAccount%']

  2. This compares the tags value with the value in the ‘instanceType’ field.

    Instance should have tags contain [ value like ~.instanceType ]

  3. In this example, the ‘^.name’ equals to ‘IamUser.name’.

    IamUser should have firstAccessKey with [ isActive = 'true' and ^.name like '%d%']

Expressions

Data Types

GSL has different syntax for strings (textual values) and numeric values.

Functions

The core GSL syntax is enriched by internal functions that provide domain-specific functionality in multiple areas such as IP addresses, dates, and string matching.

Syntax:

<property_name> <function_name> (<param1>,<param2>...)

Where:

  • property_name is the property/object we wish to operate on (equivalent to functions in object-oriented languages)

  • function_name is the name of the functions from the above list params the required parameters based on the type of the function, separated by

General Functions

Networking Functions - General

Networking Functions for AWS NACL and MS Azure NSG

AWS NACL and MS Azure NSGs have different firewall semantics.

The firewall rules are in an order and may contain explicit 'DROP'. This makes the order of the rules very important.

These functions operate on a list of rules.

Resource Functions

These functions return values for properties of assets. Especially, they can return secondary values for assets (for example, the value of a rule address for an SG assigned to an EC2 instance).

Time Functions