v1.1.3

Changes

• Added the --skip-tls-verify flag to bypass TLS verification when communicating with Vault. This is useful for using self signed certificates or testing.
• Fixed how the roles were assigned to task that requested a specific role. Previously tasks would always get tokens assigned to the first role defined in the policy. Now they properly get a token with the role they wished to be assigned.

Issue Reference

• [#79] Unseal fails with self-signed cert
• [#80] Only the first AppRole on the roles list is used for authentication

v1.1.0

Changes

• Policies can now be matched by using a regular expression. This mode of policy matching is entirely opt-in and is useful in cases where prefix matching isn't powerful enough for your use case. See Issue #76 and PR #77.

Issue Reference

• [#76] Support wildcard inside task name or a more robust (regexp?) matching
• [#77] Feature/regexp policy matcher

v1.0.6

Changes

• Mesos state is now queried at the /state endpoint instead of /state.json.
• Added support for DCOS EE Strict Mode

Issue Reference

• [#69] DCOS Enterprise Mesos Support
• [#75] Mesos 1.8+ no longer supports the state.json endpoint

v1.0.4

Changes

• Token Renewal is now retried (with exponential backoff) is renewal fails due to a transient error.

Issue Reference

• [#65] Token renewal should be retried on failure

v1.0.3

Changes

• Token Renewal now occurs randomly within a 7 minute window if the token lease is longer than 10 minutes. This can prevent all gatekeeper instances going down simultaneously if there is an issue renewing a token.
• Gatekeeper will now throw an error if its started with usage-store vault on the same mount point as policy-path if vault-kv-version is v1.
• The wildcard logic was changed, and will now match partial subfields between :s. For example the rule foo:bar:baz/* will allow a task named foo:bar:baz/baq.
• Connections weren't being closed in various places which leaked connections.

Issue Reference

• [#63] --vault-kv-version not applied
• [#64] Enable wildcard with prefix.

v1.0.1

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.

Authentication Changes

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.

Gatekeeper Policy Changes

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.

High Availability

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.

Documentation Microsite

http://nemosupremo.github.io/vault-gatekeeper

Issue Reference

• [#1] Check if slave requesting the token with a given task id, is the same slave running that task id.
• [#3] Add tests
• [#14] Pluggable Scheduler/Provider backends
• [#34] HTTP is enforced to communicate with Mesos
• [#35] Enhancement request: Create tokens using roles
• [#46] New release required for latest security features
• [#49] Adding image id for verification of task being launched
• [#51] Enhancement request: Support dynamic policy names
• [#52] New Release tag?
• [#61] Enhancement request: Support for AppRole Auth Method

v0.6.0

Version bump 0.6.0.

v0.5.3

Changes

• Policy names now support glob-style matching, with the longest pattern taking priority. .
• Fixed a panic when the request to vault would fail.

Issue References

• #17 Adding support for glob matching of policies
• #18 Intermittent crash on token request

v0.5.2

Changes

• All custom cubbyhole token passing methods have been removed in favor of the Vault managed Response Wrapping. Old clients will not work with this version of Vault Gatekeeper and Vault Gatekeeper will only work with Vault 0.6.0 or greater.
• Add /policies/reload endpoint to reload loaded Gatekeeper policies.
• If there is no application token policy in Vault for Gatekeeper to follow, it now defaults to handing out "default" scoped tokens.
• Gatekeeper Client code has been refactored.

Issue References

• #4 Update to work with Vault 0.6
• #6 Allow client callers to pass config programmatically rather than only via env vars
• #8 Replace CubbyUnsealer with WrappedTokenUnsealer
• #12 gatekeeper client doesnt work with response wrapping

v0.1.3

Changes

• Will now redirect 307 requests when querying a Vault standby node.