feat(nginx): ssl client certs

[efultz]

This pull requests adds ssl client certificate functionality to the deis-router. Users can configure their deis-router to lock-down their apps with client certificates. When configured, the deis-router will reject any incoming connections that don't have the correct client certificate.

This pull request includes:

1. model.go code for reading new annotations from router deployment
2. config.go code for writing nginx config
3. expansion of existing tests to cover ssl client certificate functionality
4. configuration spec added to annotations table in README.md
5. Brief 3-paragraph description in README.md

[deis-admin]

Thanks for the contribution! Please ensure your commits follow our style guide. This code will be tested once a Deis maintainer reviews it.

[deis-bot]

@ultimateboy, @mboersma and @krancour are potential reviewers of this pull request based on my analysis of git blame information. Thanks @efultz!

[codecov-io]

Current coverage is 55.35% (diff: 63.63%)

Merging #286 into master will increase coverage by 0.23%

@@             master       #286   diff @@
==========================================
  Files             6          6          
  Lines           381        392    +11   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
+ Hits            210        217     +7   
- Misses          151        153     +2   
- Partials         20         22     +2   

Powered by Codecov. Last update 563d731...9dbe532

[kmala]

Jenkins, Add to whitelist.

[kmala]

This looks good but will also have @krancour take a look at this.

[krancour]

@efultz thank you for the contribution, and I apologize that it's taken so long for us to get around to reviewing this.

We've discussed internally and have come to the conclusion that because this is an authentication mechanism, it belongs in the purview of the application(s) and not the router. Consider it from this perspective: If clients authenticated using a username and password instead, I don't think most operators would reasonably expect the router to handle that, and that seems to be the giveaway that auth is an application concern.

To be perfectly fair, the router might already be bloated with concerns that should never have been its to address. (More than any other component, the router has been amended time and again to address one-off requirements of individual users.) As of recently, we've been contemplating the future direction of the router. This has included discussions of whether it can either become or be replaced by a proper Kubernetes ingress controller. To that end, we've recognized that some future iteration of the router just routes and doesn't endeavor to walk the line between highly-configurable web server and one-size-fits-all web server. A first step in that direction, necessarily, has to be reining in the addition of new features that aren't specifically oriented around the core responsibility of routing.

[efultz]

Thanks for the explanation. You raise fair points and I certainly can't fault you and your team for maintaining the project's vision.

I developed this feature from the mindset of network security instead of authentication. Client SSL is (currently) the only way to build a secure connection between Amazon's API Gateway and a Deis backend. One of the restrictions of API Gateway is that traffic from the API Gateway to Deis happens across the public internet. The only way to guarantee that public traffic originated from API Gateway is with client ssl. The SSL connection must be terminated at-or-before the deis-router, because the deis-router needs access to the Host header.

I plan to maintain this feature in our fork, though I don't promise that I will maintain it very well 😉

@krancour I have another change to deis-router that's slightly simpler than this feature. Now that this feature was rejected, it's hard for me to predict if you'll want my other change. What's the right channel to discuss this with you?

[bacongobbler]

@efultz it's best to either describe the use case you wish to solve in an issue here, or you can come chat in the community channel. The former would be easier to have a longer discussion, but the latter is available at https://slack.deis.io/ :)