We currently have an RoR app hosted at Heroku, with an AWS RDS backend. Currently, the RDS instance is available to all inbound traffic. To only allow traffic from my Heroku app, can I whitelist the applicable IP blocks here:
https://ip-ranges.amazonaws.com/ip-ranges.json
...or is an add-on like Proximo or QuotaGuard my only option?
Additionally, are there security concerns for having an RDS instance available to all incoming traffic, given that the RDS instance is password protected?
As Jarmod’s comment suggests, it’s not advised to expose your database to the world, even if it’s password protected and the communication is encrypted. It’s not that your data is entirely exposed, but when dealing with sensitive information, it’s advised to control who can request access to the data in addition to the user/password authorization.
Unfortunately, when you run on Heroku you don’t have too many options. Even Heroku’s own Postgresql database is publically accessible if you know it’s url/endpoint.
If you want to improve security, you’ve two options:
1) Use an outbound proxy addon
As you suggested, you can use a proxy addon such as Proximo or Fixie and configure AWS security groups to only accepts connections from the proxy's static IPs.
I’ve detailed the downsides of this approach in my reply to: “How to properly determine Amazon AWS Heroku subnets?”
2) Migrate your application from Heroku to AWS
Depending on your company size and product maturity, it might be a good idea to consider a migration from Heroku to AWS.
When your application’s stack is run entirely from within AWS, you’ll have much more control over security and can decide how far you want to go to protect your data.
I helped a few clients with similar migrations and security was one of the top 3 reasons to migrate from Heroku to AWS.
Hope that helps.
Related
My backend is a simple dockerized Node.js express app deployed onto elastic beanstalk. It is exposed on port 80. It would be located somewhere like
mybackend.eba-p4e52d.us-east-1.elasticbeanstalk.com
I can call my APIs on the backend
mybackend.eba-p4e52d.us-east-1.elasticbeanstalk.com/hello
mybackend.eba-p4e52d.us-east-1.elasticbeanstalk.com/postSomeDataToMe
and they work! Yay.
The URL is not very user friendly so I was hoping to set up API gateway to allow to me simply forward API requests from
api.myapp.com/apiFamily/ to mybackend.eba-p4e52d.us-east-1.elasticbeanstalk.com
so I can call api.myapp.com/apiFamily/hello or api.myapp.com/apiFamily/postMeSomeData
Unfortunately, I can't figure out (i) if I can do this (ii) how to actually do it.
Can anybody point me to a resource that explains clearly how to do this?
Thanks
Yes, you can do this. For this to happen you need two things:
a custom domain that you own and control, e.g. myapp.com.
a valid, public SSL certificate issued for that domain.
If you don't have them, and want to stay within AWS ecosystem, you can use Route53 to buy and manage your custom domain. For SSL you can use AWS ACM which will provide you with free SSL certificate for the domain.
AWS instructions on how to set it up all is:
Setting up custom domain names for REST APIs
I've been an amateur developer for quite some time now and this is the first time I've actually needed to set up the domain and SSL for a website. I already bought a domain name from GoDaddy and I'm using my rails as my backend. But it seems that on almost all of the guides online (the ones I've come to search) is for the Heroku paid dynos (I'm on the free tier) or has their website hosted somewhere else/bought the domain somewhere else. As of now, I'm not actually sure how straightforward this should be but any guide to free SSL cert generation and free setup would be nice.
You have 2 options here:
Use Heroku domain app.herokuapp.com as this is encrypted and served through https.
If you want to use a custom domain. There is no way but to use a paid dyno. There were some tutorials on how to do this manually and a couple of projects that allowed you to do so on free dynos but they are all outdated/deprecated.
There is no need to configure anything on Heroku's side if you start off with a paid dyno.
ACM is enabled by default for all Common Runtime apps created after March 21, 2017 that run on Hobby or Professional dynos.
To upgrade, simply run heroku ps:resize web=hobby via heroku cli. Then, to enable letsencrypt automated certificate, simply run heroku certs:auto:enable. Just make sure your DNS is activly pointing to the currect address before doing so or you'll need to verify your DNS target.
Docs: https://devcenter.heroku.com/articles/automated-certificate-management
deprecated project: https://github.com/dmathieu/sabayon
outdated tutorial: https://github.com/dwyl/learn-heroku/blob/master/SSL-certificate-step-by-step-setup-instructions.md
I have used the same setup for my heroku app. By default heroku free tier gives ssl on your web app.
Like if you hit url yourwebsite.herokuapp.com, it is encrypted and provides ssl for free.
But when you will add a custom domain name to your heroku app, then its without ssl. You cannot use ssl on it unless you moved to hobby dyno(paid)
Here is what heroku says
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
My team and I are currently building a Ruby on Rails web application (SaaS model) that will be used by at least 5k users, and there will be probably more after.
While we reach the end of the development process I was wondering what kind of hosting we were going to use.
I first thought about using a standard web server with Nginx and Puma, and a second server dedicated to the database, but the scalability is a thing that we really want. So I started to check for an alternative solution (knowing the fact that no one of our team is an admin), and I end up on Heroku.
So, my question is why should I use something like Heroku ? After watching the prices I've the feeling it's going to cost more than a standard server for less performances, but i'm still intrigued by it : if people use it, there must be a reason.
Heroku & DigitalOcean etc, are just services which make deploying to "cloud" hosting easier. Heroku uses AWS's computing infrastructure to host your apps, but provides an environment to help deploy them easier:
Why do people use Heroku when AWS is present? What distinguishes Heroku from AWS?
Heroku vs...
Some of the important points to note about Heroku is you don't have direct access to your database, as well as relying on their infrastructure to hold up (E.G if something happens to their datacenters -- which has happened before -- you're at the mercy of Heroku & AWS's engineers).
There are two issues we have with them:
You're obliged to use their AWS Postgres DB
You've got to route through Heroku's domain
--
Choice
The choice you really have is whether to use something like RackSpace (like us), or use a service such as Heroku or DigitalOcean. To me, there is not much difference, as Heroku / DO just provide an environment to push to VPS's running on their respective partner hosting providers.
With the ease of deployment (git push), you get the downside, which is your database, environment etc will not be directly configurable. I.E if you use Heroku, it's very difficult to get off it (transferring data etc).
By using a direct solution, such as RackSpace or AWS, you are in control of the environment, which means you get direct access to your database, dependent services & other aspects of the system. Of course, it comes with more maintenance, but you aren't locked into one system, as you are with Heroku
--
System
In terms of the system, Heroku locks you into using their domain infrastructure:
The domain example.herokuapp.com will always remain active, even if
you’ve set up a custom domain. If you want users to use the custom
domain exclusively, your app should send HTTP status 301 Moved
Permanently to tell web browsers to use the custom domain. The Host
HTTP request header field will show which domain the user is trying to
access; send a redirect if that field is example.herokuapp.com.
This is coupled with the lock-in of using the likes of different dependencies & other aspects of the Heroku system. It's basically a store-front for Amazon's AWS infrastructure
--
Recommendation
If you expect to have 5k users, I would highly recommend looking at
setting up your own environment, probably with RackSpace (as we
use them).
It's my opinion that Heroku is great for developers who just want to get an app up-and-running, but it's not very good with providing an environment you can control.
Some examples of this include your database - setting up on Rackspace etc means you get to define your database yourself. On Heroku, the db is kept in a third party datacenter, which you never see (try setting up PHPMyAdmin on Heroku)
Another example would be how you're going to scale the application. If you have memory leaks etc, you'll be far better positioned to have your own stack in place, rather than relying on someone else's. It allows you to define the specific details of how the app should operate - giving the ability to scale much easier
So I host with company X and have my domain on there. I deployed my app to heroku and pointed my domain at it. I can't wrap my head around if I am hosting my site on heroku now or if I am hosting it on company X's servers.
I would assume I'm hosting on herokus server because that is the most logical, but just keep having this brainfart.
Could someone please explain this to me?
Your application is on Heroku's server. All company X has done is perform the DNS magic necessary to map the friendly URL (www.yoursite.com) to your Heroku deployment.
Amazon
You should also be aware that Heroku doesn't actually "store" the app on its own servers - it uses Amazon's ec2 cloud to create instances of your app
So although you have your domain with company X, your app handled through heroku, it will actually be running in one of Amazon's data centers
Keep that in mind when you start to grow (you may find benefits of using Amazon directly)
I am running a Rails app on the AWS infrastructure using several EC2 instances, a RDS DB, a round robin session-sticky load balancer and Route 53.
The application is serving pages for several domain names (same app looks and functions different depending on domain name).
The Rails code is hosted on a NFS share on a staging instance where the web server is running in development mode, while the other boxes load the apache config and application code via NFS and run in production mode.
What I'd like to do is to SSL-enable the whole thing as we're starting to process payments and whatnot. Due to the nature of the application and the heavy apache/Passenger optimization in place, I can't set up a vhost for each domain, but rather use a wildcard for www.* to load pretty much the same code, and the app does the rest internally.
Haven't really been able to figure out an ideal way to resolve this. Would anyone have an idea?
Thanks!
After a bit of discussion in the comments we came to this conclusion:
The application is currently hosted in one single <vhost> on Apache where the Application does the differentiation between hostnames for the different layouts.
The problem here is to support SSL without having to setup each domain with it's own certificate and a different vhost as that would require running the Rails app multiple times where it's unnecessary.
By using a Multiple Domain Certificate (MDC) this problem can be solved with only one vhost and one certificate, but MDCs are more expensive than normal certificates. So depending on the number of domains you need to support it may be cheaper/easier to just do it manually with multiple certs, or opt to pay the more expensive MDC but save time and maintenance cost.
While at it I found this nice wikipedia comparison of Certificate Authorities and their trust level in different browsers:
http://en.wikipedia.org/wiki/Comparison_of_SSL_certificates_for_web_servers