harbor

• 1:
• 2:
• 3: Ansible
• 4: cl
• 5: Tf
• 6: Tf setup

1 -

Harbor infrastructure specification

Purpose

Describe the Harbor registry infrastructure owned by infra/harbor, spanning Proxmox setup, K3s host configuration, Flux-managed chart declarations, and Harbor service Terraform. The tf_setup, ansible, cl, and tf packages are implementation stages of this owner. This is a checked-in source baseline, without an observation of live registry availability or deployment success.

Baseline revision: 550d7e79b1f5fdbc2b6017b75178471d6914082f. Observed: 2026-09-08. Sources: owner README, BUILD, and the implementation links below.

Requirements

Requirement: Dedicated K3s registry host

Setup SHALL declare a Proxmox VM in the src_infra_harbor pool with two cores, 4096 MiB memory, and 20 GiB boot, 20 GiB K3s data, and 40 GiB K3s storage disks. Ansible SHALL apply the shared host and K3s roles with K3s secrets encryption enabled. Its firewall variables SHALL scope API port 6443 access to the declared Flux host address.

Sources: VM definition, deployment playbook, K3s configuration, and host variables.

Scenario: Inspect management API access

• WHEN the Harbor host configuration is evaluated
• THEN the API-port firewall entry identifies the Flux source address
• AND the K3s configuration enables secrets encryption and disables bundled Traefik

Requirement: Remote Flux chart reconciliation

The Harbor Flux manifests SHALL declare a remote-cluster Kustomization and HelmRelease using src-infra-harbor-cl-kubeconfig. The HelmRelease SHALL pin its chart version, enable Helm tests and drift detection, set https://harbor.alwaldend.com as the external URL, and use the local-path storage class for its declared persistent components.

Source: Harbor Flux manifests.

Scenario: Inspect the Harbor release declaration

• WHEN a maintainer evaluates the Harbor HelmRelease
• THEN the source selects a specific chart version and the remote Harbor cluster configuration
• AND tests, drift detection, external URL, and persistent storage choices are explicit

Requirement: Vault-backed registry identity configuration

Harbor service Terraform SHALL configure Vault OIDC authentication using client credentials from the Vault provider, the groups claim, and the src_infra_harbor_admins administrator group. It SHALL enable automatic onboarding and use the username claim for users.

Source: authentication configuration. The baseline sets oidc_verify_cert = false with a CA-issues comment; this specification does not claim that OIDC server certificate verification is enabled.

Scenario: Resolve OIDC identity settings

• WHEN the service Terraform authentication resource is inspected
• THEN it references Vault-provided client credentials and the configured user and group claims
• AND its certificate-verification setting remains visible as a baseline limitation

Requirement: Registry projects and guest access

Service Terraform SHALL declare an alwaldend project with vulnerability scanning and automatic SBOM generation, plus a dockerhub proxy-cache project linked to the Docker Hub registry. Both projects SHALL grant the configured src_infra_harbor_users OIDC group the guest role.

Sources: first-party project and Docker Hub proxy.

Scenario: Inspect registry consumer permissions

• WHEN the managed registry projects are evaluated
• THEN alwaldend enables scanning and SBOM generation, while dockerhub references the Docker Hub proxy registry
• AND both group membership resources specify guest access

2 -

owned-dns Specification

Purpose

Define Harbor DNS management through the owner’s tf_setup root, including canonical declarations, scoped credentials, and offline source checks before adopting live records.

Requirements

Requirement: Owner-local DNS configuration

The tf_setup root SHALL consume this owner’s canonical dnsconfig.json through the shared DNS Terraform module, preserving declared record identities and views. DNS resources SHALL default to disabled before adoption and SHALL default to enabled in the reviewed adoption revision and after adoption. Adoption SHALL import the exact existing provider records and require a scoped no-change import plan before saved-plan apply. Subsequent reconciliation with unchanged root inputs SHALL preserve adopted records, unrelated DNS records, and non-DNS resources in the root.

Scenario: Inspect the preparatory configuration

• WHEN the checked-in root is evaluated with default inputs before adoption
• THEN it reads this owner’s declaration and disables managed DNS records
• AND the package contains the module and declaration inputs

Scenario: Inspect the adopted default

• WHEN the reviewed adoption revision or an adopted root is evaluated with default inputs
• THEN it reads this owner’s declaration and enables managed DNS records
• AND enabled ownership remains the default after import

Scenario: Adopt existing records

• WHEN this owner applies a reviewed saved import plan through //infra/harbor/tf_setup:dns.apply
• THEN each existing provider record is imported at its exact owner-local address
• AND a reviewed adoption plan proposes no record additions, changes, replacements, or deletions before apply

Scenario: Reconcile unchanged declarations

• WHEN the adopted root reconciles unchanged canonical declarations and root inputs
• THEN the plan proposes no changes to the adopted DNS records
• AND unrelated DNS records and non-DNS resources in the root remain unchanged

Requirement: Scoped DNS execution and offline checks

The DNS wrappers SHALL select src_infra_harbor through the repository AL flow and keep secret values in injected variables. The dns.plan, dns.show, and dns.apply targets SHALL select dns=1 and retain the owner’s setup backend; plans SHALL target module.dns and apply SHALL require a reviewed saved plan. Ordinary setup wrappers SHALL retain their service authentication behavior. Real DNS credentials and Vault policy grants SHALL be prerequisites for operational Terraform calls. RouterOS DNS credentials SHALL remain isolated from unrelated RouterOS resources. The package SHALL expose a format test without live credentials. DNS-targeted validation SHALL NOT establish unrelated VM or service health.

Scenario: Validate the Terraform source

• WHEN the package format test executes
• THEN it checks the packaged Terraform configuration without live credentials
• AND existing non-DNS authentication and backend paths remain unchanged

Scenario: Prepare an operational Terraform invocation

• WHEN an authorized operator selects the owner’s DNS wrapper
• THEN it selects DNS credential injection through the owner AppRole and setup backend
• AND its scoped plan and saved-plan apply cover DNS and its dependencies
• AND disabled DNS resources do not imply offline provider configuration

3 - Ansible

4 - cl

5 - Tf

6 - Tf setup

This root owns the Harbor DNS declaration. DNS ownership defaults to enabled after verified adoption; keep it enabled to retain the managed records.

Use //infra/harbor/tf_setup:dns.plan, :dns.show, and :dns.apply for scoped DNS reconciliation. These targets retain the setup backend and src_infra_harbor AppRole, select dns=1, and target module.dns. Apply requires a reviewed saved plan. Reconciliation of unchanged declarations must produce no DNS changes.

The ordinary setup targets retain their service authentication behavior. DNS checks do not establish PVE VM or service health; current aggregate source validation remains part of repository delivery.