Skip to content

fix: Prevent any users from approving custom policy sets #5331

Closed
bgalkows wants to merge 23 commits intorunatlantis:mainfrom
bgalkows:main
Closed

fix: Prevent any users from approving custom policy sets #5331
bgalkows wants to merge 23 commits intorunatlantis:mainfrom
bgalkows:main

Conversation

@bgalkows
Copy link
Copy Markdown
Contributor

@bgalkows bgalkows commented Feb 14, 2025

what

  • Propagates policy set names to custom policy sets properly instead of defaulting all custom checks to an undefined set called "Custom"

why

  • Currently, using custom policy tools with Atlantis inadvertently allows any user to successfully execute atlantis approve_policies on the policy check
  • Policy set naming is used to map user permissions for who can approve what, and as a result all users are able to approve the default name which has no restrictions specified
  • For the small community of Atlantis folks leveraging Terraform policy tools other than the integrated Conftest, this change is extremely important
    • Any user being able to bypass any custom policy set is a critical flaw in a controlled actuation workflow

tests

  • I have tested these changes by reproducing the bug where any user can approve the policy set and then confirming it is not possible with this change added
  • I've actually used a fork with this tweak added for a while and never noticed unintended consequences

references

@bgalkows bgalkows requested review from a team as code owners February 14, 2025 06:09
@bgalkows bgalkows requested review from X-Guardian, chenrui333 and nitrocode and removed request for a team February 14, 2025 06:09
@dosubot dosubot bot added bug Something isn't working go Pull requests that update Go code labels Feb 14, 2025
@dimisjim
Copy link
Copy Markdown
Contributor

@bgalkows Amazing, thanks a lot for the contribution. Let me know if I can help in any way, so that this gets merged and released asap!

renovate bot and others added 8 commits February 17, 2025 19:13
…n .github/workflows/lint.yml (main) (runatlantis#5330)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Signed-off-by: Brett Galkowski <bgalkows@uci.edu>
Signed-off-by: Brett Galkowski <bgalkows@uci.edu>
Signed-off-by: Brett Galkowski <bgalkows@uci.edu>
Signed-off-by: Brett Galkowski <bgalkows@uci.edu>
@bgalkows
Copy link
Copy Markdown
Contributor Author

Hey all, from what I can tell the failing unit test is erroring after it can't find Conftest installed in the GitHub runner environment. I see this matching error output in the logs:

// Will fail test if conftest isn't in path
func ensureRunningConftest(t *testing.T) {
// use `conftest` command instead `conftest$version`, so tests may fail on the environment cause the output logs may become change by version.
t.Logf("conftest check may fail depends on conftest version. please use latest stable conftest.")
_, err := exec.LookPath(conftestCommand)
if err != nil {
t.Logf(`%s must be installed to run this test
- on local, please install conftest command or run 'make docker/test-all'
- on CI, please check testing-env docker image contains conftest command. see testing/Dockerfile
`, conftestCommand)
t.FailNow()
}
}

Would anyone be able to help resolve this? testing/Dockerfile does have commands to install Conftest.

And @dimisjim, any input is appreciated if you're interested! Feel free to add commits or create your own PR if that's the easier

@dimisjim
Copy link
Copy Markdown
Contributor

@bgalkows Would this still fix the issue with approvals (should only mark the policy as approved if an owner approves it), even if the policy_check run step under the custom workflow definition in the repo's atlantis.yaml contains the --no-fail flag? This is necessary to have, according to my tests, alongside -o table flag, so that policy is treated as a custom one and I don't get: unable to unmarshal conftest output.

My conftest cmd looks like: conftest test </path/to/inputs.json> -p <path/to/my/rego/policy> -o table --no-fail

@bgalkows
Copy link
Copy Markdown
Contributor Author

@bgalkows Would this still fix the issue with approvals (should only mark the policy as approved if an owner approves it), even if the policy_check run step under the custom workflow definition in the repo's atlantis.yaml contains the --no-fail flag? This is necessary to have, according to my tests, alongside -o table flag, so that policy is treated as a custom one and I don't get: unable to unmarshal conftest output.

My conftest cmd looks like: conftest test </path/to/inputs.json> -p <path/to/my/rego/policy> -o table --no-fail

@dimisjim The custom policy checks are intended for non-Conftest policy tooling, so i've never actually used a custom check which runs Conftest. If you're using Conftest and getting unable to unmarshal conftest output, that would be related to a different bug as I understand it. Is it perhaps that the -o table flag is unsupported by Atlantis, confounding the output parsing?

To answer your question though, yes - this change will fix any user being able to approve the custom policy check regardless of what the run step actually contains.

@dimisjim
Copy link
Copy Markdown
Contributor

Is it perhaps that the -o table flag is unsupported by Atlantis, confounding the output parsing?

actually -o table is the only output type that works for me.

The reason why I am using a custom policy, but still conftest is to include more than one input into the rego policy, basically following this example: https://www.runatlantis.io/docs/policy-checking#running-policy-check-against-terraform-source-code In my case it's not to test against terraform code directly but rather inject an input concerning multiple custom workflows, taken by a pre-workflow script.

@dimisjim
Copy link
Copy Markdown
Contributor

@jamengual , @X-Guardian , @nitrocode, @chenrui333 Could you help out?

I would like to test this before merging. Is there any atlantis image I could use built from this PR?

@nitrocode
Copy link
Copy Markdown
Member

For your own container

  1. Merge your feature branch to your fork's main branch (looks like you already did)
  2. Cut a release from your fork

This will create a container and upload it to your fork's ghcr and allow you to test that container e2e in your deployment.

@dimisjim
Copy link
Copy Markdown
Contributor

@nitrocode, @bgalkows

I can confirm that it works with my setup too, after forking the repo, basing it on v0.33.0 and cherry picking the changes of this branch 🚀

@X-Guardian
Copy link
Copy Markdown
Contributor

The policy check tests in events_controller_e2e_test.go are failing on this change and need fixing.

When using custom policy checks, ensure we don't access inputPolicySets
out of bounds when iterating over outputs. If there are more outputs
than policy sets, fallback to 'Custom' as the policy set name.

This prevents potential index out of range panics when the number of
outputs exceeds the number of configured policy sets.

Signed-off-by: Pepe Amengual <pepe.amengual@example.com>
Signed-off-by: PePe Amengual <2208324+jamengual@users.noreply.github.com>
@github-actions
Copy link
Copy Markdown

This issue is stale because it has been open for 1 month with no activity. Remove stale label or comment or this will be closed in 1 month.

@github-actions github-actions bot added the Stale label Sep 13, 2025
@jamengual jamengual removed the Stale label Sep 13, 2025
@waqaskayani
Copy link
Copy Markdown

Waiting for this to be merged, much needed. 🙏

@github-actions
Copy link
Copy Markdown

This issue is stale because it has been open for 1 month with no activity. Remove stale label or comment or this will be closed in 1 month.

@github-actions github-actions bot added the Stale label Oct 19, 2025
@dimisjim
Copy link
Copy Markdown
Contributor

bump

@github-actions github-actions bot removed the Stale label Oct 20, 2025
@bruceoutdoors
Copy link
Copy Markdown

bump

@jamengual
Copy link
Copy Markdown
Contributor

the test will need to pass for this pr to be merged.

@dimisjim
Copy link
Copy Markdown
Contributor

Can you check this one here please and let me know if this is fine in terms of tests additions and fixes? #5915

Thanks 🙏

@github-actions
Copy link
Copy Markdown

This issue is stale because it has been open for 1 month with no activity. Remove stale label or comment or this will be closed in 1 month.

@github-actions github-actions bot added the Stale label Nov 30, 2025
@jamengual jamengual added waiting-on-review Waiting for a review from a maintainer and removed Stale waiting-on-response Waiting for a response from the user labels Nov 30, 2025
@dimisjim
Copy link
Copy Markdown
Contributor

dimisjim commented Dec 9, 2025

This can now be closed as this one is merged: #5915

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working conftest-policy go Pull requests that update Go code needs tests Change requires tests waiting-on-review Waiting for a review from a maintainer

Projects

None yet

Development

Successfully merging this pull request may close these issues.

10 participants