4 ms·

Timely. I launched a SaaS a few months ago and have found early customers have expected custom domain names with SSL. It seems that not offering this is a deal

Timely. I launched a SaaS a few months ago and have found early customers have expected custom domain names with SSL. It seems that not offering this is a deal breaker these days. I didn't even consider that third parties such as yourself might offer a solution. Edit: I tried to sign up. I have to already choose lots of detailed config options? No option for AWS elastic beanstalk or EC? Asking for my AWS secret key without explaining why?

mrkurt 9y ago
Send me an email and I'll help (kurt@fly.io, or support@fly.io)! We've been working on improving the onboarding flow for new apps, but it's definitely complicated. Elastic Beanstalk and EC2 will work fine, and we can help you get setup. You can either run through ELB (if you already have that setup) or use our agent and let us handle all the load balancing: https://fly.io/docs/agents/ https://fly.io/docs/agents/ It should be obvious when and what we need AWS keys for. We only need those for private S3 buckets and to invoke Lambda functions. We don't want full access keys, just scoped IAM stuff!
- theossuary 9y ago
  One thing I really appreciate from companies is when they give me a policy with just the permissions they absolutely need to function (or a reference to a cross-account policy). That way I can review it and I'm not dicking around with trying to figure out the right permissions, and I know what all you may have access to. Getting s3 objects may be a deal breaker for example, unless the action is properly scoped to a bucket.
  - mrkurt 9y ago
    Yeah agreed. We should make that explicit, or even give people a CloudFormation template to set up a restricted policy. And to be clear, we don't need s3 access unless you want to serve files from a private s3 bucket. Most sites don't use that at all.
- subway 9y ago
  You don't need AWS keys at all. This enrollment flow flies in the face of best practices. Intead, you should be providing your users with instructions to create an IAM role for cross-account utilization. Ideally in addition to the instructions, you'd provide a minimal CloudFormation template defining such a role, with your minimum required permissions. Asking a customer to create a user and ship you a secret is asking for trouble.
  - schlarpc 9y ago
    And when you use a role like this, you really should use an external ID to avoid confused deputy attacks. http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_cre...
  - samstave 9y ago
    DING DING DING The problem is that a junior level of exposure may result in access+secrets being mistakenly given out. Yeah - they should be looking into say, cloudability, or any number of thousands of offerings ding just this.

mrkurt 9y ago

Send me an email and I'll help (kurt@fly.io, or support@fly.io)! We've been working on improving the onboarding flow for new apps, but it's definitely complicated. Elastic Beanstalk and EC2 will work fine, and we can help you get setup. You can either run through ELB (if you already have that setup) or use our agent and let us handle all the load balancing: https://fly.io/docs/agents/ https://fly.io/docs/agents/ It should be obvious when and what we need AWS keys for. We only need those for private S3 buckets and to invoke Lambda functions. We don't want full access keys, just scoped IAM stuff!

theossuary 9y ago
One thing I really appreciate from companies is when they give me a policy with just the permissions they absolutely need to function (or a reference to a cross-account policy). That way I can review it and I'm not dicking around with trying to figure out the right permissions, and I know what all you may have access to. Getting s3 objects may be a deal breaker for example, unless the action is properly scoped to a bucket.
- mrkurt 9y ago
  Yeah agreed. We should make that explicit, or even give people a CloudFormation template to set up a restricted policy. And to be clear, we don't need s3 access unless you want to serve files from a private s3 bucket. Most sites don't use that at all.
subway 9y ago
You don't need AWS keys at all. This enrollment flow flies in the face of best practices. Intead, you should be providing your users with instructions to create an IAM role for cross-account utilization. Ideally in addition to the instructions, you'd provide a minimal CloudFormation template defining such a role, with your minimum required permissions. Asking a customer to create a user and ship you a secret is asking for trouble.
- schlarpc 9y ago
  And when you use a role like this, you really should use an external ID to avoid confused deputy attacks. http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_cre...
- samstave 9y ago
  DING DING DING The problem is that a junior level of exposure may result in access+secrets being mistakenly given out. Yeah - they should be looking into say, cloudability, or any number of thousands of offerings ding just this.