Access Control is here!

Terrateam has been hard at work on our latest feature Access Control. We’re happy to announce that it’s ready for the public!

Start creating rules for who can run a terraform plan and terraform apply by reading up on the documentation and example use cases.

What is Access Control?

Access Control can be used to provide a capabilities-based configuration for Terrateam Plan and Apply operations. The configuration defines a set of capabilities.

Capabilities

Access Control capabilities define who can do what when. For example, a capability could define who can trigger a Terrateam Plan or Apply operation.

Capabilities are included in each policy. Here are the main capabilities:

• apply: Define who can trigger a terraform apply.
• apply_autoapprove: Define who can trigger a terraform apply -auto-approve.
• apply_force: Define who can trigger a terraform apply bypassing Apply Requirements.
• plan: Define who can trigger a terraform plan.

Real-world scenarios

There are many reasons why an organization would want to implement access controls against their Terraform resources. Whether it be compliance, best practices, or other concerns, our Access Control feature is flexible enough to control selective restriction of access against Terraform resources.

Using the Terrateam runtime configuration, many Access Control policies can be defined.

These configurations also use [Dirs](/docs/features/directories-and-globs) and [Tags](/docs/features/tags) to target Terraform resources.

Everyone can plan. SRE can only apply.

access_control:
  enabled: true
  policies:
    - tag_query: '' # Match all Terraform resources
      plan: ['*']
      apply: ['team:sre']

Everyone can plan and apply in QA. SRE can only plan and apply in Production.

# Tag ./ec2/qa and ./ec2/production directories so we
# can reference them later.
dirs:
  ec2/qa:
    tags: [ec2, qa]
  ec2/production:
    tags: [ec2, production]
access_control:
  enabled: true
  policies:
    - tag_query: ec2 qa # Match Terraform resources in ./ec2/qa
      plan: ['*']
      apply: ['*']
    - tag_query: ec2 production # Match Terraform resources in ./ec2/production
      plan: ['*']
      apply: ['team:sre']

SRE can bypass Apply Requirements. Everyone else has to play by the rules.

access_control:
  enabled: true
  policies:
    - tag_query: '' # Match all Terraform resources
      plan: ['*']
      apply: ['*']
      apply_force: ['team:sre']

Members of Engineering can Apply only when an SRE has approved

access_control:
  policies:
    - tag_query: ''
      apply: []
      superapproval: ['team:sre']
      apply_with_superapproval: ['team:engineering']

Managing access

GitHub people, teams, and roles can be used in a ruleset for a policy. This includes:

• GitHub Users
• GitHub Teams
• GitHub Roles

Referencing these subjects in the Access Control section of your Terrateam runtime configuration file makes it possible to quickly create rules for who is capable of triggering a Terrateam operation against specific Terraform resources.

Security considerations

When someone comments on a pull request with a Terrateam command, the Terrateam backend will determine if the user attempting to trigger the operation is permitted to do so.

The Access Control configuration is always sourced from the GitHub repository default branch. This is to prevent a user from circumventing Access Control policies in their feature branch.

A GitHub default branch is usually named `main` or `master`.

Rules

Every capability has a rule. Every rule has a list of rulesets. If any rule matches the user attempting to trigger the operation, the user is granted access.

Rule	Description
*	Matches anyone.
user:<GitHub-username>	Match a GitHub username.
team:<GitHub-teamname>	Match a GitHub teamname.
repo:<GitHub-rolename>	Match a GitHub rolename defined in the repository.

Documentation

See the Access Control documentation for all available configuration options and capabilities.