This is the multi-page printable view of this section.
Click here to print.
Return to the regular view of this page.
ingress
ingress
Run ansible
bazel run //infra/ingress/ansible
Services in traefik_services must use a backend target that resolves from
the ingress hosts without resolving back to ingress. Define a dedicated
site-local address, conventionally prefixed with dc1., in the owning
service’s DNS configuration and use that address as the target.
bazel run //infra/ingress/tf
Update signed image url
Recreate VMs
bazel run infra/ingress/tf -- -replace 'yandex_compute_disk.vpc["*"]'
Regenerate wireguard keys
- Regenerate private and public keys:
wg genkey | tee host1.privatekey.txt | wg pubkey >host1.publickey.txt
wg genkey | tee host2.privatekey.txt | wg pubkey >host2.publickey.txt
wg genkey | tee router.privatekey.txt | wg pubkey >router.publickey.txt
cat - >data.json <<EOF
{
"wg_public_keys": {
"host1": "$(cat host1.publickey.txt)",
"host2": "$(cat host2.publickey.txt)",
"router": "$(cat router.publickey.txt)"
},
"wg_private_keys": {
"host1": "$(cat host1.privatekey.txt)",
"host2": "$(cat host2.privatekey.txt)",
"router": "$(cat router.privatekey.txt)"
},
"wg_preshared_keys": {
"host1": "$(openssl rand 32 | base64)",
"host2": "$(openssl rand 32 | base64)"
}
}
EOF
bazel run infra/ingress:vault.kv_put -- -format json alwaldend.com/vault1/approles/src_infra_ingress/wireguard "@${PWD}/data.json"
rm data.json *.privatekey.txt *.publickey.txt
1 -
Infrastructure ingress
Purpose
Describe Yandex Cloud ingress provisioning, the RouterOS WireGuard connection,
and the Ansible-managed Traefik configuration. The baseline covers checked-in
desired state, not a live routing or availability observation.
Baseline source revision: 550d7e79b1f5fdbc2b6017b75178471d6914082f.
Observation date: 2026-09-08. Sources are linked in full; no excerpts are used.
Sources: component contract,
VM resources,
WireGuard resources,
deployment playbook,
Traefik entry points, and
Traefik routes.
Requirements
Requirement: Provision ingress hosts from the declared host map
Terraform SHALL create addresses, encrypted boot disks, and instances for the
active local.vpc entries, using the shared cloud-init source. The baseline
active map SHALL contain host1 in ru-central1-d; the commented host2 entry
SHALL NOT be treated as an enabled resource declaration.
Scenario: Evaluate the baseline host configuration
- WHEN the checked-in ingress Terraform configuration is evaluated
- THEN instance resources are declared for
host1
- AND its boot disk references the declared KMS symmetric key
- AND instance metadata includes the shared cloud-init content
Requirement: Connect declared hosts through WireGuard
The RouterOS configuration SHALL declare the ingress-vpc interface and a peer
for each active ingress host. Peer endpoints SHALL use the corresponding cloud
address, and allowed addresses SHALL come from the Ansible inventory’s wg_ip.
- WHEN an ingress host is present in the active Terraform host map
- THEN its WireGuard peer uses the host’s declared public and preshared key
variables and inventory address
- AND the interface belongs to the configured LAN, forwarding, and ICMP lists
Requirement: Route to backend addresses that do not return to ingress
Each traefik_services backend target MUST resolve from the ingress hosts
without resolving back to ingress. The service owner SHALL declare the dedicated
site-local address. Generated HTTPS backend transports SHALL use the service
hostname as TLS server name.
Scenario: Add a service behind ingress
- WHEN a service is added to
traefik_services
- THEN its host route forwards to
https:// followed by its backend target
- AND that target is a dedicated site-local address defined by the service
owner
- AND backend TLS uses the service’s configured hostname
Requirement: Deploy Traefik with HTTPS and client-certificate authentication
The ingress playbook SHALL apply the host, WireGuard, and Traefik roles. The
Traefik templates SHALL redirect the web entry point to HTTPS and configure
default TLS client authentication as RequireAndVerifyClientCert using the
configured client CA file.
Scenario: Render the ingress TLS configuration
- WHEN the Ansible role renders the checked-in Traefik templates
- THEN port 80 redirects to the secure entry point
- AND the default TLS options require a certificate verified against the
configured client CA
2 -
owned-dns Specification
Purpose
Define retained ingress DNS ownership through the owner’s tf root,
including canonical declarations, scoped execution, and offline source checks.
Requirements
Requirement: Owner-local DNS configuration
The tf 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 until the authorized adoption revision
and SHALL retain enabled ownership after existing records are imported into the
owner’s state. Reconciliation against unchanged declarations and adopted state
SHALL propose no record additions, changes, replacements, or deletions.
Scenario: Inspect the preparatory configuration
- WHEN the checked-in root is evaluated with default inputs before its
authorized adoption revision
- THEN it reads this owner’s declaration and disables managed DNS records
- AND the package contains the module and declaration inputs
Scenario: Adopt existing DNS records
- WHEN authorized adoption records the shared writer audit and control
coverage and enables the owner’s record management
- THEN the owning root imports existing records by exact provider ID into
its state while preserving their declared identities and views
Scenario: Inspect adopted source defaults
- WHEN the adopted root uses its checked-in source defaults
- THEN DNS ownership remains enabled and the package retains the module
and canonical declaration inputs
Scenario: Reconcile existing DNS records
- WHEN the owning root plans against its adopted state and unchanged declarations
- THEN it proposes no record additions, changes, replacements, or deletions
Requirement: Scoped DNS execution and offline checks
The DNS wrappers SHALL select src_infra_ingress through the repository AL flow
and keep secret values in injected variables. dns.plan, dns.show, and
dns.apply SHALL retain the owning root and backend, select dns=1, and scope
planning to module.dns. Apply SHALL require the reviewed saved plan. This
workflow SHALL preserve ordinary service authentication and SHALL NOT establish
overall service health. Required DNS credentials and Vault grants SHALL remain
operational prerequisites, and RouterOS DNS credentials SHALL remain isolated
from unrelated RouterOS resources. The package SHALL expose a format test
without Vault authentication or DNS provider access.
- 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
- WHEN the operator selects the owning DNS wrappers
- THEN they select DNS credential injection through the owner AppRole with
dns=1
- AND their scoped plan validates DNS and its dependencies
- AND disabled DNS resources do not imply offline provider configuration
4 - Tf
Terraform config
Use this package’s dns.plan, dns.show, and dns.apply targets for the
scoped DNS adoption workflow.
DNS ownership is enabled by default after the verified 2026-09-13 adoption.
The adoption evidence
records four imports, a no-change follow-up plan, and preserved provider inventories.
The DNS wrappers select dns=1 and module.dns within this root and backend;
their validation covers DNS and its dependencies. Apply requires a reviewed
saved plan, and ordinary ingress service authentication remains separate.