Github actions credentials security without breaking your workflows

Mon, 11 May 2026 00:00:00 +0000

In the light of the recent Tanstack supply-chain attack, pipeline security has become the priority of several projects.

Mistakes in github actions are tricky to see and can have devastating consequences, through PR-controlled variable injection ¹.

Luckily there are powerful tools to catch them:

One common suggestion from Zizmor is to set persist-credentials: false when using actions/checkout ²

The problem: `persist-credentials: false` + https git commands = boom

If you combine these two ingredients you will be greeted with the error

fatal: could not read Username for 'https://github.com/': No such device or address

Workaround 1: Let `gh` provide credentials

1 - name: Commit and push
2+ env:
3+ GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
4 run: |
5+ gh auth setup-git
6 git commit -m "your message"
7 git push

gh auth setup-git configures git to fetch credentials from the gh command, which in turn reads the token from GH_TOKEN.

This avoids storing it in .git/config (which is what persist-credentials: false protects us from).

⚠️

If you self-host your runner, or use a job with a custom container:, you need to install and set up the gh cli yourself. https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-github-cli

Workaround 2: Inject the token into the remote URL (and clean it after)

 1 - name: Commit and push
 2 env:
 3 GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 4 run: |
 5 git commit -m "your message"
 6+ git remote set-url origin "https://x-access-token:${GH_TOKEN}@github.com/${{ github.repository }}"
 7 git push
 8
 9+ # Embedding the token in the remote URL writes it to `.git/config`, 
10+ # so we reset the URL after pushing.
11+ git remote set-url origin "https://github.com/${{ github.repository }}"

⚠️

If git push fails, the credentials stay in .git/config. This is an unlikely attack vector but workaround 1 is safer.

Recipe: docker + crontab

Mon, 11 May 2026 00:00:00 +0000

Prerequisite: if you start from a base image, is it based on alpine or debian?

The syntax is not the same because debian uses cron ¹ while alpine uses crond ².

Check with:

$ docker run --rm ghcr.io/borgmatic-collective/borgmatic:latest cat /etc/os-release

Output:
NAME="Alpine Linux"

1. From a fresh Debian/Ubuntu base (`crontab`)

Dockerfile

1FROM debian:bookworm-slim
2
3RUN apt-get update && apt-get install -y cron && rm -rf /var/lib/apt/lists/*
4
5COPY entrypoint.sh /entrypoint.sh
6RUN chmod +x /entrypoint.sh
7ENTRYPOINT ["/entrypoint.sh"]

entrypoint.sh

1#!/bin/sh
2set -e
3
4(printenv | grep -v "^_="; echo "0 2 * * * /my/script.sh >> /var/log/cron.log 2>&1") | crontab -
5
6exec cron -f

Unlike with alpine, the environment variables are not available to the script if you miss the printenv part ³

2. From an existing image, based on Alpine: example of borgmatic (`crond`)

compose.yaml

1services:
2 borgmatic:
3 build: ./borgmatic

borgmatic/Dockerfile

1FROM ghcr.io/borgmatic-collective/borgmatic:latest
2
3COPY entrypoint.sh /entrypoint.sh
4RUN chmod +x /entrypoint.sh
5ENTRYPOINT ["/entrypoint.sh"] 
6CMD []

borgmatic/entrypoint.sh

1#!/bin/sh
2set -e
3
4borgmatic init ... # Because we override the entrypoint, we need to insert the commands that it would have ran
5
6# 2 AM
7echo "0 2 * * * borgmatic 2>&1 | tee -a /var/log/cron.log" > /etc/crontabs/root
8
9exec crond -f

Unlike with Debian, environment variables are inherited. No tricks needed ⁴

Troubleshooting

Does the script work inside the container?

Trigger the script manually: docker exec <container> /my/script.sh

Does the cron trigger?

Check if the cron is firing: run it every minute using * * * * * and add a log: echo "$(date) cron fired" >> /var/log/cron.log; /my/script.sh

⚠️

Note: output goes to /var/log/cron.log only, and will not show up in docker logs <container>. Instead use docker exec <container> tail -n 500 -f /var/log/cron.log

Blog on Yann Pellegrini

Github actions credentials security without breaking your workflows

The problem: persist-credentials: false + https git commands = boom

Workaround 1: Let gh provide credentials

Workaround 2: Inject the token into the remote URL (and clean it after)

Recipe: docker + crontab

Prerequisite: if you start from a base image, is it based on alpine or debian?

1. From a fresh Debian/Ubuntu base (crontab)

2. From an existing image, based on Alpine: example of borgmatic (crond)

Troubleshooting

The problem: `persist-credentials: false` + https git commands = boom

Workaround 1: Let `gh` provide credentials

1. From a fresh Debian/Ubuntu base (`crontab`)

2. From an existing image, based on Alpine: example of borgmatic (`crond`)