-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a pure aws-sdk-go auth #4667
Conversation
ddd4d2b
to
1f874e6
Compare
@bwplotka could you please review this ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, thanks! Well implemented in, but I am really curious if it's complex enough to import whole new complex module 🤔 I would add issue on minio-go
too, so they are aware of this gap.
// NewAWSSDKAuth returns a pointer to a new Credentials object | ||
// wrapping the environment variable provider. | ||
func NewAWSSDKAuth(region string) *credentials.Credentials { | ||
return credentials.New(&AWSSDKAuth{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is implementation that complex that is worth to import the aws-sdk-go?
Essentially we need to compare the maintenance work.
- Is it better for us to copy (potentially tiny) code and maintain it? As far as I understand this, it's just taking correct environment variables, that's it?
- Is it better to contribute such logic to
minio-go
? - Is it better to import whole
aws-sdk-go
(dependency hell)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I used aws-sdk-go-v2
which contrary to the first aws-sdk-go
has split modules for every services so we should import only what is required for the features we need.
It does much more than taking env vars.
It also leverage the well known AWS config files allowing to automatically assume roles based on other roles via the STS API. All that logic is well and consistently implemented across all AWS SDKs so I see no reason we should have our own implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
here is the LoadDefaultConfig
credential chain we get by importing this.
1. Environment variables.
1.1 Static Credentials (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN)
1.2 Web Identity Token (AWS_WEB_IDENTITY_TOKEN_FILE)
2. Shared configuration files.
2.1 SDK defaults to credentials file under .aws folder that is placed in the home folder on your computer.
2.2 SDK defaults to config file under .aws folder that is placed in the home folder on your computer.
3. If your application uses an ECS task definition or RunTask API operation, IAM role for tasks.
4. If your application is running on an Amazon EC2 instance, IAM role for Amazon EC2.
@bwplotka I'm about to fix the conflict, could we merge this before cutting 0.24.0-rc0 ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sort of confident that if you don't use an access_key / secret_key and leave everything empty, you can just use it 'as is'. For example we use KIAM roles that places the AWS env vars and this just works out of the box. Without the need for the AWS SDK.
It feels this is an implementation for something that already works? I could however be completely missing a feature or point :)
If this is actually required to work with for example assumed roles (so you don't need KIAM), etc. I think it's actually worth to implement it.
The purpose of this is indeed to allow Thanos to work with assumed roles based on all the mechanisms implemented in the AWS SDK. |
Could we please merge this? |
Added to my TODO list for reviewing |
+1 for this. I have this exact usecase as @sylr
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good 👍 the logic sounds good to me in https://github.com/thanos-io/thanos/pull/4667/files#r749424917 🤔
Could you please rebase on |
Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>
Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>
Signed-off-by: Giedrius Statkevičius <giedriuswork@gmail.com>
Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>
Is everything good for you @GiedriusS ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
* Add a pure aws-sdk-go auth Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr> * Upgrade github.com/aws/aws-sdk-go-v2 Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr> * Update CHANGELOG.md Signed-off-by: Giedrius Statkevičius <giedriuswork@gmail.com> * Move s3 conf test in validate() Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr> Co-authored-by: Giedrius Statkevičius <giedriuswork@gmail.com> Signed-off-by: Nicholaswang <wzhever@gmail.com>
Changes
Added an authentication method for S3 which uses the AWS SDK for go.
The AWS SDK handles more authentication methods than the minio-go lib, e.g:
/etc/thanos/thanos-storage.yml
/etc/thanos/aws-config.ini
Env vars:
Here the thanos sidecar running alongside the prometheus container has an AWS session provided via a web identity token file (EKS IRSA feature) and the config file make it so that the
thanos
profile is configured to use the session from the prometheus profile to assume a role in a different account.This allows to have cross AWS accounts connectivity without the need for access and secret keys (which are baaaaaad).
Verification