Skip to content
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

S3 SignatureV4 Without Config File Credentials #735

Conversation

midnightconman
Copy link
Contributor

Changes

This PR fixes a bug in s3 config implementation, which allows the use of SignatureV4 without requiring s3 access_key or secret_key to be in storage object config. This allows the use of environment variables, aws credentials file, etc.

Verification

I tested this change by building locally and verifying SignatureV4 was used if config.SignatureV2 was false.

@midnightconman midnightconman force-pushed the midnightconman/s3-sigv4-20190114155331 branch from 3848f01 to 0541427 Compare January 15, 2019 01:35

signature := credentials.SignatureV4
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is not necessary, the signature is used by static credentials only. And by default, the following credential providers of minio provided will use SignatureV4.

  • EnvAWS
  • FileAWSCredentials
  • IAM

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe in theory, but unfortunately not in practice. Using v0.2.1 with the following bucket.yaml and environment variables (AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY), in AWS:

bucket.yaml

type: S3
config:
  bucket: my-secret-bucket-name
  endpoint: s3.us-west-2.amazonaws.com
  insecure: false
  signature_version2: false
  encrypt_sse: false

fails with the following error:

level=info ts=2019-01-15T19:38:03.422651711Z caller=flags.go:75 msg="gossip is disabled"
level=info ts=2019-01-15T19:38:03.422720714Z caller=factory.go:39 msg="loading bucket configuration"
store command failed: bucket store initial sync: sync block: iter: Access Denied

With this patch it works correctly.

Copy link
Member

@bwplotka bwplotka Jan 16, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm.. I think I know what is happening (:

So @jojohappy is right here, nothing really changed by moving signature outside of if config.AccessKey body.

I think this patch works for you because recently we fixed S3 auth order: #732 This was after 0.2.1 was released (: I think you accidenly assumed your patch work, but master most likely works for you as well (:

@midnightconman
Copy link
Contributor Author

Tests are taking too long... on my desktop (with xeon CPU), tests are almost taking 15 mins:

real    14m37.457s
user    1m27.843s
sys     0m29.667s

@bwplotka
Copy link
Member

bwplotka commented Jan 15, 2019

Yup, something is wrong with tests against:

github.com/improbable-eng/thanos/pkg/store 600.006s

We are looking on that: #740

@@ -91,3 +91,7 @@ ignored = ["github.com/improbable-eng/thanos/benchmark/*"]
[[constraint]]
version = "v0.11.0"
name = "github.com/mozillazg/go-cos"

[[constraint]]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this is needed?


signature := credentials.SignatureV4
Copy link
Member

@bwplotka bwplotka Jan 16, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm.. I think I know what is happening (:

So @jojohappy is right here, nothing really changed by moving signature outside of if config.AccessKey body.

I think this patch works for you because recently we fixed S3 auth order: #732 This was after 0.2.1 was released (: I think you accidenly assumed your patch work, but master most likely works for you as well (:

@midnightconman
Copy link
Contributor Author

You guys are right. 😄

I'll go ahead and close this PR. Thank you!

@midnightconman midnightconman deleted the midnightconman/s3-sigv4-20190114155331 branch January 18, 2019 23:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants