kubernetes-security-baseline-lab/ci/README.md

CIS benchmark scanning

The scan uses the official kube-bench K3s profile, k3s-cis-1.7, against a disposable K3d control-plane node. kube-bench needs host PID access and read-only host mounts because the CIS checks inspect processes, permissions, and node configuration. The job is intentionally separate from the ArgoCD application tree so the scanner cannot become part of the workload baseline.

GitHub Actions creates a disposable one-server K3s cluster, runs the job, stores the JSON report, and prints pass, warn, and fail totals in the workflow summary. The CI topology is intentionally smaller than the developer quick-start topology so it remains reliable on shared runners.

The workflow fails if the scanner job or report generation fails. It does not yet fail on CIS findings because a vanilla K3d cluster is expected to produce findings; later hardening phases can turn selected controls into merge gates.

To run the same scan locally against the active K3d cluster:

kubectl create namespace kube-bench --dry-run=client -o yaml | kubectl apply -f -
kubectl delete job kube-bench -n kube-bench --ignore-not-found
kubectl apply -f ci/kube-bench-k3s-job.yaml
kubectl wait --for=condition=complete job/kube-bench -n kube-bench --timeout=180s
kubectl logs -n kube-bench job/kube-bench > kube-bench-report.json

The benchmark release is pinned in the Job image. Update it deliberately when the benchmark support matrix or K3s version changes.

Gitea Actions support

Gitea Actions can run the same workflow file. Gitea's default workflow search order includes .gitea/workflows and .github/workflows; because this repository has no .gitea/workflows directory, Gitea will discover the existing .github/workflows/kube-bench-scan.yml file. GitHub Actions continues to use that same file.

The Gitea instance must have Actions enabled and an act_runner registered at the repository, organization, or instance level. The runner needs Docker access because the workflow creates a k3d cluster and runs the kube-bench Job. Register a dedicated runner for this repository rather than sharing a runner with unrelated repositories.

Example Docker runner setup, with the registration token supplied separately:

docker run -d \
  --name kubernetes-security-baseline-runner \
  -e GITEA_INSTANCE_URL=https://git.swaphb.com/ \
  -e GITEA_RUNNER_REGISTRATION_TOKEN="$GITEA_RUNNER_REGISTRATION_TOKEN" \
  -e GITEA_RUNNER_NAME=kubernetes-security-baseline \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v gitea-runner-data:/data \
  docker.io/gitea/act_runner:latest

Mounting the Docker socket gives workflow jobs substantial control over the runner host. Use a dedicated disposable runner, restrict its repository scope, and avoid placing unrelated credentials on that host.