AtlasHorizon PKI-trusted base images

Upstream OS bases with the AtlasHorizon PKI installed in the native system trust store. That is the only change.

Images are built from current CAs fetched at build/CI time from http://pki.atlashorizon.net/certs/. Generated PEMs are not committed.

Images

Image	Upstream
git.atlashorizon.net/atlashorizon/container-base/debian:trixie	debian:trixie
git.atlashorizon.net/atlashorizon/container-base/debian-slim:trixie	debian:trixie-slim
git.atlashorizon.net/atlashorizon/container-base/ubuntu:24.04	ubuntu:24.04
git.atlashorizon.net/atlashorizon/container-base/alpine:3.24	alpine:3.24

On main, each family also gets a :latest tag (debian:latest, debian-slim:latest, ubuntu:latest, alpine:latest).

FROM git.atlashorizon.net/atlashorizon/container-base/debian-slim:trixie
FROM git.atlashorizon.net/atlashorizon/container-base/ubuntu:24.04
FROM git.atlashorizon.net/atlashorizon/container-base/alpine:3.24

Certificates

scripts/refresh-certs.sh downloads and converts (DER → PEM when needed):

• Root: http://pki.atlashorizon.net/certs/AtlasHorizonRootCA.crt (never /root.crt)
• Enterprise: http://pki.atlashorizon.net/certs/AtlasHorizon%20Enterprise%20CA.crt
• Issuing: http://pki.atlashorizon.net/certs/AtlasHorizon%20Issuing%20CA.crt

into certs/AtlasHorizon-*-CA.crt. Those files are gitignored. The Gitea Action runs the script after checkout and builds from the local workspace (source: .) so the fetched PEMs are actually in the image. The default Bake Git context would omit them.

Locally:

sh scripts/refresh-certs.sh
docker buildx bake

Requires curl and openssl.

Gitea Actions and registry

.gitea/workflows/container.yml fetches the CAs, builds all four images with Bake, and publishes to this Gitea instance’s OCI registry.

On main, version tags (v*), and manual Run workflow:

git.atlashorizon.net/atlashorizon/container-base/debian:trixie
git.atlashorizon.net/atlashorizon/container-base/debian:latest    # default branch only
git.atlashorizon.net/atlashorizon/container-base/debian:sha-<short-sha>
git.atlashorizon.net/atlashorizon/container-base/debian:manual   # workflow_dispatch

(and the same tag set for debian-slim, ubuntu, alpine).

The host is taken from the Actions server URL (or vars.REGISTRY if you set one). The image prefix is {registry}/{owner}/{repo} in lowercase, which is what Gitea’s container registry requires.

Pull requests build the images but do not push.

One-time Gitea setup

1. Enable Actions on the repository (Settings → Actions).
2. Enable Packages for the owner (user or org) if it is not already on.
3. Register an act_runner that can build images: Docker socket or privileged dind. A label matching runs-on: ubuntu-latest is enough.
4. If actions/checkout@v4 and the Docker actions cannot be fetched, either set Gitea [actions].DEFAULT_ACTIONS_URL = github or mirror those actions onto this instance and change the uses: lines.

Gitea job tokens (GITEA_TOKEN) cannot log into the container registry. Create a personal access token with package read and write (and repository read if the images are private) and add it as a secret on this repo or the AtlasHorizon org:

Secret	Purpose
REGISTRY_TOKEN	Required. PAT used for docker login
REGISTRY_USERNAME	User that owns the PAT. Set this if it is not the user who triggered the workflow

Variable	Purpose
REGISTRY	Registry host if it is not the Gitea web hostname

A Get "https://git.atlashorizon.net/v2/": unauthorized failure means the PAT is missing, has the wrong scopes, or REGISTRY_USERNAME does not match the token owner. Copying REGISTRY_TOKEN from another repo (for example cert-portal) onto this org/repo is enough if that token already works.

docker login git.atlashorizon.net
docker pull git.atlashorizon.net/atlashorizon/container-base/debian-slim:trixie