Mukul SharmaandClaude Opus 5
f703f0b55a
Each of these now answers on <name>.infra.deployshed.com alongside the nip.io name it already had. Both are kept on purpose: nothing that currently references the old name breaks, and the new one can be proved before anything depends on it. Removing nip.io is a separate step, and a larger one, because Harbor's name is embedded in every running app's image reference. TLS covers the real domain only. Let's Encrypt cannot issue for nip.io — it is not on the public suffix list and every *.nip.io certificate shares one rate limit — so a tls block naming both would request one certificate spanning them and receive nothing for either. Each tls block therefore lists exactly the one new hostname, which is why they are written out rather than derived from the host list beside them. The charts disagree about how to express a second host, so each is done the way its own chart supports: gitea, grafana, vault, victoria-metrics-single take host lists, so the new name joins the existing one on a single Ingress. jenkins' primary ingress accepts exactly one hostName, so the new name goes on secondaryingress — a whole second Ingress object at the same backend. paths must be set explicitly there; left at the chart's default of [] it renders zero routes and the hostname answers nothing. argo-cd takes extraHosts natively, but its ingress.tls is a boolean bound to one fixed secret covering every host at once. Turning it on would request a certificate including nip.io and fail, and there is no extraTls to scope it. So ArgoCD gains the hostname now and its certificate when nip.io goes. Harbor is untouched here. It has no multi-host mechanism at all, so its second hostname needs a standalone Ingress, and its externalURL is what docker clients are handed — both deserve their own change rather than riding along with a hostname tidy-up. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LEsTefWWifp4ikvhHF5s6N
101 lines
3.6 KiB
YAML
101 lines
3.6 KiB
YAML
vault:
|
|
# GKE counterpart of helm-overrides/k8s-admin-prd-ase1/vault, same chart
|
|
# (0.34.1) and same shape — production mode, file storage, standalone, no
|
|
# HA — with one substantial difference: this Vault unseals itself from
|
|
# Cloud KMS instead of by hand.
|
|
#
|
|
# The homelab unseals with 3 of 5 Shamir keys after every restart. That
|
|
# was fine on an always-on VM. Here the nodes are spot and can be
|
|
# reclaimed at any hour, and a sealed Vault means every secret in the
|
|
# cluster is unavailable until a human notices. The trade, stated plainly:
|
|
# unsealing now depends on GCP IAM rather than on people holding key
|
|
# shares.
|
|
#
|
|
# This is a fresh install, not an adoption. Init is still a one-off manual
|
|
# step (`vault operator init`), and with a KMS seal it returns RECOVERY
|
|
# keys plus a root token — recovery keys cannot unseal a running Vault,
|
|
# they exist to recover or rekey it. Keep them and the root token in a
|
|
# password manager; they belong in neither Git nor Vault itself.
|
|
|
|
injector:
|
|
enabled: false
|
|
|
|
server:
|
|
# The Workload Identity binding Terraform created names exactly
|
|
# vault/vault — this namespace and this service account name. The
|
|
# annotation is the other half of that pair. Miss either and Vault
|
|
# starts, fails to reach KMS, and stays sealed with a permission error
|
|
# that does not mention Workload Identity at all.
|
|
serviceAccount:
|
|
create: true
|
|
name: vault
|
|
annotations:
|
|
iam.gke.io/gcp-service-account: toolshed-vault@toolshed-testing-508208.iam.gserviceaccount.com
|
|
|
|
dataStorage:
|
|
enabled: true
|
|
# 10Gi rather than the homelab's 5Gi: that number exists only because
|
|
# local-path cannot expand a bound volume. standard-rwo can expand, so
|
|
# this is the chart default, not a constraint.
|
|
size: 10Gi
|
|
storageClass: standard-rwo
|
|
|
|
ha:
|
|
enabled: false
|
|
|
|
resources:
|
|
requests:
|
|
cpu: 100m
|
|
memory: 128Mi
|
|
limits:
|
|
memory: 256Mi
|
|
|
|
standalone:
|
|
enabled: true
|
|
# `ui = true` here AND ui.enabled below are both required — the chart
|
|
# has two separate toggles for the same thing, and setting only one
|
|
# leaves the UI 404ing (claude.md issue #10).
|
|
#
|
|
# The seal stanza's values come from terraform output vault_seal, so
|
|
# Terraform and this file cannot disagree about which key Vault
|
|
# unseals with. No credentials appear here: the pod authenticates to
|
|
# KMS as its Workload Identity, so there is no key file to mount,
|
|
# rotate, or leak.
|
|
config: |
|
|
ui = true
|
|
listener "tcp" {
|
|
address = "[::]:8200"
|
|
cluster_address = "[::]:8201"
|
|
tls_disable = "true" # lab only - enable TLS for anything beyond local testing
|
|
}
|
|
storage "file" {
|
|
path = "/vault/data"
|
|
}
|
|
seal "gcpckms" {
|
|
project = "toolshed-testing-508208"
|
|
region = "us-central1"
|
|
key_ring = "toolshed-vault"
|
|
crypto_key = "unseal"
|
|
}
|
|
|
|
# Single host — no Tailscale here. Plain HTTP through Contour, matching
|
|
# tls_disable above.
|
|
ingress:
|
|
enabled: true
|
|
ingressClassName: contour
|
|
annotations:
|
|
# Certificate for the real domain only; nip.io cannot have one.
|
|
cert-manager.io/cluster-issuer: letsencrypt-prod
|
|
hosts:
|
|
- host: "vault.35.238.248.203.nip.io"
|
|
paths: []
|
|
- host: "vault.infra.deployshed.com"
|
|
paths: []
|
|
tls:
|
|
- secretName: vault-tls
|
|
hosts:
|
|
- vault.infra.deployshed.com
|
|
|
|
ui:
|
|
enabled: true
|