20:01:01 <redrobot> #startmeeting barbican
20:01:01 <openstack> Meeting started Mon May  4 20:01:01 2015 UTC and is due to finish in 60 minutes.  The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:04 <openstack> The meeting name has been set to 'barbican'
20:01:13 <redrobot> #topic Roll Call
20:01:23 <elmiko> yo/
20:01:24 <dave-mccowan> o/
20:01:25 <hockeynut> o/
20:01:30 <arunkant> o/
20:01:35 <rellerreller> o/ (for 30 minutes)
20:02:53 <redrobot> as usual the agenda can be found here:
20:02:56 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican
20:03:01 <redrobot> #topic Action Items
20:03:22 <redrobot> #link http://eavesdrop.openstack.org/meetings/barbican/2015/barbican.2015-04-27-20.00.html
20:03:40 <redrobot> x3k doesn't seem to be around
20:03:56 <woodster_> o/
20:03:57 <redrobot> #action x3k to submit CR to barbican-specs for Versioned Objects
20:04:09 <redrobot> #action redrobot to talk to Greg Swift about DB being used in Fedora
20:04:16 * redrobot hasn't had a chance to work on action items
20:04:24 <redrobot> #action redrobot to clean up the barbican-specs repo
20:04:37 <redrobot> so I'll kick the can down the road
20:04:46 <alee> o/
20:04:57 <redrobot> #topic Let's discuss and fine-tune the 'read-only' ACL user
20:05:40 <redrobot> woodster_ do you want to talk about this topic?
20:05:52 <redrobot> #link https://etherpad.openstack.org/p/barbican-acl-read-only-user-discussion
20:05:57 <woodster_> I created a etherpad to help discuss this one
20:06:15 <woodster_> The long and the short is that there is a use case for retriving secrets by 'name' rather than UUID
20:06:31 <woodster_> ...for ACL-listed users
20:06:49 <woodster_> The current ACL approach only allows whitelisted users to get/decrypt secrets by UUID
20:07:05 <redrobot> woodster_ we currently only allow secret retrieval by uuid
20:07:11 <redrobot> woodster_ since names are not guaranteed to be unique
20:07:11 <arunkant> woodster_, so do we need a secret/container lookup by name?
20:07:27 <woodster_> For automation use cases, wherby a system like Chef will retrieve a secret later, it would be nice to retreive by name instead
20:07:50 <woodster_> well, a starting point would be allowing the ACL user to retrieve a list of secrets
20:08:12 <woodster_> ...or else allow them to have the  audit role, and let the audit role get a list of secrets by name
20:08:24 <redrobot> woodster_ just to be clear here, we're not talking about the current feature of being able to filter by name
20:08:29 <woodster_> the audit role currently doesn't support getting lists of secrets/containers
20:08:51 <woodster_> redrobot: well the current get list of secrets call gets teh list of secrets for a project
20:09:02 <woodster_> redrobot: you can then add a query parameter to filter by a name for examp;le
20:09:16 <woodster_> redrobot: the ACL user can't use this call currently though
20:10:01 <woodster_> redrobot: so it seems a way for an ACL user to see all the secrets they are on the whitelist for, by name (or any other secret metadata) would be useful
20:10:23 <redrobot> woodster_  It seems that maybe list needs to be able to also include secrets that are accessible through the ACL?
20:10:27 <rellerreller> woodster_ Would it be fair to say that you want to have access control for a key that does not yet exist? I'm trying to fully understand the issue.
20:11:25 <woodster_> rellerreller: the detailed sequence is on the etherpad, but the idea is that the key is put up first (by an admin let's say), and then processes thereafter consume it. Similar to the LBaaS use case actually
20:11:48 <redrobot> woodster_ so if the key is stored first, why isn't the UUID available for retrieving it later?
20:12:12 <woodster_> redrobot: my concern with modifying the current get call is that I think get by whitelist would be a more compute intensive query
20:13:00 <woodster_> redrobot: that's why I'm suggesting adding something like a 'acl_only' flag as a query parameter to only support ACL queries
20:13:25 <woodster_> redrobot: it might also be confusing if both ACL and project-based secrets are in the same result set that is returned
20:14:28 <arunkant> woodster_, so this "acl_only" list is going to be same regardless of which project secrets you are requesting ..right?
20:14:39 <woodster_> redrobot: if a script like a Chef cookbook is retrieving that key later, it a full URI to the secret would have to put into the ocnfigs. If that secret is later rotated, the URI would chagne, and so would the need to update the chef script.
20:14:48 <woodster_> redrobot: if by name, then the chef script woldn't have to change
20:15:12 <redrobot> woodster_ I would argue that the URI could be added as a databag value.  If the secret is rotated, the value should be updated.
20:15:21 <woodster_> arunkant: that's correct, it would search across projects, giving you all the secets you are on the ACL for
20:16:03 <hockeynut> woodster_ that does sound like a lot of DB query work
20:16:31 <woodster_> redrobot: that would be an additional step you'd have to put into your deployment after rotation that otherwise would not be required
20:17:24 <woodster_> hockeynut: yeah, that's why I'd prefer separating the result sets returned. Combining the result sets, esp. for a paged list request, would be more painful I think
20:18:06 <hockeynut> so the issue is that acl cuts across projects
20:18:37 <woodster_> redrobot: we've talked about adding more ACL support to our resources, beyond the simple get by UUID one we have now. Adding support for ACL lists I think is the next logical one and has benefits on the automation front I believe
20:18:52 <woodster_> hockeynut: indeed it does
20:20:28 <woodster_> (are folks gathering their torches and pitchforks?)
20:20:40 <redrobot> woodster_ I think it's a big enough change to warrant a blueprint.   I'm on board with adding a new flag to GET /secrets so that it only returns ACLed secrets.
20:20:55 <redrobot> woodster_ I'm still not sold on the get-by-name feature though
20:21:06 <redrobot> woodster_ for starters we would have to start enforcing name uniqueness
20:21:08 <woodster_> redrobot: this definitely requires a blueprint, but I wanted to make sure the general approach was ok with folks
20:21:15 <arunkant> woodster_, so there would be two step..one get UUID(s)  by using "acl_only" and "name" query parameters..and then using that UUID to get actual key data...is that the flow?
20:21:35 <redrobot> arunkant that's what I'm trying to get to also.
20:22:14 <woodster_> redrobot: I'm suggesting not enforcing uniqueness...so two 'foo' named secrets would show up in the get by secrets...the admin of the project would need to ensure only one secret exists.  Or better still use named containers to hold secrets
20:22:51 <woodster_> arunkant: that is correct...so still a two step process since uniqueness is not assured.
20:22:57 <redrobot> woodster_ I see, but the fetching of the secret would still use UUID?
20:23:23 <woodster_> containers do enforce secret-key-name uniqueness though, so they would be the better choice
20:23:30 <elmiko> woodster_: requiring admins to ensure name uniqueness seems a little fragile, imo
20:23:35 <woodster_> redrobot: yes, the actual decrypt would be by UUID
20:23:54 <redrobot> woodster_ ok, that was the part that wasn't clear for me.   I'm on board now. :)
20:24:20 <woodster_> elmiko: I think folks would use containers, like 'staging-dfw' to represent an environment let's say. And then have 'database-n01' as a secret key inside that container
20:24:35 <elmiko> woodster_: yea, that makes much more sense.
20:24:37 <rellerreller> Are container names unique?
20:24:42 <woodster_> of course the other thing that's needed if containers are use is....
20:24:57 <woodster_> ...the abilty to modify the secret put into a generic container type :)
20:25:10 <redrobot> rellerreller container names themselves are not unique.  but within a container, you assign names to the secrets it contains, and those names are unique per container.
20:25:37 <rellerreller> So how does adding them to a container help?
20:26:00 <woodster_> rellerreller: container names are not unique either but are easier to keep static...once you create your 'staging-dfw' environment container, you are done. Never have to mess with it again (errr...unless we aren't cool with mutable generic containers :)
20:26:02 <rellerreller> If the container name is not unique then it seems like you still have the same problem where two things could be named the same thing.
20:26:40 <redrobot> woodster_ sounds like the filter-by-name feature is needed in the containers, not the secrets
20:27:04 <woodster_> rellerreller: the nice thing about a mutable generic container is that the key-name uniqueness is enforced...you could only have one 'database-n01' secret stuck in there at a time
20:27:05 <redrobot> woodster_ the chef script would filter-by-name on container, then just use the container references to fetch the secrets it needs
20:28:07 <rellerreller> woodster_ But I still have the problem that two containers could be named the same thing. I feel like we just pushed that problem up a level.
20:28:30 <woodster_> redrobot: that is probably true. Simple projects with one or two secrets probably would just go the secret route I'd think
20:28:32 <rellerreller> I thought the problem was that two keys could have the same name and you need to know which one to choose.
20:29:30 <woodster_> rellerreller: I think the issue is a referencing one...having a common name to refer to a secret in automation/down-stream scripting that doesn't have to change if I change/rotate the upstream secret. Also having a human readable name.
20:30:12 <woodster_> rellerreller: I don't think uniqness by name is a requirement though.
20:30:35 <redrobot> rellerreller sounds like woodster_  can push the responsibility to keep the name unique to his user
20:30:56 <woodster_> rellerreller: if we did want that as a requirement, I think we'd need a new tagging field for that purpose
20:31:02 <rellerreller> redrobot I agree. That's why I think it could be on secret. Not sure why containers are being involved.
20:31:37 <woodster_> redrobot: well in the automation use case, the admin would be responsible for managing secrets properly for the system
20:32:26 <woodster_> rellerreller: if on the container, then if I change that databse password, I just replace it within the container...the container UUID/name would not change
20:32:46 <redrobot> so I think the changes boil down to:  Add flag to list secrets by ACL-secrets only, and ensure it can filter by name.  And also add filter-by-name to containers.  That hsould about cover it, right woodster_ ?
20:32:50 <woodster_> rellerreller: if we don't want mutable generic containers though, then I agree the benefit is not as great
20:33:19 <redrobot> woodster_ I think Generic Containers are currently mutable, so no change needed there.
20:33:27 <woodster_> redrobot: I think the ACL-based query is needed
20:33:52 <woodster_> redrobot: well we don't have a PUT for containers, so they aren't 'officially' mutable :)
20:34:15 <redrobot> woodster_ I think a POST will re-write a generic container?
20:34:17 <woodster_> redrobot: I was hopeful everyone was on board with makign them mutable for real (by adding PUT support)
20:34:47 <woodster_> redrobot: oh wow, not sure I like that
20:35:27 <woodster_> redrobot: I'll research that one. I'd really prefer a PUT call to modify a container though.
20:35:35 <redrobot> woodster_ I'm making a note to look into that.
20:35:52 <redrobot> #action woodster_ to research mutability of generic containers.
20:36:02 <woodster_> redrobot: I can 'put' (pun intended) up a blueprint to add PUT containers support
20:36:14 <elmiko> lol...
20:36:15 <joesavak> fyi - keystone- uses post to update users - http://docs.openstack.org/developer/keystone/api_curl_examples.html#post-v3-users -
20:36:27 <joesavak> probably just need to see what other os services do too in that research
20:36:34 <woodster_> rellerreller: are you ok with all of this though, esp. the ACL query part?
20:36:49 <woodster_> joesavak: good point, I'll take a look
20:37:19 <rellerreller> woodster_ I don't really have a strong opinion at the moment.
20:37:23 <elmiko> +1 for PUT to update
20:37:26 <redrobot> joesavak woodster_ the way I'm used to seeing these is that POST will overwrite the entity, and PUT adds to it.
20:37:55 <dstanek> HTTP semantics say that PUT will replace the resource
20:38:05 <joesavak> +1 redrobot. In the case of keystone PUT is more used for assignments. "Add" role to group of users for example
20:38:06 <woodster_> I've always thought POSTs were creational, and PUTs replaced the entity (without changing its UUID)
20:38:07 <rellerreller> woodster_ I'm mostly trying to figure out if this is necessary and what problem is being solved. Mostly curious. Will there be a bp?
20:38:25 <woodster_> rellerreller: yes, I'll put up a bp for this
20:38:33 <rellerreller> Cool.
20:38:33 <elmiko> woodster_: that's what i thought too
20:38:44 <dstanek> woodster_: you are mostly correct (POST is more general)
20:38:46 <rellerreller> I have to run now. Later :)
20:38:53 <redrobot> bye rellerreller !
20:38:57 <elmiko> later!
20:39:01 <hockeynut> L8R
20:39:04 <woodster_> rellerreller: take care
20:40:21 <woodster_> I can see what other projects do here though
20:40:43 <elmiko> might be worth checking the api-wg guidelines too, not sure if this issue has been covered yet though.
20:41:02 <arunkant> woodster_, not sure how name uniqueness issue is resolved..looking forward to this bp as referring keys by name can be useful in some cases.
20:41:18 <woodster_> briancurtin: are you available?
20:41:29 <briancurtin> woodster_: yeah, what's up
20:42:12 <woodster_> arunkant: this wouldn't resolve multiple keys with the same name...those are still optional metadata about a secret.
20:42:45 <woodster_> briancurtin: do you know if the api-wg has tackled PUT vs POST semantics
20:42:48 <redrobot> arunkant yeah, it doesn't seem name uniqueness is a requirement for woodster_ 's use case
20:43:04 <woodster_> briancurtin: ...in terms of standardizing access across resources, across projects
20:43:34 <briancurtin> woodster_: i'm not a part of that so i don't know, everett toews (etoews in at least #openstack-sdks and #openstack-api) would know better
20:43:51 <woodster_> arunkant: a fail safe for clients that care that there is more than one secret would be for them to fail and notify of the issue perhaps
20:44:21 <woodster_> briancurtin: thanks, I can follow up with him then as part of my action time...does that make sense redrobot ?
20:44:47 <redrobot> woodster_ yep, sounds good
20:44:55 <elmiko> woodster_: looks like there is no official guideline yet
20:44:59 <redrobot> #action woodster_ to check with API-WG about POST vs PUT semantics.
20:45:30 <woodster_> wow, that all hogged up 3/4 of our meeting time :)
20:45:51 <woodster_> nothing else on the agenda though?
20:45:55 <redrobot> woodster_ good thing it was the only item on the agenda
20:46:04 <woodster_> redrobot: ha!
20:46:08 <elmiko> might we talk about castellan planning?
20:46:13 <redrobot> #topic Castellan
20:46:18 <redrobot> what's up elmiko ?
20:46:32 <elmiko> i know there are some nice changes planned for liberyt,
20:46:46 <elmiko> i'm curious about how best to sync up with those efforts
20:47:54 <redrobot> elmiko so the folks at John's Hopkins are driving the Castellan effort
20:48:05 <redrobot> elmiko so that'll be rellerreller (who just left) or kfarr
20:48:37 <redrobot> elmiko and a couple others whose nicks escape me.
20:48:38 <kfarr> elmiko rellerreller and I are working on an etherpad page, I can ping you when it's up :)
20:48:48 <elmiko> kfarr: that would be excellent!
20:49:18 <redrobot> elmiko if you'll be in Vancouver, then kfarr and I will be leading a Castellan fishbowl
20:49:26 <elmiko> kfarr, redrobot, the sahara team would like to integrate with castellan. so i just want to make sure that we can help if possible to get things in order =)
20:50:09 <kfarr> elmiko, that sounds great! Do you have a date you'd want to integrate by?
20:50:39 <elmiko> kfarr: i have this spec up now, #link https://review.openstack.org/#/c/179393/
20:50:55 <elmiko> and i'm working on a prototype now. switching from our old barbican approach.
20:51:14 <kfarr> elmiko, I'll take a look
20:51:27 <elmiko> rellerreller cautioned me that big changes were coming, so i'd like to help get the changes in if possible.
20:51:40 <elmiko> ultimately sahara would like to have this feature for the Liberty release
20:51:54 <elmiko> (but i was pusing for L-1 in our internal planning)
20:53:04 <elmiko> i realize this might not happen with the changes proposed for castellan
20:53:15 <kfarr> elmiko, ah, ok, will you be at the summit?
20:53:19 <elmiko> yes
20:54:53 <kfarr> elmiko it'll be much easier once we get that etherpad page up I think. We were looking at changes all the way through Liberty
20:55:14 <kfarr> so I'm not sure at the moment which changes will be affecting Sahara
20:56:11 <elmiko> kfarr, i think some of the abc changes, at least that's what rellerreller lead on about. i'll just keep poking =)
20:56:28 <kfarr> Sounds good elmiko, thanks!
20:57:30 <redrobot> alrighty y'all we're just about out of time
20:57:36 <redrobot> thanks for coming!
20:57:41 <redrobot> #endmeeting