Repository navigation
Support AWS-managed credentials for S3 storage - #6874
Conversation
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 11 |
🟢 Coverage 100.00% diff coverage · 0.00% coverage variation
Metric Results Coverage variation ✅ 0.00% coverage variation (-1.00%) Diff coverage ✅ 100.00% diff coverage (70.00%) Coverage variation details
Coverable lines Covered lines Coverage Common ancestor commit (939bdbf) Report Missing Report Missing Report Missing Head commit (5210c38) 43454 (+20) 37798 (+17) 86.98% (0.00%) Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch:
<coverage of head commit> - <coverage of common ancestor commit>Diff coverage details
Coverable lines Covered lines Diff coverage Pull request (#6874) 24 24 100.00% Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified:
<covered lines added or modified>/<coverable lines added or modified> * 100%1 Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct.
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
5fc717b to
3ace65e
Compare
nscuro
left a comment
There was a problem hiding this comment.
Thanks. Please use an enum for the credential source option, the other comments are suggestions.
Please also update the user-facing documentation here: https://github.com/DependencyTrack/docs/blob/main/docs/reference/configuration/file-storage.md#s3 so it explains how to configure the provider for AWS, and what sources are checked.
1ec0d91 to
84a4c73
Compare
The S3 file storage provider only authenticated when static access and secret keys were configured, and otherwise issued anonymous requests. This prevented the use of AWS-managed credentials (IRSA, ECS task roles, EC2 instance profiles), which are the recommended way to grant access on AWS and avoid long-lived static keys. Add a 'dt.file-storage.s3.credentials-source' option, defaulting to 'static' to preserve existing behavior. When set to 'aws', credentials are resolved from the workload's AWS identity via MinIO's IamAwsProvider, which supports web identity tokens (IRSA), ECS container credentials and the EC2 instance metadata service, in that order. This is not the full AWS default credential provider chain: environment variables and ~/.aws/credentials profiles are not consulted. Configuring only one of the two static keys now fails at startup instead of silently falling back to anonymous requests. Such a configuration could never authenticate, since SigV4 requires both. Signed-off-by: Fouad JADOUANI <fouad.j@live.fr> Signed-off-by: Fouad <fouad.j@live.fr>
Signed-off-by: Fouad JADOUANI <fouad.j@live.fr> Signed-off-by: Fouad <fouad.j@live.fr>
Co-authored-by: fffinkel <finkel.matt@gmail.com> Signed-off-by: Fouad JADOUANI <fouad.j@live.fr> Signed-off-by: Fouad <fouad.j@live.fr>
nscuro
left a comment
There was a problem hiding this comment.
Thanks!
FYI I updated the PR description so it accurately states what's being shipped now.
The docs in application.properties are also outdated from an earlier iteration, i.e. "Static keys are not required and are ignored in this mode." is no longer the case. I'll fix that myself in a follow-up PR.
Description
The S3 file storage provider only authenticated when static access and secret keys were configured, and otherwise issued anonymous requests. This prevented the use of AWS-managed credentials (IRSA, ECS task roles, EC2 instance profiles), which are the recommended way to grant access on AWS and avoid long-lived static keys.
This PR adds a
dt.file-storage.s3.credentials-sourceoption, defaulting tostaticto preserve existing behavior. When set toaws, credentials are resolved from the workload's AWS identity, so no static keys need to be configured.Addressed Issue
Closes #6851
Additional Details
When
credentials-source=aws, credentials are resolved via MinIO'sChainedProvider, composed ofAwsEnvironmentProvider(AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY),AwsConfigProvider(~/.aws/credentials), andIamAwsProvider, which itself supports web identity tokens (IRSA), ECS container credentials (AWS_CONTAINER_CREDENTIALS_RELATIVE_URIAWS_CONTAINER_CREDENTIALS_FULL_URI) and the EC2 instance metadata service, in that order of precedence.Note that this is close to, but not exactly, the AWS default credential provider chain: the AWS SDK consults web identity tokens before
~/.aws/credentials, whereas the chain above is evaluated in the order listed.Behavior change worth highlighting: configuring only one of the two static keys now fails at startup instead of silently falling back to anonymous requests. Such a configuration could never authenticate, since SigV4 requires both an access key and a secret key, so this only surfaces already-broken setups. Setting static keys together with
credentials-source=awsfails at startup as well, so a leftover key cannot silently shadow the intended source.The credential resolution logic is covered by
S3FileStorageProviderTest, which deliberately does not use Testcontainers so it runs without Docker.Checklist
This PR fixes a defect, and I have provided tests to verify that the fix is effectiveThis PR introduces changes to the database model, and I have updated the migration changelog accordinglyThis PR is a substantial change (per the ADR criteria), and I have added an ADR underdocs/adr/