Ohhh Cyril haha you're right! Yes of course I remember packager.io. Sorry about that!! In any case, I still find this very interesting and will definitely check it out. Thanks for the heads-up.
Oh it's nice to see how well you've pivoted from PullReview! It's a great idea and I'll be trying it out shortly.. As a side note, @crohr was one of our first beta tester and paying customer of jidoteki.com (now on-premises.com), sadly their PullReview service didn't do as well as planned, but PullPreview seems to be a home run. I'm happy to see them building this service and look forward to watching the development.
There's still a bit of "manual" work to get someone up and running on our Meta appliance, so unfortunately you would have to go through our sales process. However if you just want a video or screen recording of how it works then I can put something online in the next hour or two.
For baking the machine, we use Ansible under the covers and have a set of Lisp scripts to manage everything. As for image formats: qcow2, raw, vhd (and vmdk in the .ova file).
Not trying to hijack Gravitational's thread, please contact me (email in profile, or 'aw-' on FreeNode) if you want to discuss more.
A minimal immutable VM image which is finely tuned and hardened is the exact approach we're taking with https://on-premises.com - except we haven't focused on k8s workloads. We've found that customers would much rather import a VM than "install" something, however there are valid use-cases which require special monitoring tools and other customizations which are not possible on an immutable system. Gravity is interesting and seems to meet that demand.
Yes, exactly! In Japan there's also no fees or sales tax on Amazon gift cards (physical ones), and you can purchase them in arbitrary amounts I think max 100,000 JPY (~$1000 USD). Amazon.com provides one-day free shipping with gift card purchases, but could have a surcharge for oversized, heavy, or international items. I'm not sure if any of this applies to digital gift cards though.
I've noticed this as well. The trick is to _remove your credit card_ from your Amazon account. It significantly reduces the "traps" and prevents them from automatically subscribing you to Prime. I now purchase Amazon Gift cards instead (also, free shipping when using a gift card).
A few things you can do: 1) place Nginx in front of the webhooks service (it will allow you to filter traffic by IP, request headers, etc - a bit less efficient than a proper firewall IP filter). 2) listen for webhooks on a port other than 443 (GitHub allows this). 3) use a unique URL for webhooks, with a unique/random/long token as part of the URL (this way only someone who knows the exact URL will be able to reach it). 4) of course, use a valid TLS certificate 5) validate all headers sent by GitHub (user-agent, x-github-delivery, etc). 5) provide a unique/random/long shared "secret", different from the URL token, for validating the sha1 signature of the request. 6) only accept a valid JSON payload and application/json content-type. 7) only accept specific events from the x-github-event header (ex: push, ping). 8) reject EVERYTHING ELSE with a 404. 9) validate the actual content of the JSON payload (does it contain the proper key/value pairs you need? discard the rest). 10) enable audit-logging of requests, so you can see any attempts at people trying to "hack" your webhooks service.
I recommend running the webhooks (external service) as an entirely different application from your internal services. If it's a nodejs app, and your main internal app is nodejs, then you'll need to run 2 nodejs processes (and not as root).
Also if you can, try running the webhooks service on an entirely different machine (vm?) - and have it talk to Jenkins through the network (ex: as others have suggested with a message queue or API call).
If you're filtering by IP (might be troublesome if GitHub's IP range changes), most of the above will be overkill.
Edit: to answer your last question: security is a process, whether it's full-time or not depends on how much you care.
Edit 2: fix typo
Ex-GitHubber specializing in infrastructure design, automation, disaster recovery, capacity planning, and scalability.
I'm not interested in AWS or other cloud platforms, since I prefer working with bare-metal and VM deployments, switches, routers, and hardware appliances.
Founder of https://jidoteki.com here - we provide the ability to go from SaaS to On-Premises in less than one week[1] as well, without the need to jump into Docker.
I think ReadMe's approach is pretty good, and I applaud them for making the move.
Our aim is a bit different from others, as we focus exclusively on "actual" on-premises (local virtual machines), as opposed to "on someone else's premises" (AWS).
This is an interesting post, as Gravitational is doing something very similar to us - https://jidoteki.com - in fact that blog post reflects much of what I wrote a year ago on our company blog - http://blog.unscramble.co.jp/post/134388066008/why-we-care-a.... We focus on the more commonly known concept of on-prem (not AWS/Kubernetes), in other words on dedicated hardware in a private datacenter or hosting facility, by creating fully offline, updateable, and secure virtual appliances designed specifically for self-hosting.
The Keyless SSL server is open source and available on GitHub - https://github.com/cloudflare/keyless - although I'm wondering if its dependence on OpenSSL was a good choice.