alexwilliamsca

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.

A few years ago I wrote a Ruby example if anyone wants to try it: https://github.com/aw/ruby-decision-table

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

SEEKING WORK - Remote

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.

Tech stack: Linux/BSD, PicoLisp, Ansible, Cisco, *SQL, Redis, HAProxy, Nginx, Lua...

Contact:

GitHub: https://github.com/aw

Email: alexwilliamsca at gmail dot com

Website: http://alexwilliams.ca

Business: https://unscramble.co.jp

I'm always open to interesting projects, so let's talk!

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).

[1] http://blog.unscramble.co.jp/post/128610241043/production-re...

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.

Let's just skip this like we did with IPv5.

CyaSSL - http://www.yassl.com/yaSSL/Products-cyassl.html

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.