Running osquery on CoreOS

Most things in CoreOS Container Linux can be run in containers, except when it doesn’t make sense. Here’s how I got osquery up and running.

osquery is an operating system instrumentation framework for Windows, OS X (macOS), Linux, and FreeBSD. The tools make low-level operating system analytics and monitoring both performant and intuitive.

osquery exposes an operating system as a high-performance relational database. This allows you to write SQL queries to explore operating system data. With osquery, SQL tables represent abstract concepts such as running processes, loaded kernel modules, open network connections, browser plugins, hardware events or file hashes.

Continue reading “Running osquery on CoreOS”

PGP Key Transition

Keybase | Gist

Hash: SHA512

PGP Key Transition Statement
José Padilla 
Fri Jul 28 12:54:01 UTC 2017

I have created a new OpenPGP key and will be transitioning away from
my old key. The old key has not been compromised and will continue to
be valid for some time, but I prefer all future correspondence to be
encrypted to the new key, and will be making signatures with the new
key going forward.

I would like this new key to be re-integrated into the web of trust.
This message is signed by both keys to certify the transition. My new
and old keys are signed by each other. If you have signed my old key,
I would appreciate signatures on my new key as well, provided that
your signing policy permits that without re-authenticating me.

The old key, which I am transitioning away from, is:

pub   2048R/9B2987B1 2014-03-04
      Key fingerprint = 6120 BB14 9792 D8E9 A371  B03C AAE3 EF57 9B29 87B1

The new key, to which I am transitioning, is:

pub   4096R/B55434E2 2017-07-28
      Key fingerprint = 58FD 4723 5047 E944 BDE3  4DC7 9A11 1405 B554 34E2

I disown all other and prior keys, so please don't use them.
Specifically, the following keys are not valid for me:

* 0x33CFB6D79478C173
* 0x56921E75F4A66D4C
* 0x7C09FCF380E5AFA3
* 0x55FCA69C27265701
* 0xAAE3EF579B2987B1 (as provided above)

The entire key may be downloaded from:

To fetch the full new key from a public key server using GnuPG, run:

  gpg --keyserver --recv-key B55434E2

If you already know my old key, you can now verify that the new key is
signed by the old one:

  gpg --check-sigs B55434E2

If you are satisfied that you've got the right key, and the User IDs
match what you expect, I would appreciate it if you would sign my key:

  gpg --sign-key B55434E2

You can upload your signatures to a public keyserver directly:

  gpg --keyserver --send-key B55434E2

Or email [email protected] (possibly encrypted) the output from:

  gpg --armor --export B55434E2

If you'd like any further verification or have any questions about the
transition please contact me directly.



Update Kubernetes Deployment after pushing image to Docker Hub


I recently moved’s workers deployment to Kubernetes in Google Container Engine. After setting the workers up as a Deployment I wondered how this would fit with my current setup for continuous deployment. On a previous setup, I relied on Docker Hub to automatically build, push tagged images, and notify Rancher via a webhook.

I ended up writing a small server to handle the webhook event from Docker Hub and PATCH the container’s image tags in the Kubernetes deployment which triggers a rollout.