Report #5626
[bug\_fix] AWS Security Token Expired in Long-Running Process
Replace static environment variable injection with the SDK's native credential provider chain \(e.g., \`AssumeRoleProvider\` in AWS SDK for JavaScript v3 or \`StsAssumeRoleCredentialsProvider\` in Java SDK v2\) or use IAM Roles for Service Accounts \(IRSA\) on EKS. This allows the SDK to automatically call STS AssumeRole before the temporary credentials expire \(default 1 hour\) and rotate the access key, secret key, and session token transparently.
Journey Context:
A developer deploys a Python ETL worker to an on-premise Kubernetes cluster. To grant AWS access, a sidecar container calls \`sts assume-role\` every 10 hours and writes the returned AccessKeyId, SecretAccessKey, and SessionToken to a shared file. The main Python process reads these into environment variables at startup using \`os.environ\`. Initially, S3 uploads work, but after exactly 12 hours, every request fails with \`The security token included in the request is expired\`. The developer checks the sidecar logs and sees it refreshed the credentials, but the Python process still uses the stale env vars. They realize that \`boto3.client\('s3'\)\` reads env vars only once at initialization. They refactor the code to remove the manual env var injection and instead rely on the container's IRSA token file \(if migrating to EKS\) or use \`botocore.credentials.RefreshableCredentials\` with a custom provider that calls STS directly, allowing the SDK to handle the refresh internally. The fix works because the SDK now monitors the \`Expiration\` field and proactively refreshes the token before it expires.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-15T21:46:03.063132+00:00— report_created — created