Nearly a year ago we announced the initial release of Confidant . Since then we’ve continued active development, and today are happy to announce the release of version 1.1, with some new major features and lots of bugfixes. Here’s some of the major changes we’ve made:
We’ve split our KMS authentication code into a separate library, kmsauth . Along with this, we’ve also introduced a new KMS authentication token version (v2), which enables service or user authentication. This change also allows for the KMS authentication token specification to be modified over time in a versioned manner. To make KMS authentication easier to manage we’ve added documentation for using IAM policy, rather than needing to rely on Confidant-managed KMS key grants. It’s now possible to disable the grant management in Confidant and solely rely on IAM policy. We’ve added a new form of secret, called “server-blinded credentials”. Server-blinded credentials enable you to manage secrets that even the Confidant server can’t decrypt. This feature can be used for secrets that are considered to be extra-sensitive, like TLS certificate keys, ensuring that only the intended targets can decrypt the secrets, even if access is accidentally granted elsewhere, or if the Confidant service itself is compromised. We’ve added an opinionated client: confidant-client . confidant-client can be installed through pip, via pypi. We believe the primary use of this library will be to fetch service secrets, so we’ve also included a formatter that can reformat the service secret data into a few output formats. Thanks to v2 KMS auth tokens, the client can be used to update Confidant data from the CLI, including support for the new server-blinded credentials feature. This client can also be used as a library, for directly embedding Confidant into your python applications. Thanks to contributions from Andy Brody at The U.S. Digital Service (USDS), the authentication code for frontend authentication has been refactored to be modular. As part of this work, Andy contributed an authentication module to support SAML authentication. Also, a huge thanks to Andrew Dunham and Jesse Luehrs, from Stripe, for contributing an authentication module for header authentication, for offloading frontend authentication to a proxy. We’ve added a proper login/logout flow for frontend authentication, and have switched the default session management to use secure cookies, rather than redis-backed sessions, removing the redis requirement for installation. We’ve made it possible for Confidant to bootstrap its own secrets, using KMS, to make deployment more secure.There’s more features and fixes that come along with this release; see the changelog for more information.
We’re also changing the development model for Confidant starting with this release. Though Lyft has a continuous release model for Confidant internally, our branching model thus far, for the public version, hasn’t properly reflected our efforts. We’ve been working in the 1.1 branch, and have been keeping master stable, to keep the initial release installation instructions accurate for the stable version. When viewing the project, this makes it seem like no work is occurring, since it’s in a non-visible branch.
Going forward we’ll be using a standard open source model of having master be the development branch, while having branches for stable and unreleased versions. The docker images for Confidant will reflect this, with latest being bleeding edge, and tags available for branches and releases.
As before, if you have any questions or need any help with Confidant, you can reach us in the #confidant channel in freenode , or the confidant-users in google group . You should also check out the docs and give us feedback in our github issues .
Interested in open source work and having a big impact?Lyft is hiring! Drop me a note on Twitter or atryan.lane@lyft.com.
N E X T→ Extending IAM Policy and AWS APIs Using KMS and Lambda