serverless-sharp icon indicating copy to clipboard operation
serverless-sharp copied to clipboard

FR: Bring back multiple-bucket support

Open Mosnar opened this issue 6 years ago • 9 comments

We should be able to specify the bucket at the beginning of the URL to support multiple environments.

Mosnar avatar Jul 24 '19 19:07 Mosnar

Here's the plan:

  • We'll change the URI format to start with the bucket name with the full path.

  • We'll drop OBJECT_PREFIX and simply require the full path to the object

  • The allowed buckets setting will dictate the IAM rule so you can restrict bucket object access

Mosnar avatar Jul 25 '19 12:07 Mosnar

@timkelty After some thinking on this one, I realized there were some issues that may make this worth reconsidering, and I'd like your input.

In order to support multiple buckets, we also need to support multiple object prefixes to prevent arbitrary object access. There isn't a great way as far as I can tell to convert some arbitrary environment variable of buckets to a list of ARNs for the generated IAM policy. We would need to be able to accept something like: staging.assets.site.com/images/*, production.assets.site.com/images/* and convert that into the necessary format.

We support could support just denoting your own role to use in the serverless.yml and then the user could self-manage the allowed assets; HOWEVER, this means each request needs to try to access an object and fail, rather than using the environment variable to validate the request prior to the S3 request. Not sure if this is a big deal or not.

The other option is we use stages to support a single different bucket and object prefix for each environment.

Mosnar avatar Jul 30 '19 12:07 Mosnar

Does something like this make sense?

  • If SOURCE_BUCKET is empty, we assume:
    • user will configure their own role for s3 access in serverless.yml
    • first segment of the path will be the bucket
{SOURCE_BUCKET}/{OBJECT_PREFIX}/{path}?{query}

timkelty avatar Jul 30 '19 14:07 timkelty

FWIW - My main reason for needing this is to handle environment-specific buckets.

If serverless makes it easy enough to deploy a couple envs that are bucket specific…I'm probably ok with that. I'm new to serverless and have avoided this in the past because managing/deploying multiple stacks was a pain.

timkelty avatar Jul 30 '19 14:07 timkelty

@timkelty take a look at https://serverless.com/framework/docs/providers/aws/guide/variables/

You can then import bucket name from a file: ${file(./env-vars.yml):image_bucket, "default-s3-bucket"}

Just swap the env-vars.yml out when deploying to different environments

ganey avatar Jul 30 '19 14:07 ganey

Done - see new settings.yml file

Mosnar avatar Aug 04 '19 18:08 Mosnar

@Mosnar unless I'm mistaken the new settings stuff doesn't really address the original feature request.

The request was to have multiple bucket support on the same deployment, so you wouldn't have to deploy multiple.

That said, serverless/settings.yml makes it easy enough to deploy and manage multiple versions, and supporting multiple buckets is tricky from a permissions perspective, so I say we still cancel/table this for now.

timkelty avatar Aug 09 '19 11:08 timkelty

Fair nuff

Mosnar avatar Aug 09 '19 11:08 Mosnar

I agree with @timkelty. :+1: for this feature request. As long as it doesn't overcomplicate the simple use case / configuration. It would simplify multi-environment, mutli-bucket deployments tremendously allowing a single api gateway and cloudfront distribution to service multiple environments while still segregating media across environment buckets. Additionally, it would enable some really interesting multi-tenant scenarios where a single deployment could service many buckets. Very cool.

tyrauber avatar May 15 '20 10:05 tyrauber