A small service for securely delivering Vault authorization keys to Mesos tasks and ECS containers.
--skip-tls-verify
flag to bypass TLS verification when communicating with Vault. This is useful for using self signed certificates or testing.usage-store
vault on the same mount point as policy-path
if vault-kv-version
is v1
.:
s. For example the rule foo:bar:baz/*
will allow a task named foo:bar:baz/baq
.Vault Gatekeeper has gone through an architectural change. These changes represent some of the things we have learned running Gatekeeper in production for the last year and others reflect changes in the best practices with Vault. Many of the changes are not backwards compatible so there has been a major version bump.
Gatekeeper no longer creates token directly, instead Gatekeeper now leverages Vault AppRoles to create tokens. This is cleaner than having Vault create tokens directly as now the Gatekeeper's token policy no longer needs to be a sudo token and you can more readily lockdown the tokens that Gatekeeper is able to create. Gatekeeper now also requires less direct configuration and more token based options can be directly configured with Vault on the AppRole.
Since Gatekeeper now uses AppRoles, the policy spec has changed as well. First, gatekeeper now loads policy information in a nested manner. For example, if your secret path is secret/data/gatekeeper
, Gatekeeper will also merge the policies in secret/data/gatekeeper/foo
and secret/data/gatekeeper/bar
as well. This makes it easier to logically split up your policy definition with a smaller footprint.
Next, the key name for the policy definition has changed. Previously it was just Task Name. Now the format is updated to include the scheduler name and framework name. For mesos this means the policy key will look something like this: mesos:marathon:api
. For ecs it will look something like this: ecs:foo
, since ecs doesn't have a framework.
Optionally, you can also set Gatekeeper to lookup by docker image name rather than task name. The policy key will then look something like mesos:myorg/myrepo:v1.0.0
.
Gatekeeper can now run in HA mode. By specifying vault
as your --usage-store
, Gatekeeper will keep the knowledge about what tasks have been given what tokens inside Vault. Next you can also specify addresses to other peers using the --peers
option. If a Gatekeeper instance is sealed, and another is unsealed, Gatekeeper will proxy token requests to an unsealed peer.
http://nemosupremo.github.io/vault-gatekeeper
/policies/reload
endpoint to reload loaded Gatekeeper policies.