ci: set persist-credentials: false on checkout steps#3006
Conversation
CodeRabbit repeatedly flags actions/checkout steps for leaving the GITHUB_TOKEN in the runner's git config after checkout, where any later step in the job could read it. Harden every checkout in one pass by setting persist-credentials: false, rather than fixing them one at a time as CodeRabbit notices. This covers 41 read-only checkouts across 14 workflows. The single exception is the release.yaml release-new-version job, whose checkout must keep its credential so the following "Push Git Tag" step can push back to the repo; that checkout is annotated with a comment explaining why it is intentionally left enabled. Fixes NVIDIA#2925 Signed-off-by: Omar Refai <omar@refai.org>
Summary by CodeRabbit
Walkthrough
ChangesCredential Persistence Hardening Across CI/CD Workflows
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~4 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/rest-prepare-build-info.yml:
- Around line 64-69: The checkout step in the workflow is disabling credential
persistence, which can leave later Git operations without auth. Update the
actions/checkout usage in the job that runs the tag fetch so the token remains
available, or explicitly pass a token to the step that runs git fetch --tags
--force. Keep the fix localized to the checkout/fetch sequence in the workflow
and ensure the tag-fetching logic can authenticate in private repositories.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 25d03b74-ee1e-4b28-a46f-6c10ac9b3fb4
📒 Files selected for processing (14)
.github/workflows/build-boot-artifacts.yml.github/workflows/ci.yaml.github/workflows/docker-build.yml.github/workflows/fern-docs-ci.yml.github/workflows/fern-docs-preview-build.yml.github/workflows/promotion.yaml.github/workflows/publish-fern-docs.yml.github/workflows/release.yaml.github/workflows/rest-build-binaries.yml.github/workflows/rest-build-push-service.yml.github/workflows/rest-ci.yml.github/workflows/rest-helm-workflows.yml.github/workflows/rest-lint-and-test.yml.github/workflows/rest-prepare-build-info.yml
| - name: Checkout code | ||
| uses: actions/checkout@v4 | ||
| with: | ||
| persist-credentials: false | ||
| fetch-depth: 0 | ||
| submodules: recursive |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE=.github/workflows/rest-prepare-build-info.yml
sed -n '64,76p' "$FILE"
echo
rg -n -C2 'git fetch|git submodule' "$FILE"Repository: NVIDIA/infra-controller
Length of output: 799
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE=.github/workflows/rest-prepare-build-info.yml
echo "=== workflow header ==="
sed -n '1,120p' "$FILE"
echo
echo "=== checkout/auth-related lines ==="
rg -n -C3 'actions/checkout|persist-credentials|fetch-depth|git fetch|git describe|tags' "$FILE"Repository: NVIDIA/infra-controller
Length of output: 6821
🌐 Web query:
actions/checkout persist-credentials false git fetch private repository credential removal documentation
💡 Result:
In GitHub Actions, the persist-credentials input for actions/checkout determines whether the authentication token used for the repository checkout is stored in the local Git configuration of the runner [1][2]. When persist-credentials is set to true (which has historically been the default), the action configures the local.git/config file with the necessary credentials [1][3]. This allows subsequent steps in the same job to execute authenticated Git commands without needing to explicitly provide a token [1][4]. These credentials are removed during the post-job cleanup process [1][2]. When persist-credentials is set to false, the action does not configure these credentials in the local Git configuration [1][4]. Consequently, if your workflow requires further Git operations that must authenticate with the remote repository (such as pushing changes or fetching additional data), those operations may fail unless you provide authentication tokens explicitly through other means [4]. Setting persist-credentials: false is often recommended as a security best practice, especially in workflows triggered by events that have access to sensitive repository permissions (such as pull_request_target or workflow_run), to prevent untrusted code in subsequent steps from easily reading the token from the disk [3]. Summary of behavior: - persist-credentials: true (default in many versions): Credentials are written to.git/config for use by later steps and removed during post-job cleanup [1][2]. - persist-credentials: false: Credentials are not written to.git/config, preventing implicit access by subsequent steps [1][4][3]. Documentation for actions/checkout confirms that this input exists specifically to allow users to opt-out of credential persistence [1][5]. While community discussions have explored changing the default to false to improve security, users should explicitly set this to false when security auditing or risk mitigation requires preventing implicit token availability [6][7][3].
Citations:
- 1: https://github.com/actions/checkout
- 2: https://github.com/actions/checkout/blob/main/README.md
- 3: https://pipefort.mintlify.app/rules/cicd-sec-1-checkout-persist-credentials
- 4: https://github.github.com/gh-aw/reference/checkout/
- 5: https://github.com/marketplace/actions/checkout?version=v3.6.0
- 6: Remove
persist-credentialsor change the default tofalseactions/checkout#485 - 7: [security] Escalate concerning default
persist-credentials=trueplease actions/checkout#2312
Restore auth for the tag fetch. With persist-credentials: false, the checkout token is not available to later Git commands, so git fetch --tags --force can fail in private repositories. Keep credentials persisted for this job or pass an explicit token to the fetch step.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/rest-prepare-build-info.yml around lines 64 - 69, The
checkout step in the workflow is disabling credential persistence, which can
leave later Git operations without auth. Update the actions/checkout usage in
the job that runs the tag fetch so the token remains available, or explicitly
pass a token to the step that runs git fetch --tags --force. Keep the fix
localized to the checkout/fetch sequence in the workflow and ensure the
tag-fetching logic can authenticate in private repositories.
Source: Path instructions
|
/ok to test f328b21 |
🔐 TruffleHog Secret Scan✅ No secrets or credentials found! Your code has been scanned for 700+ types of secrets and credentials. All clear! 🎉 🕐 Last updated: 2026-06-30 17:56:32 UTC | Commit: f328b21 |
🔍 Container Scan Summary
Per-CVE detail lives in the per-service |
3 participants
Harden every
actions/checkoutstep by settingpersist-credentials: false, so theGITHUB_TOKENis no longer written to the runner's.git/configafter checkout — where any later step in the same job could read it. This resolves the recurring CodeRabbit findings in one pass instead of fixing them one at a time as they come up.Related issues
Fixes #2925
Type of Change
Breaking Changes
Testing
All 20 workflow files were validated to still parse as YAML after the change.
Additional Notes
persist-credentials: false.release-new-versionjob inrelease.yaml, whose checkout credential is consumed by the following Push Git Tag step (it pushes back to the repo). That checkout is left enabled and annotated with an inline comment so it is not "hardened" later by mistake.persist-credentialshardening that CodeRabbit flags. Other possible lockdowns (pinning actions to commit SHAs, tightening per-workflowpermissions:blocks) are left out to keep this PR single-purpose and easy to review — happy to follow up separately if those are wanted.