Allow AWS SDK credential chain for S3 storage#6121
Open
TheJenne18 wants to merge 1 commit into
Open
Conversation
When STORAGE_S3_KEY / STORAGE_S3_SECRET are unset, the previous default
placeholder strings ('your-key' / 'your-secret') were passed as explicit
credentials to the AWS PHP SDK. Because the SDK treats any non-null
key+secret as credentials, it never consulted its default credential
provider chain, breaking IAM-role-based setups (ECS task role on
Fargate/EC2, EKS IRSA, EC2 instance profile, Lambda execution role).
Changing the defaults to null lets the SDK fall through to the
credential chain when these env vars are omitted, while preserving
existing behaviour for users who set them explicitly.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
When running BookStack with
STORAGE_TYPE=s3on infrastructure that provides AWS credentials via the SDK credential chain (EC2 instance profile, ECS task role on Fargate/EC2, EKS IRSA, Lambda execution role, etc.), all S3 operations fail with errors such as:even though the environment correctly exposes credentials and the role has full S3+KMS permissions.
Root cause
app/Config/filesystems.phpdefaultedSTORAGE_S3_KEYto'your-key'andSTORAGE_S3_SECRETto'your-secret'. When these env vars are not set, those literal placeholder strings are handed to the AWS PHP SDK as explicit credentials. Because explicit credentials are present, the SDK does not consult its default credential provider chain, and every S3 call fails with403, which Flysystem v3 wraps asUnableToCheckFileExistence.The AWS SDK only walks the chain (env vars → container creds → instance metadata → ...) when
keyandsecretarenull/absent.Change
Default the
keyandsecretof thes3disk toenv('STORAGE_S3_KEY')/env('STORAGE_S3_SECRET')without a fallback (i.e.nullwhen unset). Existing setups that set these env vars explicitly are unaffected; IAM-role-based setups now work out of the box.Reproduction (before)
STORAGE_TYPE=s3,STORAGE_S3_BUCKET,STORAGE_S3_REGIONset, and noSTORAGE_S3_KEY/STORAGE_S3_SECRET.POST /api/image-gallery→ HTTP 500,Unable to check existence for: ….Workaround that confirmed the diagnosis
Setting
STORAGE_S3_KEY=nullandSTORAGE_S3_SECRET=null(Laravel'senv()converts the string"null"to PHPnull) makes uploads succeed via the task role. With this PR that workaround is no longer needed.Test plan
STORAGE_S3_KEY/STORAGE_S3_SECRETkeep working.local_securestorage unaffected.