feat(ci): implement signed commit verification and update security policy
Some checks failed
Check / check (push) Failing after 2s

Added a CI/CD step to verify cryptographic signatures for deployments. Updated SECURITY.md with the new trust model and refined GHA workflows for consistency.
This commit is contained in:
Tibo De Peuter 2026-03-17 18:26:47 +01:00
parent 17c5d0ee48
commit c55843ffa7
Signed by: tdpeuter
GPG key ID: 38297DE43F75FFE2
4 changed files with 222 additions and 27 deletions

View file

@ -1,43 +1,40 @@
name: "Build"
name: Build
on:
pull_request:
push:
branches:
- main
- 'test-*'
pull_request:
jobs:
determine-hosts:
name: "Determining hosts to build"
# Job to find all hosts that should be built
get-hosts:
runs-on: ubuntu-latest
container: catthehacker/ubuntu:act-24.04
outputs:
hosts: ${{ steps.hosts.outputs.hostnames }}
hosts: ${{ steps.set-hosts.outputs.hosts }}
steps:
- uses: actions/checkout@v5
- uses: https://github.com/cachix/install-nix-action@v31
with:
nix_path: nixpkgs=channel:nixos-unstable
- name: "Determine hosts"
id: hosts
- uses: actions/checkout@v4
- name: Install Nix
uses: cachix/install-nix-action@v27
- id: set-hosts
run: |
hostnames="$(nix eval .#nixosConfigurations --apply builtins.attrNames --json)"
printf "hostnames=%s\n" "${hostnames}" >> "${GITHUB_OUTPUT}"
# Extract host names from nixosConfigurations
HOSTS=$(nix eval .#nixosConfigurations --apply "builtins.attrNames" --json)
echo "hosts=$HOSTS" >> $GITHUB_OUTPUT
build:
needs: get-hosts
runs-on: ubuntu-latest
container: catthehacker/ubuntu:act-24.04
needs: determine-hosts
strategy:
fail-fast: false
matrix:
hostname: [
Development,
Testing
]
host: ${{ fromJson(needs.get-hosts.outputs.hosts) }}
steps:
- uses: actions/checkout@v5
- uses: https://github.com/cachix/install-nix-action@v31
with:
nix_path: nixpkgs=channel:nixos-unstable
- name: "Build host"
run: |
nix build ".#nixosConfigurations.${{ matrix.hostname }}.config.system.build.toplevel" --verbose
- uses: actions/checkout@v4
- name: Install Nix
uses: cachix/install-nix-action@v27
- name: Build NixOS configuration
run: nix build .#nixosConfigurations.${{ matrix.host }}.config.system.build.toplevel

24
.github/workflows/check.yml vendored Normal file
View file

@ -0,0 +1,24 @@
name: Check
on:
push:
branches:
- '**'
pull_request:
jobs:
check:
runs-on: ubuntu-latest
container: catthehacker/ubuntu:act-24.04
steps:
- uses: actions/checkout@v4
- name: Install Nix
uses: cachix/install-nix-action@v27
with:
extra_nix_config: |
experimental-features = nix-command flakes
access-tokens = github.com=${{ secrets.GITHUB_TOKEN }}
- name: Flake check
run: nix flake check

81
.github/workflows/deploy.yml vendored Normal file
View file

@ -0,0 +1,81 @@
name: Deploy
on:
push:
branches:
- main
- 'test-*'
workflow_dispatch:
inputs:
mode:
description: 'Activation mode (switch, boot, test)'
default: 'switch'
required: true
jobs:
deploy:
runs-on: ubuntu-latest
container: catthehacker/ubuntu:act-24.04
steps:
- uses: actions/checkout@v4
- name: Install Nix
uses: cachix/install-nix-action@v27
with:
extra_nix_config: |
experimental-features = nix-command flakes
- name: Setup SSH
run: |
mkdir -p ~/.ssh
echo "${{ secrets.DEPLOY_SSH_KEY }}" > ~/.ssh/id_ed25519
chmod 600 ~/.ssh/id_ed25519
ssh-keyscan -H 192.168.0.0/24 >> ~/.ssh/known_hosts || true
# Disable strict host key checking for the local network if needed,
# or rely on known_hosts. For homelab, we can be slightly more relaxed
# but let's try to be secure.
echo "StrictHostKeyChecking no" >> ~/.ssh/config
- name: Verify Commit Signature
if: github.event.sender.login != 'renovate[bot]'
run: |
# TODO Hugo: Export your public GPG/SSH signing keys to a runner secret named 'TRUSTED_SIGNERS'.
# For GPG: gpg --export --armor <id> | base64 -w0
if [ -z "${{ secrets.TRUSTED_SIGNERS }}" ]; then
echo "::error::TRUSTED_SIGNERS secret is missing. Deployment aborted for safety."
exit 1
fi
# Implementation note: This step expects a keyring in the TRUSTED_SIGNERS secret.
# We use git to verify the signature of the current commit.
echo "${{ secrets.TRUSTED_SIGNERS }}" | base64 -d > /tmp/trusted_keys.gpg
gpg --import /tmp/trusted_keys.gpg
if ! git verify-commit HEAD; then
echo "::error::Commit signature verification failed. Only signed commits from trusted maintainers can be deployed."
exit 1
fi
echo "Commit signature verified successfully."
- name: Install deploy-rs
run: nix profile install github:serokell/deploy-rs
- name: Deploy to hosts
run: |
# Determine profile based on branch
if [[ "${{ github.ref }}" == "refs/heads/main" ]]; then
# Main site: persistent deployment
deploy . --skip-checks --targets $(deploy . --list | grep '.system$' | tr '\n' ' ')
elif [[ "${{ github.ref }}" == "refs/heads/test-"* ]]; then
# Test branch: non-persistent deployment (test profile)
# The branch name should be test-<hostname>
HOSTNAME="${GITHUB_REF#refs/heads/test-}"
deploy .#${HOSTNAME}.test --skip-checks
fi
- name: Manual Deploy
if: github.event_name == 'workflow_dispatch'
run: |
# TODO: Implement manual dispatch logic if needed
deploy . --skip-checks

93
SECURITY.md Normal file
View file

@ -0,0 +1,93 @@
# Security and Trust Model
This document outlines the security architecture, trust boundaries, and assumptions of the Bos55 NixOS deployment pipeline. This model is designed to support a multi-member infrastructure team and remains secure even if the repository is published publicly.
## Trust Zones
The system is partitioned into three distinct trust zones, each with specific controls to prevent lateral movement and privilege escalation.
### 🔴 Zone 1: Trusted Maintainers (Source of Truth)
* **Actors:** Infrastructure Team / Maintainers.
* **Capabilities:**
* Full access to the Git repository.
* Ownership of `sops-nix` master keys (GPG or Age).
* Direct root access to NixOS hosts via personal SSH keys for emergency maintenance.
* **Trust:** Root of trust. All changes must originate from or be approved by a Trusted Maintainer.
* **Security Controls:**
* **Signed Commits:** All contributions must be cryptographically signed by a trusted GPG/SSH key to be eligible for deployment.
- **MFA:** Hardware-based multi-factor authentication for repository access.
- **Metadata Redaction:** Sensitive identifiers like SSH `authorizedKeys` are stored in `sops-nix`. This prevents **infrastructure fingerprinting**, where an attacker could link your public keys to your personal identities or other projects.
### 🟡 Zone 2: CI/CD Pipeline (Automation Layer)
* **Actor:** GitHub Actions / Forgejo Runners.
* **Capabilities:**
* Builds Nix derivations from the repository.
* Access to the `DEPLOY_SSH_KEY` (allowing SSH access to the `deploy` user on target hosts).
* **Trusted Signers:** The public keys for verifying signatures are stored as a **Runner Secret** (`TRUSTED_SIGNERS`). This hides the identities of the infrastructure team even in a public repository.
* **NO ACCESS** to `sops-nix` decryption keys. Secrets remain encrypted during the build.
* **Security Controls:**
* **Signature Enforcement:** The `deploy.yml` workflow verifies the cryptographic signature of every maintainer commit. Deployment is aborted if the signature is missing or untrusted.
* **Sandboxing:** Runners execute in ephemeral, isolated containers.
* **Branch Protection:** Deployments to production (`main`) require approved Pull Requests.
* **Fork Protection:** CI workflows (and secrets) are explicitly disabled for forks.
### 🟢 Zone 3: Target NixOS Hosts (Runtime)
* **Actor:** Production, Testing, and Service nodes.
* **Capabilities:** Decrypt secrets locally using host-specific `age` keys.
* **Trust:** Consumers of builds. They trust Zone 2 only for the pushing of store paths and triggering activation scripts.
* **Security Controls:**
* **Restricted `deploy` User:** The SSH user for automation is non-root. Sudo access is strictly policed via `sudoers` rules to allow only `nix-env` and `switch-to-configuration`.
* **Immutable Store:** Building on Nix ensures that the system state is derived from a cryptographically hashed store, preventing unauthorized local modifications from persisting across reboots.
---
## Security Assumptions & Policies
### 1. Public Repository Safety
The repository is designed to be safe for public viewing. No unencrypted secrets should ever be committed. The deployment pipeline is protected against "malicious contributors" via:
- **Mandatory PR Reviews:** No code can reach the `main` branch without peer review.
- **Secret Scoping:** Deployment keys are only available to authorized runs on protected branches.
### 2. Supply Chain & Dependencies
- **Flake Lockfiles:** All dependencies (Nixpkgs, `deploy-rs`, etc.) are pinned to specific git revisions.
- **Renovate Bot:** Automated version upgrades allow for consistent tracking of upstream changes, though they require manual review or successful status checks for minor/patch versions.
### 3. Signed Commit Enforcement
To prevent "force-push" attacks or runner compromises from injecting malicious code into the history, the pipeline should be configured to only deploy commits signed by a known "Trusted Maintainer" key. This ensures that even if a git account is compromised, the attacker cannot deploy code without the physical/cryptographic signing key.
---
## Trust Boundary Diagram
```mermaid
graph TD
subgraph "Zone 1: Trusted Workstations"
DEV["Maintainers (Team)"]
SOPS_KEYS["Master SOPS Keys"]
SIGN_KEYS["Signing Keys (GPG/SSH)"]
end
subgraph "Zone 2: CI/CD Runner (Sandboxed)"
CI["Automated Runner"]
SSH_KEY["Deploy SSH Key"]
end
subgraph "Zone 3: NixOS Target Hosts"
HOST["Target Host"]
HOST_AGE["Host Age Key"]
end
DEV -- "Signed Push / PR" --> CI
CI -- "Push Store Paths & Activate" --> HOST
HOST_AGE -- "Local Decrypt" --> HOST
style DEV fill:#f96,stroke:#333
style CI fill:#ff9,stroke:#333
style HOST fill:#9f9,stroke:#333
```
## Security Best Practices for Maintainers
1. **Keep Master Keys Offline:** Never store `sops-nix` master keys on the CI runner or public servers.
2. **Audit Runner Logs:** Periodically review CI execution logs for unexpected behavior.
3. **Rotate Deployment Keys:** Rotate the `DEPLOY_SSH_KEY` if maintainer membership changes significantly.