docs: record Go RDS TLS diagnosis
This commit is contained in:
brother7 committed
1 parent
bb50d06d1d
commit
acf368b6fe
1 file changed
+97
@@ -0,0 +1,97 @@
|
|||||||
|
# Task: Diagnose Go RDS TLS startup failure
|
||||||
|
|
||||||
|
## Identity
|
||||||
|
|
||||||
|
- Task ID: 20260816-diagnose-go-rds-tls-9c4a7e21
|
||||||
|
- Mode: Feature
|
||||||
|
- Branch: main
|
||||||
|
- Worktree: D:\Datas\OthersProjects\NianAIGC
|
||||||
|
- Base commit: bb50d06d1da67556571eb5e0fdb7312339842e71
|
||||||
|
- Owner: codex
|
||||||
|
- Status: Ready for Integration
|
||||||
|
|
||||||
|
## Scope
|
||||||
|
|
||||||
|
- Diagnose the Go API startup failure whose root error is PostgreSQL `server
|
||||||
|
refused TLS connection` during first-super-administrator account listing.
|
||||||
|
- Verify the repository TLS defaults and ACK Secret contract without reading
|
||||||
|
or exposing production credentials.
|
||||||
|
- Keep the task diagnostic-only; do not change application behavior or mutate
|
||||||
|
the live ACK/RDS environment without cluster access and explicit operational
|
||||||
|
execution.
|
||||||
|
|
||||||
|
## Intent And Constraints
|
||||||
|
|
||||||
|
- Build a deterministic local PostgreSQL wire-protocol feedback loop that
|
||||||
|
exercises the real Go administration list path.
|
||||||
|
- Separate confirmed protocol behavior from the unverified live RDS control
|
||||||
|
plane setting.
|
||||||
|
- Prefer verified TLS for production; document `sslmode=disable` only as a
|
||||||
|
deliberate plaintext fallback when the operator accepts that tradeoff.
|
||||||
|
- Redact credentials and delete all temporary diagnostic code before finish.
|
||||||
|
|
||||||
|
## Outcome
|
||||||
|
|
||||||
|
- Confirmed the Go PostgreSQL configuration defaults to `verify-full` when
|
||||||
|
`DATABASE_URL` omits `sslmode`; the checked-in Secret example also specifies
|
||||||
|
`verify-full` and an RDS CA path.
|
||||||
|
- Reproduced the exact production error chain against a local PostgreSQL
|
||||||
|
protocol endpoint that returns `N` to `SSLRequest`: `list accounts` -> `list
|
||||||
|
administration accounts` -> `tls error (server refused TLS connection)`.
|
||||||
|
- Re-ran the identical administration query path against the same endpoint
|
||||||
|
with `sslmode=disable`; it passed. This isolates the failure to a mismatch
|
||||||
|
between client TLS mode and endpoint TLS capability, before credentials,
|
||||||
|
grants, schema, or bootstrap creation are evaluated.
|
||||||
|
- The most likely live cause is that the RDS instance/selected connection
|
||||||
|
address does not have SSL enabled while the deployed `DATABASE_URL` requests
|
||||||
|
verified TLS. Wrong endpoint/port or a TLS-refusing intermediary remain
|
||||||
|
lower-probability alternatives until checked from the Go Pod/RDS console.
|
||||||
|
- No product source, deployment manifest, or canonical project-memory file was
|
||||||
|
changed. The temporary diagnostic test was deleted.
|
||||||
|
|
||||||
|
## Verification
|
||||||
|
|
||||||
|
- RED: `go test ./internal/application -run
|
||||||
|
TestDiagnosticListAccountsAgainstTLSRefusingEndpoint -count=1 -v` reproduced
|
||||||
|
the exact `server refused TLS connection` error on the production query path.
|
||||||
|
- GREEN: with diagnostic mode set to `disable`, the same command and fake
|
||||||
|
endpoint passed.
|
||||||
|
- A credential-free SSLRequest probe to the real RDS host timed out from this
|
||||||
|
workstation; this is consistent with a private/VPC endpoint but does not
|
||||||
|
establish the RDS SSL setting.
|
||||||
|
- `kubectl config current-context` reported no configured context, so no live
|
||||||
|
Secret, Pod DNS result, or RDS endpoint was inspected or mutated.
|
||||||
|
- Alibaba Cloud's current RDS PostgreSQL documentation confirms that SSL must
|
||||||
|
be enabled for SSL-mode connections, `disable` is the non-SSL client mode,
|
||||||
|
and enabling/changing the protected address restarts the instance with a
|
||||||
|
minute-level interruption risk.
|
||||||
|
|
||||||
|
## Follow-ups
|
||||||
|
|
||||||
|
- In the RDS console, verify whether SSL is enabled and whether the protected
|
||||||
|
connection address exactly matches the host used by the Go Pod.
|
||||||
|
- Recommended production repair: enable RDS SSL for that address, mount the
|
||||||
|
downloaded CA as `zhinian-rds-ca`, retain `sslmode=verify-full`, update the
|
||||||
|
Go database Secret, and restart/smoke the Go Deployment.
|
||||||
|
- Temporary recovery alternative: explicitly use `sslmode=disable` in the Go
|
||||||
|
`DATABASE_URL`, accepting plaintext database transport inside the network,
|
||||||
|
then restart and verify the Deployment.
|
||||||
|
- After TLS negotiation succeeds, separately validate credentials, grants,
|
||||||
|
migrations 0001/0002, and super-administrator bootstrap.
|
||||||
|
|
||||||
|
## Promotion Candidates
|
||||||
|
|
||||||
|
- Target: production RDS validation evidence and deployment troubleshooting
|
||||||
|
guidance.
|
||||||
|
Proposal: record the live RDS SSL state/protected address and add a
|
||||||
|
credential-free SSLRequest check before deploying a `verify-full` database
|
||||||
|
URL.
|
||||||
|
Evidence: the Go startup failure and deterministic RED/GREEN protocol loop
|
||||||
|
recorded above.
|
||||||
|
Future impact: prevents fail-closed Go startup from being mistaken for an
|
||||||
|
account/bootstrap defect when the endpoint refuses TLS.
|
||||||
|
Semantic conflicts: none; this strengthens existing RDS-001/RDS hardening
|
||||||
|
commitments.
|
||||||
|
Human confirmation required: no for evidence/runbook promotion; enabling or
|
||||||
|
disabling production RDS SSL remains an operator decision because it can
|
||||||
|
restart the instance or weaken transport security.
|
||||||
Reference in new issue
Block a user