Hardening the Atlantis server

It holds the keys to your infra.

Advanced14 min · lesson 11 of 12

Because Atlantis executes Terraform with real credentials in response to VCS webhooks, hardening it spans network, identity, and the workflow. Network: put it behind your boundary (it does not need to be public — a private endpoint the VCS webhook reaches via an allowlisted path, or a VCS-hosted runner model), terminate TLS, and restrict who can reach the UI. Identity: the webhook secret and repo allowlist gate inbound events; VCS permissions and apply requirements gate who can apply.

The Atlantis attack surface
inbound
webhook
secret + repo allowlist
UI
restrict access, TLS
execution + outbound
workflows
server-side only for untrusted repos
cloud creds
short-lived, scoped roles
Lock the front door (webhook secret, allowlist), control execution (server-side workflows), minimize credentials (assumed roles).

The whole chain

Put it together: authenticate and allowlist webhooks, keep the UI private and TLS-only, define workflows server-side and forbid custom ones for untrusted repos, enforce approval + mergeable apply requirements centrally, run with short-lived scoped cloud roles, fetch secrets at run time, protect state, and keep Atlantis patched. Each control closes one path; together they make the credential-holding automation server as hard to abuse as the infrastructure it manages. Audit its logs — every plan and apply is a security event.

An exposed or over-privileged Atlantis is a cloud takeover
The failure modes compound: a public UI or unauthenticated webhook lets attackers trigger runs; custom workflows let a PR run code; long-lived broad credentials make any of that catastrophic. Harden all three layers — inbound (secret + allowlist + private + TLS), execution (server-side workflows, enforced approvals), and credentials (short-lived scoped roles) — because a weakness in any one turns the tool that applies your infrastructure into the tool that compromises it.