Skip to content
This repository has been archived by the owner on Jan 8, 2024. It is now read-only.

v1.0.1
Compare
Choose a tag to compare
@nemosupremo nemosupremo released this 23 Jul 07:59
· 23 commits to master since this release
v1.0.1
8744532

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
Assets 17
Loading