Apply Overrides

Besides terrateam plan and terrateam apply, there are other Terrateam Commands you can issue. These commands are called Apply Overrides and they can be used to force Apply operations.

Why do these commands exist?

Terrateam doesn’t own, control, or operate your infrastructure. That’s your job. We’re here to give you a pathway for successful Terraform operations. Sometimes there are situations where users want to override rules defined in the Terrateam configuration file. Particularly, Access Control and Apply Requirements configurations. This is especially useful in the case of emergencies. #hugops

What are the commands?

terrateam apply-force

Commenting terrateam apply-force on a pull request will bypass any and all Apply Requirements that are defined in the Terrateam configuration file.

The example below shows a user issuing two commands. The first command is a terrateam apply which returns a failure due to unmet Apply Requirements. The second command is a terrateam apply-force which bypasses unmet Apply Requirements and results in a successful Apply operation.

terrateam apply-autoapprove

Commenting terrateam apply-autoapprove on a pull request will execute a Plan and Apply operation in the same workflow execution.

The -auto-approve apply option is passed to the terraform command. This option skips the approval step of a plan before applying. As a result, the plan that is generated is automatically applied.

Take the following Terrateam configuration file as an example:

dirs:
  aws/prod/storage:
    when_modified:
      autoplan: false

access_control:
  policies:
    - tag_query: ''
      apply_autoapprove: ['team:developers']

The above configuration instructs Terrateam to disable automatically running a Plan operation when the aws/prod/storage directory has a change in a pull request. Additionally, a custom Access Control rule is configured to allow team developers to issue the apply-autoapprove command.

The example screenshot below displays the following:

• A pull request with a change to aws/prod/storage/main.tf
• No Plan operation triggered (autoplan -> false)
• The terrateam-demo-user (a member of team:developers) commenting terrateam apply-autoapprove
• Terrateam running the operation which forces a Plan and Apply all in one step

Restricted by default

Apply Overrides can be configured using the Access Control configuration. These rules are always read from the repository default branch.

The GitHub default branch can only be modified by administrators of the GitHub repository. Access Control configuration is sourced from the default branch to prevent a user from circumventing defined policies in a feature branch.

Example configurations

There are many different scenarios that could take advantage of Apply Overrides. Granular rules can be configured using Tags and Tag Queries. Here are a few example configurations.

• Team SRE can bypass Apply Requirements

access_control:
  policies:
    - tag_query: ''
      apply_force: ['team:sre']

• Team Developers can bypass Apply Requirements against the QA directory

access_control:
  policies:
    - tag_query: "dir:qa"
      apply_force: ['team:developers']

• Team SRE can run an Apply with Autoapprove and Apply with Force against all pull requests

access_control:
  policies:
    - tag_query: ''
      apply_autoapprove: ['team:sre']
      apply_force: ['team:sre']

• Separate rules for Production, QA, and Development environments by directory

access_control:
  policies:
    - tag_query: 'dir:production'
      apply_autoapprove: ['team:sre']
      apply_force: ['team:sre']
    - tag_query: 'dir:qa'
      apply_autoapprove: ['team:qa', 'team:sre']
      apply_force: ['team:qa', 'team:sre']
    - tag_query: 'dir:development'
      apply_autoapprove: ['*']
      apply_force: ['*']

• Team Security can bypass Apply Requirements for all iam directories using a custom tag

dirs:
  aws/**/iam/**:
    tags: ["iam"]

access_control:
  policies:
    - tag_query: 'iam'
      apply_force: ['team:security']