[rushtong]

Addresses

https://broadworkbench.atlassian.net/browse/DT-4348

Stacked PRs (merge in order):

1. [DT-4348][risk=no] Render the local certs with render-configs.sh (1/5) #3177 Base and certs ← this PR
2. [DT-4348][risk=no] Render consent.yaml, site.conf and oauth2.conf from terra-helmfile (2/5) #3178 Chart configs
3. [DT-4348][risk=no] Render the local compose files and .env (3/5) #3179 Compose
4. [DT-4348][risk=no] Export the dev database and fill the local index (4/5) #3180 Dump and index
5. [DT-4348][risk=no] Render the local config in the Dev Container (5/5) #3181 Dev Container

Summary

The first of 5 stacked PRs that replace the hand-made config/ directory with files rendered from their real sources. Review the plan first: it describes the design for all 5 PRs.

• Plan: updates docs/plans/render-local-configs-plan.md to follow the current duos-ui model (DT-4236 and DT-4257): no Dockerfile, no gh, git clone over HTTPS then SSH, no preflight, and the dev database credentials for the local Postgres, so the duos-ui compose mode against a local consent stack connects with no change. The "Pull Requests" section lists the 5 PRs.
• scripts/render-configs.sh: writes server.crt, server.key and ca-bundle.crt from the local-dev-cert secret, as duos-ui does. Each step writes to a staging folder in config/, and moves its files into place only when the step succeeds. The script uses its own kubeconfig, so the developer's kubectl context does not change. One kubectl get --raw call with a 10-second timeout finds a missing VPN fast.
• scripts/lib/common.sh: shared helpers. Later PRs add to it.
• DEVNOTES.md: adds the "Render Configs" section, which DEVNOTES.md already links to.

Testing

• bash -n on each script.
• A run with stub gcloud and kubectl commands writes the three files, with mode 600 on server.key.
• With the cluster out of reach, the script stops with the VPN message and the old certs do not change.
• Not tested against the real cluster (needs the VPN).

---

Have you read CONTRIBUTING.md lately? If not, do that first.

• Label PR with a Jira ticket number and include a link to the ticket
• Label PR with a security risk modifier [no, low, medium, high]
• PR describes scope of changes
• Get a minimum of one thumbs worth of review, preferably two if enough team members are available
• Get PO sign-off for all non-trivial UI or workflow changes
• Verify all tests go green
• Test this change deployed correctly and works on dev environment after deployment

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.