# 这份文件**只是形状说明**，不是拿来 apply 的。
#
# 真实值由 deploy-uat job 在流水线里从 Azure Key Vault 现取现渲染：
#
#   JWT_KEY=$(az keyvault secret show --vault-name conti-backend-kv --name security-jwt-key-v1 ...)
#   kubectl create secret generic conti-backend-secret -n retailapp-uat \
#     --from-literal=SECURITY_JWT_SECRET="$JWT_KEY" ... | kubectl apply -f -
#
# 密钥只在那个 job 的执行过程中短暂存在，不落盘、不进镜像、不进 git。
# 谁要是把真值填进这个文件并提交，即使之后再删掉，也已经永久留在 git 历史里了——
# 那时候唯一正确的处理是轮换密钥，而不是改一次提交。
apiVersion: v1
kind: Secret
metadata:
  name: conti-backend-secret
  namespace: retailapp-uat
type: Opaque
stringData:
  # HS256 签名密钥，base64 编码；解码后必须 ≥ 32 字节，否则 JwtProperties 在启动时就拒绝
  # （见 04-security-auth.md）。轮换时先加 SECURITY_JWT_KEYS_V2，再切 ACTIVE_KEY_ID，
  # 最后一步才移除 V1——三步之间要隔开，否则已签发的 token 会集体失效。
  SECURITY_JWT_SECRET: "__injected_by_pipeline__"
  # 运行时账号的密码（只有 DML 权限），迁移账号的密码是另一个
  DB_PASSWORD: "__injected_by_pipeline__"
  # F6 的调用凭证。骨架里 IntegrationClientProperties.ClientConfig 还没有 apiKey 字段，
  # F6ApiClient 也还没往请求头上挂它——接入 F6 真实鉴权时补上这两处，这个 key 就有人用了。
  F6_API_KEY: "__injected_by_pipeline__"