[00:00:06] yep [00:01:00] we have an open issue for generating random values in the interface: https://github.com/lyft/confidant/issues/3 [00:01:22] So the client above: that's a basic tool to pull out a secret then? [00:01:29] the most basic use-case right now is: I have a secret my service needs. I put it into confidant, an the client pulls the secret from confidant. [00:01:55] Gotcha. Can you elucidate a bit about token lifetimes? [00:01:59] sure [00:02:06] we're using KMS for auth [00:02:27] I'm mildly ignorant about KMS, I stared at the docs a while ago and got the basic idea [00:02:28] KMS lets you encrypt and decrypt. it restricts these actions via IAM policy. [00:02:44] I don't know the nits and grits tho' [00:02:46] it specifically uses something called encryption context to restrict access [00:03:02] confidant manages the grants on the auth KMS key for your IAM roles [00:03:29] it allows each role to use encrypt if the "from" encryption context value matches the IAM role name [00:03:50] it also allows each role to decrypt if the "to" encryption context value matches its IAM role name [00:04:19] let's say you have a service, in an autoscale group with iam role: example-production [00:04:50] it would be able to encrypt something with {"from":"example-production","to":"confidant-production"} [00:04:57] we'll assume confidant's IAM role is confidant-production [00:05:23] what it'll encrypt is a validity period. valid_from: x, valid_to: y [00:05:27] that's the token lifetime [00:05:50] Mhmm [00:06:01] confidant gets the encrypted payload, decrypts it (passing in the encryption context), and checks the validity period [00:06:18] if the period is too long it rejects the token [00:06:26] that's a config option on the server side [00:06:37] its default is 60 minutes [00:06:58] Ah, this limits replay attack surface, I see. [00:07:01] yes [00:07:17] OK, so it's not *secret* lifetime, it's *request* token lifetime. [00:07:18] we have plans on making replay basically impossible, too [00:07:25] indeed [00:07:30] the secrets never expire [00:07:39] I was really confused about why the secrets were rotating, it didn't make sense. [00:08:05] https://github.com/lyft/confidant/issues/5 <-- that's how we can make replay impossible [00:08:14] you'd be able to replay, but you'd get back encrypted content [00:08:21] which you wouldn't be able to decrypt [00:08:47] so, as for security... we're in the middle of getting an external audit [00:09:04] cryptography.io is relatively new, but it implements the Fernet spec [00:09:32] we use the implementation without using any primitives [00:09:57] otherwise confidant itself is relatively simple. it's been reviewed internally by a number of people [00:10:14] I got feedback from AWS about the use of KMS [00:10:26] I haven't received any negative feedback security-wise so far from them :) [00:10:32] So... what is Fernet: https://github.com/fernet/spec/blob/master/Spec.md is super unclear about where it came from [00:10:51] it's an opinionated implementation of AES with HMAC [00:10:54] and AAD [00:11:33] the basic idea is that it's a standard way to use AES that's considered safe, without the need to use primitives [00:11:39] kind of like libnacl [00:12:12] Sure, I see it's a construction of crypto primitives... it just is kind of bare of "and has been reviewed by xyz experts. ;) " [00:12:13] if you're more comfortable with libnacl, changing out the cipher code is relatively trivial [00:12:13] :) [00:12:52] (iow, a lack of social proof exists around fernat afaict, despite whether it's mathematically correct) [00:12:59] ideally we could support both and offer end-users a choice of which to use [00:13:03] * Ryan_Lane nods [00:13:17] yeah, it's an issue. [00:13:27] Cryto runs on social proofs, ironically, given the mathematics. [00:13:27] but it's way better than implementing the crypto directly [00:13:49] Sure, no gripe on that [00:14:06] I'm surely not opposed to adding support for other cipher suites, though [00:14:08] so the other unpleasant question is "how committed is Lyft to keeping this codebase alive" [00:14:23] some companies dump and run, some companies garden their codebases [00:14:23] pretty committed. we're using it extensively internally [00:14:56] I've actually been pushing code into the open source release and backporting into our private version :D [00:15:10] Nice! [00:15:19] I notice there's a CLA around PR acceptance. [00:15:31] I've run a bunch of open source projects and am pretty opposed to dumping code over the fence [00:15:56] yeah.... I'm trying to get that changed to a DCO [00:16:33] permissive licensed projects need either a CLA or a DCO for legal protection [00:16:46] it's a pain in the ass, but that's life. [00:17:09] http://elinux.org/Developer_Certificate_Of_Origin (if you aren't familiar with DCOs) [00:17:17] google helped me out there. :) [00:17:38] I was thinking, it'd be nice if I didn't have to go find the VP and get a waiver for a CLA. [00:18:09] So this is extremely useful to know [00:18:21] well, for now we require a CLA [00:18:31] I'm evaluating secret storage systems and Confidant maps really neatly into the needs we have. [00:18:36] cool [00:18:49] and also I like Lyft's service! :-) [00:18:56] even better :) [18:56:17] @logging-off [18:56:52] @logoff