20:00:32 <redrobot> #startmeeting barbican
20:00:33 <openstack> Meeting started Mon Jul  6 20:00:32 2015 UTC and is due to finish in 60 minutes.  The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:36 <openstack> The meeting name has been set to 'barbican'
20:00:46 <redrobot> #topic Roll Call
20:00:49 <dave-mccowan> o/
20:00:54 <kfarr> o/
20:00:58 <igueths> o/
20:01:00 <silos> o/
20:01:02 <elmiko> o/
20:01:17 <chellygel> ✧٩(•́⌄•́๑)
20:01:27 <rellerreller_> o/
20:02:26 <elmiko> very fancy chellygel
20:02:33 <chellygel> ;)
20:02:45 <redrobot> guessing other barbicaneers are still out for the 4th of july weekend
20:03:00 <redrobot> no matter, we'll have an awesome meeting regardless
20:03:15 <redrobot> as usual the agenda can be found here:
20:03:16 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican
20:03:25 <redrobot> #topic Action Items from previous meeting
20:03:33 <redrobot> #link http://eavesdrop.openstack.org/meetings/barbican/2015/barbican.2015-06-29-20.00.html
20:03:38 <redrobot> jaosorior are you around?
20:04:12 <redrobot> I'll take that as a no.
20:04:15 <redrobot> #action jaosorior to backport the DogTag gate fixes into stable/kilo
20:04:21 <redrobot> ok moving on to the agenda for today
20:04:55 <redrobot> #topic Update on Quota Support blueprint
20:05:03 <redrobot> dave-mccowan do you have an update for us?
20:05:06 <dave-mccowan> I've made good progress on the quotas blueprint.  To hopefully make reviewing easier, I'm breaking it into three parts: 1) config and controller, 2) repos, and 3) enforcement.  I'll include relevant unit test and functional tests with each part.  I submitted the CR for #1 today. https://review.openstack.org/198764  Let me know if there is anything I can do to help reviewers.  Perhaps wishful thinking, but it would be great if this
20:05:06 <dave-mccowan> could merge, before i start on #2.
20:05:37 <hockeynut> o/
20:05:42 <hockeynut> (late, I know)
20:05:57 <redrobot> #info dave-mccowan will be splitting the quota bp work into several patches
20:06:01 <redrobot> #link https://review.openstack.org/#/c/198764/
20:06:11 <redrobot> sounds great dave-mccowan !
20:06:24 <redrobot> any questions/comments about this blueprint?
20:06:29 <dave-mccowan> can we get a couple volunteers who will be doing the reviewing?
20:06:43 <hockeynut> (meekly raises hand in the air)
20:07:04 <hockeynut> 6 more LOC and we would have the CR from hell
20:07:25 <dave-mccowan> * makes note for next patch set
20:07:28 <rellerreller_> haha
20:07:54 <redrobot> I'll try to get a review in as well.
20:08:17 <redrobot> I'm sure woodster will be interested also
20:08:41 <redrobot> ok, moving on
20:08:52 <redrobot> #topic ACL client implementation
20:09:03 <redrobot> chellygel this topic is yours, yes?
20:09:06 <chellygel> Yes!
20:09:16 <chellygel> thanks redrobot (/me grabs the conch shell)
20:09:31 <chellygel> So, one of the tasks we want to implement is putting per-secret ACL into the barbican client
20:09:52 <chellygel> i have a blueprint here in launch pad: https://blueprints.launchpad.net/python-barbicanclient/+spec/per-secret-acl
20:10:07 <chellygel> i want to ask the community if they feel this approach to usage makes sense... as an example:
20:10:12 <chellygel> barbican acl "[secret-ref-here]" user list
20:10:23 <chellygel> would provide a list of user ids associated w/ the acl for the specific secret
20:10:53 <chellygel> this very basic vanilla implementation would have user add, user delete, and user list... does anyone have any thoughts, concerns, or questions about this implementation?
20:10:55 <redrobot> #link https://blueprints.launchpad.net/python-barbicanclient/+spec/per-secret-acl
20:11:13 <redrobot> chellygel I think the subcommand needs to be grouped together, so
20:11:24 <redrobot> barbican acl user list [secret-ref]
20:11:52 <rellerreller_> +1
20:11:52 <redrobot> but then again, I'm no cliff expert
20:12:01 <chellygel> makes sense to me :)
20:12:15 <chellygel> if no one else wishes to speak, i'm finished and will begin the implementation in this manner
20:12:21 <rellerreller_> It's not just cliff but what is intuitive to user as well.
20:12:34 <redrobot> barbican acl user delete [secret-ref] [user-ref]
20:12:49 <redrobot> barbican acl user add [secret-ref] [user-ref]
20:13:01 <redrobot> ^^ looks a little odd, but I think that would be the cliff ordering?
20:13:52 <redrobot> hmm....
20:14:05 <redrobot> barbican acl add --user [user-id] ?
20:14:11 <redrobot> barbican acl list
20:14:18 <redrobot> barbican acl delete --user [user-id] ?
20:14:22 <chellygel> still need to pass that ref though, right?
20:14:34 <chellygel> barbican acl add --ref [ref] --user [user]
20:14:35 <hockeynut> --secret-ref [secret=ref]
20:15:29 <chellygel> anyone else? thoughts?
20:15:44 <rellerreller_> If they are required do we need -- options?
20:16:12 <rellerreller_> It seems like user add would be like
20:16:13 <rellerreller_> barbican acl user add [secret-ref] [user-ref]
20:16:41 <rellerreller_> The --user makes it seem like not required, but it should be. I think.
20:16:44 <chellygel> i can't think of any other thing that would matter for an action w/ acls
20:17:09 <redrobot> there is a spec out for group acls as well
20:17:11 <redrobot> so we could have
20:17:22 <redrobot> barbican acl add --user [user-id] [secret-id]
20:17:23 <redrobot> and
20:17:35 <redrobot> barbican acl add --group [group-id] [secret-id]
20:18:24 <chellygel> well it could be argued that... barbican acl [user/group] add [secret-ref] [group/user-id] wouild work too
20:18:41 <redrobot> chellygel true...
20:18:42 <chellygel> im not sure the difference though, so i dont have an opinion on either way
20:18:54 <redrobot> chellygel would be one cliff subcommand vs two cliff sub-commands
20:19:08 <redrobot> chellygel functionally it wouldn't matter, I guess.
20:20:06 <rellerreller_> I vote for barbican acl user add [secret-ref] [user-ref], but I don't really care much one way or the other.
20:20:36 <hockeynut> as long as secret-ref and user-ref are keyword args I'm good with that
20:21:03 <kfox1111> -s secret-ref -u user-ref ?
20:21:08 <kfox1111> then you can reorder them.
20:21:12 <silos> -- makes sense to me. barbican acl add --user [userid] --ref [refid] and barbican acl add --ref [refid] --user [userid] are the same that way. Less likely to have mistakes that way IMO
20:21:33 <rellerreller_> Actually now I take it back. Maybe I do like barbican acl add [--user || --group <id>] <secret-ref>
20:22:01 <kfox1111> what about secret vs container acl's?
20:22:09 <kfox1111> -c for container ref, -s for secret ref.
20:22:19 <redrobot> I'm starting to agree on flags as well
20:22:39 <redrobot> kfox1111 yep, containers would be similar... I'm guessing --secret-ref and --container-ref to be consistent with the rest of the CLI
20:22:40 <kfox1111> acl add [--user || --group <id>] [--container || --secret <ref>]
20:23:48 <chellygel> okay, well lets get some votes in here so we can move on, yeah?
20:24:00 <chellygel> barbican acl add --user [id] --secret [ref]
20:24:06 <dave-mccowan> is two word commands, like "user add", typical for barbican client?   nova, for example, uses one word commands, e.g.:  "flavor-add", "flavor-list", "flavor-delete"
20:24:34 <redrobot> chellygel seems like we're all agreeing on using flags for secret/container refs and for user/group
20:24:49 <redrobot> dave-mccowan IIRC cliff can handle either
20:25:10 <dave-mccowan> +1 for flags
20:25:35 <kfox1111> most openstack seperate clients use '-' instead of ' '. the unified openstack client uses spaces for everything.
20:25:40 <kfox1111> +1 for flags.
20:26:17 <hockeynut> +1 for flags
20:26:25 <redrobot> seems there's consensus
20:26:36 <redrobot> chellygel any other questions about the ACL client implementation?
20:26:49 <chellygel> im good :)
20:27:01 <redrobot> ok
20:27:12 <redrobot> I was hoping to bikeshed on this until woodster had a chance to jump on
20:27:34 <redrobot> #topic Additional role for ACL
20:27:39 * kfox1111 chuckles
20:27:49 <kfox1111> its got to be green! :)
20:28:05 <elmiko> lol
20:28:09 <redrobot> kfox1111 lol
20:28:20 <chellygel> Green!! no! D: needs to be color blind friendly!
20:28:23 <redrobot> seems woodster isn't going to make it.
20:28:36 <redrobot> but I can talk about this topic anyway.
20:28:46 <redrobot> the idea here was to add one more role to our policy
20:29:04 <redrobot> potentially called "acl-user" or something similar we can bikeshed on
20:29:37 <kfox1111> whats it do?
20:29:59 <redrobot> so, for ACL access, the token provided would have to have the "acl-user" role scoped to the project that owns the secret.
20:30:12 <redrobot> in addition to being on the ACL
20:30:23 <redrobot> the benefit is that you can remove the role to lock out someone from all ACL'ed secrets.
20:30:33 <redrobot> instead of having to iterate through all possible secrets in the project
20:30:53 <redrobot> also I should point out that this is strictly a policy change.
20:31:07 <redrobot> and as such it would only affect people who choose to use the default policy
20:31:19 <redrobot> someone could still write a policy to ignore that role altogether.
20:31:49 <dave-mccowan> i envision the rule in policy.json would be: rule:secret_project_match and rule:secret_acl_read    in this case, it doesn't matter what we call the new role (member, user, acl-user, _foo_).  as long as the token is scoped for the project and the user is on the acl-read list, it's all good.
20:31:59 <kfox1111> as in the user would have to have the acl-user role on the project in order for the acl itself to take affect,
20:32:12 <kfox1111> or would have to have acl-user to be able to look at the acl itself?
20:32:41 <redrobot> kfox1111 yeah... though we could be a little looser, and just have the "acl-read" role in a scoped token... not necessarily scoped to the project that owns the secret...
20:33:28 <kfox1111> I'm a little worried the one way is too specific for things like the instance users to work,
20:33:28 <redrobot> kfox1111 someone using ACL would need both the "acl-read" role in their token (not sure about what project scope) as well as have the user-id listed in the ACL
20:33:37 <kfox1111> and the other is loose enough it might not be all the valuable.
20:35:02 <redrobot> kfox1111 good points... I wish woodster would be here to argue more for this change
20:35:12 <kfox1111> is there a spec?
20:36:03 <redrobot> I don't think so... we've had a couple of discussions about it, but it hasn't been put into a spec
20:36:24 <redrobot> probably would be good to do if woodster really wants this change.
20:36:34 <kfox1111> might be good to do a spec then, since these types of things can be discussed in the spec.
20:36:39 <kfox1111> yeah.
20:36:56 <kfox1111> it still might be a good idea, just may need to be thought out carefully.
20:37:31 <redrobot> #action redrobot to ping woodster about writing a spec for the additional acl role
20:37:42 <kfox1111> thx.
20:38:07 <redrobot> That's all I have on the agenda for today
20:38:11 <redrobot> #topic Open Discussion
20:38:36 <redrobot> any questions/comments/reviews that need to be brought up now?
20:38:57 <kfarr> Has anyone submitted any proposals for Tokyo?
20:39:18 <redrobot> kfarr not yet... we have a meeting sometime this week to brainstorm possible topics
20:39:21 <kfox1111> any more reviewers for the Container ACL and Fetch API spec? https://review.openstack.org/#/c/190404/
20:39:39 <kfarr> ok just checking!
20:39:55 <dave-mccowan> i still have the same two open reviews as last week: https://review.openstack.org/181291  and https://review.openstack.org/171023
20:40:14 <redrobot> kfarr how about you?  have you submitted anything?
20:40:52 <silos> I uploaded a new patch last week on a spec: https://review.openstack.org/#/c/194298/3
20:42:48 <kfarr> No, we were trying to come up with topics last week
20:43:26 <redrobot> I think it would be good to do a "How to deploy Barbican" talk... but we're still figuring it out >_<
20:43:43 <kfarr> :D
20:43:55 <elmiko> redrobot: +1
20:44:13 <kfarr> Oh, by the way, the Barbican wrapper for Castellan only needs a workflow! https://review.openstack.org/#/c/171918/
20:44:20 <elmiko> ooh \o/
20:44:51 <redrobot> kfarr excellent!
20:45:40 <rellerreller_> A security overview talk would be good. We could highlight what good security things are already in OpenStack and what is missing.
20:46:03 <elmiko> that would be a nice talk too
20:46:43 <kfox1111> it might make some folks cry though. :/
20:46:51 <kfox1111> I want to every time  Isee passwords passed through userdata. :/
20:46:53 <redrobot> rellerreller_ +1 ... sounds kindof like dave-mccowan 's talk in Vancouver.  It was a really good overview of security topics.
20:46:57 <elmiko> yea, maybe better to say "how you can improve security using barbican" ;)
20:47:13 <kfox1111> and instance users are not going to land in liberty. :_(
20:47:37 <rellerreller_> I missed dave-mccowan 's talk :(
20:47:42 <redrobot> kfox1111 bummer.
20:47:52 <elmiko> rellerreller_: it was nice
20:48:06 <kfox1111> nova's getting very slow at reviews. :/
20:48:12 <redrobot> rellerreller_ https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/securing-your-openstack-cloud
20:48:38 <dave-mccowan> thanks.  the video's on the openstack website.  rob clark also usually does an security overview talk.
20:49:03 <kfarr> rellerreller_, dave-mccowan's was a good one!
20:53:44 <redrobot> Alrighty y'all, I think that about does it for this meeting.
20:53:53 <redrobot> thanks everyone for coming!
20:53:57 <redrobot> #endmeeting