Glossary

This is a glossary of terms used in GorillaStack and their meaning.

Team

A Team is an organisation or company using GorillaStack. It is the billing entity for subscriptions. It has multiple Users, User Groups and linked cloud environments.

User

A User is a member of a Team and is an entity with access to GorillaStack.

Role

A Role is a capability that a User has within a Team. The Role has a series of policies, which allow or deny privileges over different resources.

For example, a user may have snooze and cancel privileges over the Rules resource.

A Role can have one parent role, from which it inherits policies.

More about our role based access control (RBAC).

User Group

A User Group is a subset of Users within a Team. Within the scope of a User Group, Users can have different Roles. The User Group can own multiple Rules, thus granting its Users elevated or restricted privileges within that context.

User Groups are a feature restricted to enterprise customers.

Rule

A Rule is a configuration of an automation policy, to apply a given Actions over targeted resources when responding to Triggers in a given Context.

Context

The Context is the scope of the Rule. It defines the combination of AWS Accounts and AWS Regions to observe Triggers within.

Trigger

The Trigger is the observed event that will kick off our Rule.

Action

The Action is the turnkey automation capability that will be applied in response to the observed Trigger event.

Tag Group

A Tag Group is a targeting mechanism, used to describe a collection of resources within a cloud environment. Tag Groups allow customers to define a combination of resource tag key:value pairs and a matching option for each and then combine them using a boolean expression to target any resources for which the given Tag Group validates.

Tag Groups can be re-used between different Rule Actions that target different resource types.

To avoid side-effects, once in use, Tag Groups cannot be modified, however, they can be cloned and then their references can be updated.

More about targeting resources with tag groups.

Matching Option

The Matching Option allows customers to define how they would like to match the GorillaStack definition of key:value pairs with those against their resources in their cloud environments. We support the following matching options:

  • Case Insensitive
  • Case Sensitive
  • Regular expression

Boolean Expression

The Boolean Expression allows customers to express the expected presence and absence of given resource tags from a resource. For example, the customer can define a Tag Group with 3 resource tags:

  • Tag 0: { key: /costcentre/i, value: /^dev/i, matching_option: 'regex' }
  • Tag 1: { key: 'Application', value: 'Billing', matching_option: 'sensitive' }
  • Tag 2: { key: 'environment', value: 'production', matching_option: 'insensitive' }

Then the user could define a Boolean Expression of 0 and 1 not 2 to target all resources with a tag cost centre that starts with 'dev', an 'Application' tag of 'Billing' BUT NO 'environment' tag of any casing with the value 'production' of any casing.

Tag Groups in Action

AWS Account Groups

AWS Account Groups make it easier to target many AWS Accounts in a Rule. Once an AWS Account Group is created and selected in Rules, a User only has to modify the AWS Account Group to influence which AWS Accounts are targeted in those Rules.

For example:

For a hypothetical Team using AWS Account Groups, four different GorillaStack Rules exist with the responsibilities of starting and stopping non-production EC2 and RDS Instances. An AWS Account Group named `non-prod` is selected in each Rule context, effectively targeting 23 non-production AWS Accounts across all Rules. The Team admins then wish to add another non-production AWS Account to GorillaStack. The admins can add the AWS Account to GorillaStack, and then select the new AWS Account as a member of the `non-prod` AWS Account Group. The existing Rules will now target the new AWS Account, no further manual changes of Rule contexts required.