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
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.
What are the commands?
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
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
terrateam apply-autoapprove on a pull request will
execute a Plan and Apply operation in the same workflow execution.
-auto-approve apply option is passed to the
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
The example screenshot below displays the following:
- A pull request with a change to
- No Plan operation triggered (
autoplan -> false)
terrateam-demo-user(a member of
- 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.
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
iamdirectories using a custom tag
dirs: aws/**/iam/**: tags: ["iam"] access_control: policies: - tag_query: 'iam' apply_force: ['team:security']