Fork of hashicorp/boundary-plugin-aws (MPL-2.0). Module path and Boundary SDK
imports now point at repo.anhonesthost.net/CyberCoveLLC. Adds NOTICE and an
About this fork section to the README.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
This changeset implements multipart uploads. AWS caps PutObject calls at 5
GiB, effectively causing the plugin to error on any upload larger than that.
Multipart limit is 8 TiB, which should be plenty for most use cases.
Multipart implementation is size-gated: we only switch to multipart uploads once
the file size is greater than multipartThreshold, which is currently set to 8
MiB, and we set the part size to 8 MiB as well (this follows AWS CLI and boto3).
That gives us ~78 GiB max object before we auto-scale, due to 10,000 part cap on
AWS.
---------
Co-authored-by: Hugo <10965479+hugoghx@users.noreply.github.com>
* feat: parse generic aws api errors
* feat: parse s3 api errors
* feat: return credential state for all status errors
* fix status codes on certain http error codes and re-enable two tests
* switch code to FailedPrecondition
* update certain error codes
* update go.mod for new sdk version
---------
Co-authored-by: Damian Debkowski <damian.debkowski@hashicorp.com>
* fix(storage): Storage Assume Role Support
This commit introduces fixes to enable operators to use AWS dynamic
credentials on the storage side of this plugin, namely validation,
improved credential lifecycle management to allow for storage buckets to
be updated from static to dynamic credentials and vice versa, and a new
way to determine credential types.
It also introduces new tests for dynamic credential usage for the
various functions.
* fix(storage): Static rotated creds being deleted on plugin err
On Storage Bucket update, when we determine if the credentials are to be
updated to new ones, we call `credState.ReplaceCreds`.
This call, if the old credentials were managed by us (rotated at create
time), will delete the old credentials and set the new ones onto
credState.
We called this function without validating if the incoming credentials
are valid. This could get the bucket in a state where where, while we'd
return an update error if the incoming credentials weren't working with
S3 (err in the dry run process that happens at the end of the update),
we'd also silently delete the old credentials the bucket used, rendering
the bucket completely broken.
---------
Co-authored-by: Hugo <hugoamvieira@users.noreply.github.com>
shadowdaoandClaude Sonnet 5.5
Piotr KazmierczakandHugo
Damian Debkowski
hashicorp-copywrite[bot]
oss-core-libraries-dashboard[bot]andhashicorp-copywrite[bot]
Louis Ruch
daniandDamian Debkowski
