v0.1.2

Changes

• There can be a potential network race where the framework may not have reported a task's status back to mesos (so according to mesos, the task hasn't started and is in TASK_STAGING). If we lookup the task in mesos, we don't get any status information for that task. In this case, we now sleep for up to 2s to get the task's status.

v0.1.1

Changes

• More logging around token requests.
• Display version on status page.

v0.0.7

Changes

• When we look up a task, and it has no statuses in mesos, deny the token request.
• To work around a bug in 0.5.2 (hashicorp/vault#1401), use the /create method instead of /create-orphan. This means gatekeeper tokens must be root/sudo'd tokens. you may want this anyways if you need to hand out tokens of arbitrary policies.
• Add the option for gatekeeper to generate its own new tokens when the token its holding onto reaches max_ttl (-self-recreate-token or RECREATE_TOKEN options).

v0.0.6

Changes

• Add cubby method for unsealing.
• Add TLS_CERT and TLS_KEY arguments for serving over TLS.

Cubby Method

The cubby method was added for ease of unsealing when you aren't serving over TLS. Since the token you send over the network can only be used once, it is useless after it used. You can create the token on the command line like so

$ vault token-create -policy="" -use-limit=2
Key             Value
token           74099365-c260-143a-bef8-0f96f3e03045 
token_accessor  10bb61c6-3eec-f954-abee-a1f40def4857
token_duration  0
token_renewable true
token_policies  [default]
$ VAULT_TOKEN=74099365-c260-143a-bef8-0f96f3e03045 vault write cubbyhole/vault-token token=REAL_PERM_TOKEN

And then provide the temp token, (74099365-c260-143a-bef8-0f96f3e03045 in this case) to gatekeeper for cubby unsealing.

0.0.4

This is the initial release of Vault Gatekeeper Mesos.