Require Atmos Pro Authorization Before Environment Jobs Start
Erik Osterman
CEO & Founder of Cloud Posse
|
Erik Osterman
CEO & Founder of Cloud Posse
Erik is the founder of Cloud Posse and creator of Atmos. With over a decade of experience helping teams adopt Terraform at scale, he is passionate about open-source infrastructure tooling and developer experience.
Require deployments to go through Atmos Pro. When you enable its protection rule
on a GitHub environment, GitHub pauses each protected job and sends Atmos Pro a webhook
before allowing it to start.
Atmos Pro checks the webhook's run ID against its own dispatch records. If Atmos
Pro didn't dispatch that run, it rejects the deployment—including workflows started
manually from main through GitHub or the CLI. The webhook doesn't expose workflow
inputs; the run ID connects it to the exact SHA recorded at dispatch. Before approving,
Atmos Pro verifies that SHA against the originating GitHub event or authenticated GitHub API
evidence. Uploaded metadata alone cannot authorize a deployment.
Existing CLI uploads, including user-token authentication, remain compatible. Accepting an
upload or dispatching a workflow does not grant permission to start a protected job.
Atmos Pro also checks that SHA against the environment's allowed branches through GitHub.
An unmerged PR cannot target a main-only production environment, even when its workflow
runs from main. With default-branch dispatch, PR plans need an environment that permits
both the default branch and their PR branches. Default-branch dispatch remains the repository default; opting into PR-branch dispatch changes the workflow
source, without weakening this check.
With PR-branch dispatch enabled, pinned approval previews follow the verified PR branch, and merge-queue
workflows use GitHub's queue branch. Both retain SHA ancestry checks and require an environment that permits
their dispatch branch. After a PR merges, its approval preview uses the default branch workflow
while retaining the exact merge SHA and originating GitHub event. A newer branch tip cannot
silently replace the commit being reviewed.
Atmos Pro records approvals, rejections, verification failures, and whether GitHub accepted
the decision in the workspace audit log. Each entry identifies the run, environment, requested
SHA, source event, and reason. An audit-storage failure prevents approval and triggers a
rejection attempt; application logs report the failure.
GitHub’s required human approvals remain an additional gate. We recommend enabling Prevent self-review and
disabling administrator bypass, as shown below.
Environments/Configure plat-prod
Deployment protection rules
Configure reviewers, timers, and custom rules that must pass before deployments to this environment can proceed.
Required reviewers
Specify people or teams that may approve workflow runs when they access this environment.
Add up to 5 more reviewers
Search for people or teams...
acme/managers
Prevent self-review
Require a different approver than the user who triggered the workflow run.
Wait timer
Set an amount of time to wait before allowing deployments to proceed.
Atmos Pro
Custom protection rule provided by Atmos Pro.
Enable additional custom rules with GitHub Apps Preview
Learn about existing apps or create your own protection rules so you can deploy with confidence.
Allow administrators to bypass configured protection rules
Deployment branches and tags
Limit which branches and tags can deploy to this environment.
1 branch and 0 tags allowed
main
Currently applies to 1 branch
Add deployment branch or tag rule
Example settings. Make these changes in your repository on GitHub.
For private/internal repositories, the App rule requires GitHub Enterprise. Follow the
environment setup guide to enable it. If it's
missing on an environment identified in Atmos workflow inputs or observed on an Atmos-dispatched job,
admins see a security finding under Repairs, with a GitHub settings link and Recheck.
Unrelated environments, such as GitHub Pages or Copilot, are excluded. Check hardcoded or dynamically
selected environments in GitHub before first use; Repairs cannot verify targets it has not discovered.
For discovered targets, the finding resolves only after Atmos Pro verifies that its rule is enabled;
until then, it cannot block deployments started directly in GitHub. Older runs without verified source
records must be dispatched again.
