fix: clone cluster failure with IRSA due to wrong AWS_REGION and overwritten AWS_ACCESS_KEY_ID - #1213
Conversation
|
The main issue we are facing is the bug3, but AI reported the others while I was investigating. |
There was a problem hiding this comment.
🟡 Changes recommended
The new AWS region fallback logic accidentally shadows the prefix function parameter, which can change later behavior (e.g., skipping BACKUP_NUM_TO_RETAIN in the unprefixed/main envdir).
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
This PR targets wal-g/IRSA clone reliability in configure_spilo.py by correcting how AWS region is derived, ensuring IRSA env var fallbacks include AWS_REGION, and removing a stale “future compatibility” block that could corrupt wal-g credentials.
Changes:
- Extract S3 bucket name before applying the region regex to avoid false matches from path suffixes like
/wal/. - Extend IRSA bare-env fallback propagation to include
AWS_REGIONalongside other IRSA variables. - Remove a block that could overwrite
AWS_ACCESS_KEY_IDwith a wal-g S3 prefix template.
File summaries
| File | Description |
|---|---|
| postgres-appliance/scripts/configure_spilo.py | Fixes IRSA/clone-related wal-g env generation (region derivation, IRSA fallbacks, and removal of stale credential-overwrite logic). |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 1
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
…environment Signed-off-by: tcondeixa <tscondeixa@gmail.com>
…b-tcondeixa:zalando/spilo into fix/irsa-access-key-id-clobbered-by-s3-prefix
|
👍 |
Fix three bugs in configure_spilo.py that cause clone clusters to fail when using IRSA.
Bug 1 — AWS_ACCESS_KEY_ID overwritten with S3 prefix
A stale "future compatibility" block introduced during the wal-e → wal-g migration copies WALG_S3_PREFIX into AWS_ACCESS_KEY_ID when no static credentials are set. With IRSA, AWS_ACCESS_KEY_ID is legitimately absent, so wal-g ends up with a garbage S3 path as a credential. Regular clusters survive this because wal-g's credential chain picks up AWS_ROLE_ARN/AWS_WEB_IDENTITY_TOKEN_FILE first — but it remains a latent issue.
Bug 2 — AWS_REGION incorrectly extracted as loca
The regex used to derive the AWS region was applied to the full S3 path. When PGVERSION is not yet known at clone configure time, the path ends with /wal/ (no version), causing the greedy regex to match kube-1 in the bucket name and extract the wrong preceding segment (loca) as the region. Fixed by extracting the bucket name before running the regex. Also renamed the temporary variable from prefix to bucket_or_prefix to avoid shadowing the function parameter, which would have incorrectly suppressed BACKUP_NUM_TO_RETAIN for the main envdir when S3 is configured.
Bug 3 — AWS_REGION not falling back to bare env var for clone and standby envdir
The IRSA fallback that copies bare env vars when prefixed versions are absent covered AWS_ROLE_ARN, AWS_WEB_IDENTITY_TOKEN_FILE, and AWS_STS_REGIONAL_ENDPOINTS — but not AWS_REGION. Even with AWS_REGION=eu-central-1 correctly set in the pod env, both the clone and standby envdir would still fall through to the broken regex. The fallback is shared code (irsa_names list in update_and_write_walg_configuration), so adding AWS_REGION to it fixes both in one change.
NOTE: PR created with the help of AI agent.