Server-side config & control

Who can define workflows.

Advanced14 min · lesson 9 of 12

There are two places configuration can live, and the split is a security boundary. Repo-side atlantis.yaml is convenient but editable by anyone who can open a PR. Server-side config (a repos.yaml the operator controls) sets the rules that repos cannot override: which workflows exist, whether repos may define their own, what apply requirements are enforced, and which settings a repo’s atlantis.yaml is even allowed to change. Server-side config is how the operator keeps control.

REPO-SIDE VS SERVER-SIDE CONTROL

Repo-side (atlantis.yaml)

Editable by any PR author

anyone who can open a PR

Picks a workflow

only if allowed_overrides permits

Cannot weaken guardrails

bounded by server config

Server-side (repos.yaml)

Operator-controlled

the real security control

apply_requirements enforced

approved, mergeable

allow_custom_workflows: false

no repo-defined run steps

allowed_overrides

only the settings you trust

Server-side repos.yaml sets the rules repos cannot override; repo-side config is a convenience within its bounds.

repos.yaml (server-side)

repos:
  - id: /.*/
    apply_requirements: [approved, mergeable]   # enforced; repos cannot weaken this
    allowed_overrides: [workflow]                # repos may pick a workflow...
    allow_custom_workflows: false                # ...but NOT define new ones
    workflow: default
  - id: github.com/acme/platform            # trusted repo gets more latitude
    allow_custom_workflows: true

Least privilege for repos

The safe default is restrictive: enforce apply requirements server-side, disallow custom workflows, and permit only the specific overrides you trust — then loosen selectively for repos owned by teams you trust. This prevents a PR from redefining the guardrails it must pass or injecting a malicious run step. Think of repos.yaml as the policy for the automation itself: it decides what the reviewed, credential-holding server will and will not do on behalf of any given repo.

If repos can define workflows, they can run code as Atlantis

allow_custom_workflows: true for an untrusted repo means a PR author can add a run step that executes with the server’s cloud credentials — full compromise via a pull request. Keep it false by default, enforce apply_requirements server-side so a repo cannot self-approve, and grant custom-workflow rights only to repos whose write-access you fully trust. The server-side config is the real security control; repo-side config is a convenience within its bounds.

Policy checks in the flowCredentials & secrets