---
# Ansible-side knobs for roles/k3s_cert_manager — cert-manager, which issues
# and renews the TLS certificates Ingresses on this cluster serve. Installed
# via k3s's own bundled helm-controller, same mechanism as roles/k3s_metallb,
# k3s_monitoring and k3s_postgres (see tasks/main.yml) — no helm binary or
# extra Ansible collection needed on the controller.
#
# This is the fourth cluster service, and the first one that exists purely
# for apps rather than for the cluster: nothing here needs a certificate,
# roles/k3s_app's tenants do. It's still a cluster service rather than an
# app, because a certificate issuer is shared infrastructure in the same way
# the shared Postgres is — one ClusterIssuer, every app's Ingress annotates
# itself against it.

k3s_cert_manager_namespace: cert-manager

k3s_cert_manager_chart_repo: https://charts.jetstack.io

# Pinned, same reasoning as every other chart version here — a rebuild
# months from now should reproduce today's install, not whatever's newest.
# Bump deliberately; check the current release first at
# https://github.com/cert-manager/cert-manager/releases.
k3s_cert_manager_chart_version: "v1.21.1"

# The name every app's Ingress annotates itself with
# (cert-manager.io/cluster-issuer: <this>). A ClusterIssuer rather than a
# per-namespace Issuer, so an app doesn't need its own copy of the ACME
# account and DNS credentials in its own namespace.
k3s_cert_manager_issuer_name: letsencrypt

# Let's Encrypt's production directory. Swap for the staging URL
# (https://acme-staging-v02.api.letsencrypt.org/directory) while working out
# a solver configuration: production has a hard rate limit of 5 failed
# validations per account/hostname/hour, and burning it means waiting rather
# than retrying. Changing this changes which ACME account the issuer uses, so
# existing certificates are re-issued rather than renewed.
k3s_cert_manager_acme_server: https://acme-v02.api.letsencrypt.org/directory

# The address Let's Encrypt sends expiry warnings to. No default — an ACME
# account is registered against it, so a wrong value is worth failing on
# rather than guessing. Set in inventory/group_vars/k3s_cluster.yml.
k3s_cert_manager_acme_email: ""

# Where the ACME account's private key is kept. cert-manager generates it on
# first registration; it is *not* the certificate key, and losing it means
# re-registering rather than losing certificates.
k3s_cert_manager_acme_key_secret: letsencrypt-account-key

# --- Solver -----------------------------------------------------------------
#
# How cert-manager proves control of the domain. DNS-01 by default, not
# HTTP-01, because HTTP-01 requires Let's Encrypt to reach this cluster from
# the internet on port 80 — true only if the LAN is port-forwarded, and this
# cluster deliberately isn't. DNS-01 needs no inbound path at all, and is the
# only option that can issue wildcards.
#
# The provider block is left open rather than hard-coding Cloudflare, since
# it's the one part of this role that depends on who runs the DNS. Set
# k3s_cert_manager_solver in inventory/group_vars/k3s_cluster.yml to whatever
# your provider's stanza looks like in cert-manager's docs
# (https://cert-manager.io/docs/configuration/acme/dns01/); it's rendered
# into the ClusterIssuer's solvers list as-is. Any secret it references
# should name the Secret this role renders from Vault (below), so no token is
# ever committed. tasks/main.yml fails fast while this is empty.
k3s_cert_manager_solver: {}

# The Vault path holding the DNS provider's API credentials. Every key at
# this path becomes a key in a Secret named after it in the cert-manager
# namespace, the same "Vault keys pass through verbatim" rule roles/k3s_app
# uses — so the solver above references whichever key name you stored.
# Leave empty for a solver that needs no credentials (e.g. HTTP-01).
k3s_cert_manager_vault_path: homelab/k3s-cert-manager
k3s_cert_manager_credentials_secret: cert-manager-dns-credentials