From 1360f296f90d0a8f67e4424f4eae74e80ac0c852 Mon Sep 17 00:00:00 2001 From: hermes Date: Mon, 9 Nov 2026 11:02:32 +1000 Subject: [PATCH] ci: drop the kubeconfig from the build job The independent review flagged that the build job wrote the `KUBEC_CONFIG_BUILDX` secret to disk even though the build does not need cluster access at all. That secret is cluster-admin-equivalent: a build step that never talks to the cluster should not be able to read it, and a compromised dependency in the build would otherwise have a direct path to the cluster. The "Create Kubeconfig" step is removed from the build job. The deploy step, added in a later PR, gets its own job with the kubeconfig - so the privilege is only present where it is actually used. --- .gitea/workflows/build_push.yml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/.gitea/workflows/build_push.yml b/.gitea/workflows/build_push.yml index deaec02..d7f41b6 100644 --- a/.gitea/workflows/build_push.yml +++ b/.gitea/workflows/build_push.yml @@ -28,6 +28,11 @@ jobs: . .venv/bin/activate python -m pytest tests/ -q + # NOTE: the build job deliberately does NOT have a kubeconfig. The + # `KUBEC_CONFIG_BUILDX` secret is cluster-admin-equivalent, and a build step + # that has no need of the cluster should not be able to read it. The deploy + # step, added in a later PR, gets its own job with the kubeconfig - that way + # a compromised dependency in the build cannot reach the cluster. build: name: Build and push image runs-on: ubuntu-latest @@ -39,11 +44,6 @@ jobs: - name: Checkout uses: actions/checkout@v4 - - name: Create Kubeconfig - run: | - mkdir -p $HOME/.kube - echo "${{ secrets.KUBEC_CONFIG_BUILDX }}" > $HOME/.kube/config - - name: Set up Docker Buildx (remote -> persistent buildkit daemon) uses: docker/setup-buildx-action@v3 with: