This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

OpenSpec

1 - Specifications

1.1 - Dns records

1.1.1 - dns-records Specification

Provide one canonical DNS transformation for project-local Terraform resources and offline inspection, preserving declared names, values, and view ownership.

The module SHALL accept decoded owner DNS documents and a zone, flatten every supported type member, expand and deduplicate destinations, and expose one normalized map without provider configuration. It SHALL reject unsupported types, destinations, malformed members, and absolute names outside the zone.

  • WHEN an entry contains A and AAAA with destinations all and global
  • THEN normalization produces exactly four records, one per type and view

Normalized and provider resource keys SHALL use logical declaration key, type, and view without mutable record values. Separate logical keys SHALL preserve multiple records at the same name and type, including MX priority and TXT values. Explicit TTLs SHALL override the type-specific compatibility defaults.

  • WHEN an A member changes its address without changing its logical key
  • THEN its normalized and provider resource keys remain unchanged

The module SHALL accept provider instances from its caller and create individual Cloudflare global and RouterOS dc1 records only when explicitly enabled. It SHALL default to disabled provider ownership while preserving normalized outputs. Cloudflare records SHALL remain unproxied. Disabled ownership SHALL NOT imply that operational provider initialization or credential prerequisites are suppressed.

  • WHEN a root calls the module without enabling ownership
  • THEN it declares no provider record resources and still exposes every normalized declaration

1.2 - Project dns

1.2.1 - project-dns Specification

Record the retirement of this project’s landing DNS infrastructure while preserving its repository documentation and builds.

The project SHALL have no dedicated landing DNS declaration, Terraform root, or operational source export. Its landing page SHALL be published by the main site under /projects/tf_modules/ instead of a dedicated hostname.

  • WHEN the project tree is consumed
  • THEN it contains no landing DNS declaration, Terraform DNS stage, or landing build target, and the main site owns its landing page.

1.3 - Project tf modules

1.3.1 - Reusable Terraform modules

Provide reusable infrastructure declarations for Vault, virtual machines, storage, and related services. This baseline was observed at repository revision 550d7e79 on 2026-09-08. The collection remains in progress according to its README. Sources for the representative module contracts below are the AppRole module, transit-key module, backup-bucket module, and module packaging. These are declarative source contracts; no live provisioning is asserted.

The AppRole, transit-key, backup-bucket, and Proxmox VM module packages SHALL each expose their main.tf through a same-named Bazel filegroup available to repository subpackages.

  • WHEN a target depends on //projects/tf_modules/vault_approle:vault_approle
  • THEN its declared source input includes the AppRole module’s main.tf

The AppRole module SHALL declare an identity entity, backend alias, internal group, and named AppRole with configurable token and secret-ID limits. Its role policies SHALL combine the shared and AppRole-secret policies with caller policies and the Yandex-folder policy unless that policy is disabled for the role.

  • WHEN disable_yc_folder_policy is true
  • THEN the role’s policy list excludes the module’s Yandex-folder policy while preserving shared, AppRole-secret, and caller policies

The transit-key module SHALL declare a named Vault transit key, an encryption policy and group, and a decryption policy and group. Decryptor member groups SHALL also be included in the encryption group.

  • WHEN a caller adds a group ID to decryptors_member_group_ids
  • THEN the module includes that group in both transit permission groups

The backup-bucket module SHALL declare a versioned Yandex storage bucket with default KMS encryption, grant read and write permissions to the supplied service accounts, and store bucket identifiers in the caller-selected Vault KV v2 location.

  • WHEN the caller supplies the bucket name components, folder, service accounts, and Vault destination
  • THEN the declarations bind bucket encryption to the module’s KMS key and publish the bucket ID, folder ID, and bucket name to that Vault destination