Mukul SharmaandClaude Opus 5
ce072ffcf1
The GCP repos now live under ~/Documents/localgit/gcp/ so they cannot be confused with their homelab namesakes, which push to a different Gitea. This file documents the one-off kubectl that creates the registry-ca Secret from terraform output, and that path moved with them. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LEsTefWWifp4ikvhHF5s6N
32 lines
1.4 KiB
YAML
32 lines
1.4 KiB
YAML
# The issuer that signs Harbor's certificate, from the private CA the GKE
|
|
# node pool was told to trust.
|
|
#
|
|
# Terraform generates that CA and puts its PUBLIC key in Secret Manager,
|
|
# which is what every node fetches to verify image pulls. cert-manager needs
|
|
# both halves in order to sign, so the key pair is created as the
|
|
# `registry-ca` Secret in the cert-manager namespace by hand, from
|
|
# `terraform output` — the private key exists nowhere else, so nothing can
|
|
# reconcile it from git:
|
|
#
|
|
# TF=~/Documents/localgit/gcp/toolshed-gke-infra/envs/prod/10-infra
|
|
# kubectl -n cert-manager create secret tls registry-ca \
|
|
# --cert=<(terraform -chdir=$TF output -raw registry_ca_cert_pem) \
|
|
# --key=<(terraform -chdir=$TF output -raw registry_ca_key_pem)
|
|
#
|
|
# A ClusterIssuer, not an Issuer, so Harbor's namespace can request a
|
|
# certificate without the CA's private key being copied there. Note that a
|
|
# ClusterIssuer always reads its secret from cert-manager's own namespace,
|
|
# which is what makes that possible.
|
|
#
|
|
# This is the whole reason cert-manager is installed at all: nothing else in
|
|
# this cluster uses TLS. Let's Encrypt cannot help here, because nip.io is
|
|
# not on the public suffix list and every *.nip.io certificate shares one
|
|
# rate limit.
|
|
apiVersion: cert-manager.io/v1
|
|
kind: ClusterIssuer
|
|
metadata:
|
|
name: registry-ca-issuer
|
|
spec:
|
|
ca:
|
|
secretName: registry-ca
|