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

blob/s3: add support for per-request options #3214

Closed
dkolbly opened this issue Jan 17, 2023 · 3 comments
Closed

blob/s3: add support for per-request options #3214

dkolbly opened this issue Jan 17, 2023 · 3 comments

Comments

@dkolbly
Copy link
Contributor

dkolbly commented Jan 17, 2023

Is your feature request related to a problem? Please describe.

I have an application where I need to use AWS STS (Security Token Service) to obtain
credentials to access an S3 bucket. The way these credentials are supplied to s3v2
is via an options list on the call to, e.g., ListObjectsV2 or GetObject. In order to use
the blob API I need a way to supply the appropriate option on the call.

Describe the solution you'd like

The solution I have in mind (and have prototyped on a fork) is that As() would
accept a *[]func(*s3v2.Options) argument which would allow the injection
of arguments to the call.

Describe alternatives you've considered

Considered a solution where the options could be expressed at the constructor
(s3blob.OpenBucketV2). This approach requires an extra level of conceptual
indirection, and in my situation passing information via the context
because the necessary information is not known until the call site.

Additional context

As mentioned above, I have a prototype of the As() approach that I've used
in my application to good effect. Patch is here:
https://gist.github.com/dkolbly/d5deae7f6efd942bed899e8b8c795495

@vangent
Copy link
Contributor

vangent commented Jan 17, 2023

Can these credentials be used at bucket instantiation time? If so, could you instantiate buckets lazily? I don't think there's much cost to doing so.

@dkolbly
Copy link
Contributor Author

dkolbly commented Jan 17, 2023

Yeah, I think the bucket instantiation is fairly cheap compared to network calls. I briefly considered an approach similar to that, but it would kind of turn my application on its head and doesn't seem to be how go-cloud is intended to be used. I'm using google wire, and the bucket configuration is bound at wiring time.

As a workaround, I could probably create my own bucket abstraction and open the bucket at request time. It would be easier if all my AWS (or even S3) calls were using the same STS auth, then I could just build an aws.Config with the right CredentialsProvider, but that doesn't wind up working out either.

How do people normally deal with setting s3.Options on requests in go-cloud? 🤔 When I was using minio I have to set s3.Options.UsePathStyle, and I think that would run into the same problem trying to use s3/blob.

@vangent
Copy link
Contributor

vangent commented Jan 18, 2023

Extending As to support this seems OK. Can you send a PR, including a test? You should be able to extend the existing tests (e.g., https://github.com/google/go-cloud/blob/master/blob/s3blob/s3blob_test.go#L236) with the new type; just verify the type conversion works.

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

No branches or pull requests

2 participants