20:01:18 <redrobot> #startmeeting barbican 20:01:19 <openstack> Meeting started Mon Aug 17 20:01:18 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:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:22 <openstack> The meeting name has been set to 'barbican' 20:01:37 <elmiko> heyo/ 20:01:41 <chellygel> ( ีเจ ี)โ 20:01:44 <hockeynut> o/ 20:01:47 <apmelton> o/ 20:01:49 <jvrbanac> o/ 20:01:50 <peter-hamilton> o/ 20:01:57 <rellerreller> o/ 20:01:57 <silos1> o/ 20:02:02 <arunkant> o/ 20:02:08 <elmiko> very nice chellygel 20:02:08 <pkazmir> o/ 20:02:13 <kfarr> o/ 20:02:24 <dave-mccowan> \o/ 20:02:29 <chellygel> elmiko, perhaps is hould put that on my resume, no? japanese emoticon usage. 20:02:39 <elmiko> chellygel++ 20:02:53 <elmiko> you have demonstrated a clear proficiency for it ;) 20:03:00 <igueths> o/ 20:03:21 <redrobot> #topic Action Items from last meeting 20:03:23 <rm_work> o/ 20:03:36 <redrobot> ... and I'm just going to kick the can down the road on these 20:03:43 <elmiko> hehe, fair 20:03:49 <redrobot> I am actively looking at the stable/kilo gate failures though 20:03:58 <redrobot> #action redrobot to finish prioritizing liberty-2 bugs, and also check them for kilo status 20:04:08 <redrobot> #action redrobot to fix the stable/kilo gate failures during mid-cycle (in-progress) 20:04:15 <redrobot> #action redrobot and alee to backport the DogTag gate fixes into stable/kilo after redrobot fixes the gate 20:04:30 <redrobot> also 20:04:37 <woodster_> o/ 20:04:41 <redrobot> #action redrobot to submit a patch for a new python-barbicanclient release 20:04:54 <redrobot> client releases are done via Gerrit now 20:05:07 <redrobot> kfarr I'll add you to the review... I know you're waiting on that release 20:05:26 <kfarr> Thanks redrobot! I'm curious to see what the process is, I couldn't find much online 20:05:50 <redrobot> kfarr there was a message in the dev ML about it... don't have the link handy right now, but I can get it to you after the meeting. 20:06:18 <redrobot> ok, moving on to the agenda for today 20:06:21 <redrobot> which can be found here: 20:06:22 <redrobot> #link redrobot and alee to backport the DogTag gate fixes into stable/kilo after redrobot fixes the gate 20:06:29 <redrobot> derp 20:06:37 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican 20:06:55 <redrobot> #topic Adding certificate manager namespace to Castellan 20:07:00 <rm_work> abandoned 20:07:04 <rm_work> topic over 20:07:07 <rm_work> thanks for playing :P 20:07:39 <rm_work> (shortest Castellan discussion ever to take place) 20:07:42 <elmiko> rm_work: did this just end up not making sense, or too much resistance, or? 20:07:46 <woodster_> This rivaled content-types for bike shed supremacy! 20:07:50 <redrobot> #link https://review.openstack.org/#/c/156623/ 20:08:03 <rm_work> elmiko: redrobot found the gaping flaw i missed 20:08:24 <elmiko> redrobot, rm_work, ack thanks /me reads 20:08:40 <rm_work> I'll just say I was too distracted by the random invalid arguments everyone was throwing at me :P 20:08:54 <elmiko> haha, nice 20:09:00 <rm_work> but yeah, essentially it's impossible to expose any HSM without ... Barbican or a barbican-clone 20:09:21 <rm_work> because by definition, "a service to expose a HSM" would ... BE a barbican clone 20:09:30 <elmiko> right, makes sense 20:09:30 <rm_work> and if the issue is that people can't use barbican... 20:09:32 <rm_work> we're toast 20:09:44 <rm_work> yep 20:09:56 <rm_work> donezo 20:09:58 <rm_work> finished 20:10:10 <elmiko> thanks for indulging my curiosity =) 20:10:15 <rm_work> heh 20:10:31 <redrobot> #agreed cert manager is out of scope for Castellan 20:10:47 <rm_work> redrobot: you pretty much killed CertManager *everywhere* 20:11:00 <rm_work> I'll probably go rip it out of LBaaS now >_> 20:11:03 <redrobot> yeah... the alternative is to use Barbican directly 20:11:07 <rm_work> yep 20:11:26 <rm_work> or Castellan and take individual refs, like rellerreller was saying 20:11:46 <rm_work> which is shittier from a user perspective but it'd be the only way to be generic enough to support other use-cases 20:12:14 <rm_work> and even then, the same problem exists, which is that a user can't get data into any other service easily 20:12:39 <rm_work> which makes me wonder about Castellan in general -- i guess it's ONLY useful for M2M stuff 20:12:49 <redrobot> m2m? 20:12:53 <rm_work> anything involving an end-user and castellan is sunk 20:13:01 <rm_work> Machine to Machine 20:13:20 <redrobot> ah... yeah... or tiny clouds where users are allowed to use the key manager device 20:13:21 <rellerreller> Why can't end user use Castellan? 20:13:40 <rm_work> rellerreller: because no one in their right mind exposes an HSM directly 20:13:45 * peter-hamilton settles in 20:13:51 <rm_work> rellerreller: remember I tend to think in the "public cloud" mindset 20:13:58 <rellerreller> What about bring your own key use cases? 20:14:18 <rm_work> rellerreller: how do I store my key using Castellan unless I have credentials for the HSM? 20:14:31 <rm_work> and what cloud provider is going to give users direct credentials for an HSM 20:14:42 <rm_work> that's the point of Barbican <_< 20:14:45 <rellerreller> If you own the HSM then you would have credentials for it. 20:15:01 <rm_work> so end-users, in order to use your cloud, would have to own and operate their own HSM 20:15:12 <redrobot> rellerreller yeah.... a small cloud deployment where users have credentials for the HSM would still work. 20:15:13 <rellerreller> I can store keys with my credentials and let Neutron or whatever have read access to certain keys. 20:15:15 <rm_work> and they'd have to open up THEIR HSM to your cloud services 20:15:39 <rm_work> yeah that's not a reasonable use-case for public cloud at scale 20:15:43 <rm_work> I don't think 20:15:44 <rellerreller> Yes, that is the bring your own key model. 20:16:07 <rellerreller> silos or someone else brought this up. 20:16:19 <rm_work> i don't think any major cloud provider would ever do that 20:16:43 <rm_work> could be wrong i guess? but not a use-case we're planning for 20:16:51 <redrobot> yeah... it's interesting that Castellan gives you a non-barbican choice, but there's definitely caveats that come with non-barbican solutions. 20:17:39 <rm_work> and we're way off topic 20:17:53 <redrobot> yup 20:17:55 <redrobot> moving on 20:18:16 <redrobot> thanks for playing rm_work ... your name will always be remembered in Castellan discussions ;) 20:18:32 <redrobot> silos around? 20:18:38 <silos1> \o/ 20:18:55 <redrobot> #topic Federated Barbican 20:19:00 <silos1> I created a wiki for fed barbican 20:19:03 <silos1> https://wiki.openstack.org/wiki/Barbican/Discussion-Federated-Barbican 20:19:13 <silos1> The picture is so wrong. I need to change it ASAP. 20:19:37 <redrobot> #link https://wiki.openstack.org/wiki/Barbican/Discussion-Federated-Barbican 20:19:39 <redrobot> silos1 nice! 20:19:58 <rellerreller> http://googlecloudplatform.blogspot.com/2015/07/Bring-Your-Own-Encryption-Keys-to-Google-Cloud-Platform.html 20:20:02 <redrobot> I'll ping Joe Savak on our end to pitch into that... will definitely come in handy if our federation talk gets picked up. 20:20:16 <silos1> thanks. 20:20:31 <silos1> I was hoping we could schedule a meeting sometime to talk and get his help with this. 20:21:25 <redrobot> silos1 I have a meeting with Joe on Sept 2 to talk about Federation. I should have more info after that. 20:21:36 <silos1> redrobot: awesome! 20:21:42 <pkazmir> (Yeah, Joe's on vacay this week) 20:21:46 <pkazmir> (slacker) 20:21:51 <silos1> haha 20:22:03 <silos1> anyone is free to comment on the wiki. The more the better. 20:23:04 <silos1> That's pretty much it for me. Just wanted to put the wiki out there. 20:23:13 <redrobot> silos1 ok sounds good 20:23:16 <redrobot> moving on 20:23:37 <redrobot> #topic Defect/issue template 20:23:44 <woodster_> silos1: API call examples would be nice to add to that wiki 20:23:58 <redrobot> hockeynut did you add this topic? 20:24:04 * silos1 writes down to add API calls 20:24:30 <hockeynut> redrobot yessir 20:24:39 <redrobot> hockeynut go ahead! 20:25:14 <hockeynut> would like to get more detail, and useful info into our launchpad issues. Suggesting this template as a way to get there: https://etherpad.openstack.org/p/barbican-bug-report-template 20:25:28 <redrobot> #link https://etherpad.openstack.org/p/barbican-bug-report-template 20:25:48 <hockeynut> if there are other datum that folks would like to see added then certainly lets add it. 20:26:17 <pkazmir> +1 looks great 20:26:34 <pkazmir> Like how you were clear on priority and severity. 20:26:55 <hockeynut> this helps in the immediate time if the fixer <> the reporter and also helps us memorialize information about a bug so it makes sense when "future us" looks at it 20:27:31 <hockeynut> pkazmir I unabashadly stole^H^H^H^H^H borrowed it 20:27:34 <redrobot> not sure that we want to track status outside of the launchpad provided ones... 20:27:41 <woodster_> I think reporter is handled by LP automatically. 20:27:46 <pkazmir> heh 20:28:09 <redrobot> I do agree we need to get better at triaging bugs 20:28:21 <woodster_> redrobot: +1 So 'Importance' could map to your severity 20:28:31 <hockeynut> dont want to duplicate info, so certainly those don't need to be in the defect BODY. But they do need to be considered when writing up a bug. 20:28:35 <redrobot> eg, the OpenStack way is to move bugs from New->Confirmed->Triaged and encouraging people to pick up Triaged bugs. 20:28:57 <hockeynut> is triaging a formal activity? 20:29:20 <redrobot> hockeynut it should be... 20:29:29 <redrobot> but historacally we've been really bad at it 20:29:42 <dave-mccowan> is the barbican policy for changing bug state that the PTL does that, any core, or any interested party? 20:29:48 <woodster_> FWIW: https://github.com/cloudkeep/barbican/wiki/Testing-Process 20:30:05 <woodster_> ...see the 'workflow for defects' section 20:30:12 <elmiko> hockeynut: sahara team has been triaging all day, so i'd say yes =) 20:30:19 <jvrbanac> woodster_, uh oh. not the old wiki 20:30:22 <jvrbanac> ;) 20:30:26 <redrobot> dave-mccowan permissions are granted in launchpad specific fields... I would say anyone who is not the reporter should be able to move bugs to "Confirmed" 20:30:34 <woodster_> jvrbanac: it's still alive!!!! 20:30:42 <redrobot> launchpad specific groups even... 20:31:01 <redrobot> not sure how the permissions actually break down though... 20:31:03 <woodster_> jvrbanac: Barbican's genesis is that wiki 20:31:11 <hockeynut> sounds like we need to add some more rigor beyond just some standardized text in the bug body 20:31:38 * redrobot didn't know we had a cloudkeep page for that 20:31:40 <woodster_> hockeynut: that's for sure. Is there sphinx info on that already? 20:32:30 <hockeynut> redrobot I'd be more than happy to take a look at the process, docs, etc and give some recommendations 20:32:39 <redrobot> hockeynut sounds good to me! 20:32:53 <redrobot> #action hockeynut to review bug tracking policies and give feedback 20:33:45 <redrobot> ok, moving on to the next topic 20:33:57 <redrobot> #topic super-user rule in policy.json 20:34:01 <redrobot> dave-mccowan go ahead 20:34:16 <dave-mccowan> working on the quotas blueprint, the need for a new permissions level became apparent. 20:34:22 <redrobot> #link https://review.openstack.org/#/c/213570/ 20:34:36 <dave-mccowan> now we have 3 roles: admin, creator, observer, audit... each role is scope to it's own project 20:35:04 <dave-mccowan> to set a quotas, you really want a cloud-admin (or service-admin, or super-admin) not just a project-admin to change those. 20:35:33 <dave-mccowan> in the review linked above, i proposed one way to do this with the default policy file (no code change to barbican) 20:35:40 <pkazmir> That makes sense, I would call it a service-admin. 20:35:53 <redrobot> dave-mccowan yep... I do believe this is the first cloud-admin type of operation 20:35:57 <redrobot> pkazmir +1 service-admin 20:36:09 <dave-mccowan> is there anyone here who is wise in the ways of oslo policy that can point us to the "right" way to do this? 20:36:46 <hockeynut> and do other projects have a similiar concept? 20:36:50 <redrobot> dave-mccowan as far as DevStack is concerned... you'll want to add a new user, and then grant the "admin" role on the "service" tenant 20:37:26 <redrobot> the oslo.policy piece would have to check that the admin role is present AND that the tenant the toke is scoped to is the "service" tenant. 20:37:29 <arunkant> dave-mccowan: I think you just need to assign that role to a pre-defined admin 'project' e.g. 'service' project. 20:37:31 <dave-mccowan> i found this in an example keystone V3 policy file: "cloud_admin": "rule:admin_required and domain_id:admin_domain_id", 20:37:55 <dave-mccowan> i don't see a standard (oslo) way to get the service tenant id into barbican 20:37:58 <woodster_> yeah, I noticed that arunkant pointed out that this role should be associated to a special project to quality as a valid cloud admin user 20:38:18 <woodster_> arunkant: yep! 20:39:09 <arunkant> dave-mccowan: And keystone middleware provides header for project name..so it can be checked in policy 20:39:14 <redrobot> dave-mccowan http://git.openstack.org/cgit/openstack/barbican/tree/bin/keystone_data.sh#n64 should do it 20:39:17 <elmiko> a general observation about barbican policy files, we should probably prefix all these policies with "key-management:" 20:39:28 <elmiko> to allow for aggregated policy files 20:39:33 <redrobot> elmiko s/key-management/key-manager/ and I agree 20:39:50 <elmiko> yea, key-manager, whatevet the official service type is 20:39:53 <woodster_> dave-mccowan: so managing domains would be required if using that rule it seems...does keystone v2 support domains though? 20:40:27 <redrobot> dave-mccowan service tenant ID would likely be a config option 20:41:26 <redrobot> woodster_ correct, v2 keystone does not have a concept of domain. All entities created via v2 api belong to the "default" domain in v3. This is how keystone is able to run v2 and v3 in parallel. 20:41:30 <arunkant> woodster_, so far I have seen service policy configuration tend to avoid domain information. Uses project boundary to enforce rules. 20:41:38 <elmiko> dave-mccowan: might be worth pinging ayoung on the keystone team, he had some great suggestions about implementing policy features that can bridge the gap into the policy authorization code. 20:41:55 <dave-mccowan> redrobot... that seems kind of icky. putting the UUID into a config file? tricky to build the gate job to that on the fly too. 20:42:38 <redrobot> dave-mccowan service tenant name in devstack is known to be "service" http://git.openstack.org/cgit/openstack/barbican/tree/bin/keystone_data.sh#n44 20:43:12 <dave-mccowan> redrobot can we key on tenant name only? everything else goes by the tenant id. 20:43:23 <elmiko> i *think* there is a way to specify a function in the policy file that maps to a function in the acl code, that would allow you to control it programatically without the need for embedding special values in the config 20:43:37 <arunkant> dave-mccowan: You can use 'service' project name instead of ID and populate that as service boostrap data 20:44:00 <dave-mccowan> i'm not sure if tenant name is guaranteed to be unique. anyone know? 20:44:20 <redrobot> dave-mccowan it is in v2. only guaranteed unique within a domain in v3 20:45:27 <arunkant> yes, will need both service and domain name in that case. 20:45:36 <arunkant> s/service/project 20:46:01 <redrobot> would be worth pinging the keystone folks about this 20:46:07 <elmiko> +1 20:46:23 <elmiko> also, check out ayoung's talk from vancouver about dynamic policy 20:46:32 <redrobot> elmiko agreed 20:47:02 <redrobot> dynamic policy would include namespaced roles... which I looked into briefly 20:47:03 <redrobot> https://review.openstack.org/#/c/187638/ 20:47:05 <dave-mccowan> redrobot +1 i'd really like to see another project that has done this to follow as an example. no new wheel needed here. 20:47:39 <redrobot> cool, sounds like we can move on to the next topic? 20:47:48 <elmiko> redrobot: i did the namespace conversion to sahara's policy, it went pretty smoothly 20:48:20 <redrobot> elmiko I'll have to look into that and see if I can fix my patch 20:48:29 <elmiko> i'll make a comment too 20:48:53 <dave-mccowan> ok to move on 20:48:59 <redrobot> #topic quotas blueprint update 20:49:03 <redrobot> another one for dave-mccowan 20:49:07 <elmiko> hehe 20:49:38 <dave-mccowan> i wanted to point out 3 deviations from the current spec as approved. 20:50:13 <dave-mccowan> 1) the super-admin role, we just discussed. 2) the spec calls for transport-keys to be managed under a quota, but it turns out the are not project resources. 20:50:34 <dave-mccowan> the are per plugin, not per project. so i will delete them from the spec/code/doc etc. 20:50:59 <dave-mccowan> (btw... maybe their API should also be controlled by rule:service-admin) 20:51:31 <dave-mccowan> and 3) a nit: the details of the paging for list of project-quotas was missing from the spec. 20:51:41 <redrobot> Anyone is allowed to ask for the Transport Key 20:51:49 <redrobot> haven't looked into the api recently 20:51:56 <dave-mccowan> i'll update the spec with these 3 points. i assume all of these are ok? 20:51:57 <redrobot> but any add/edit actions need to be service-admin calls 20:52:26 <redrobot> all 3 seem reasonable to me 20:53:03 <woodster_> agreed 20:53:33 <dave-mccowan> and finally, i'd like to ask for reviews on the CRs I have out on the blueprint. pretty please. :-) 20:53:33 <redrobot> awesome... sounds like we're done for today 20:53:47 <redrobot> with a couple of minutes to spare 20:54:07 <dave-mccowan> i'll be stuck soon, if these don't start landing. there are four out there. we can split them up if we need to. 20:54:23 <redrobot> dave-mccowan I'll look at them ... soon ... :) 20:55:03 <arunkant> will appreciate if people can comment on barbican client ACL changes as well. 20:55:16 <redrobot> #topic Review Requests 20:55:30 <redrobot> ok, y'all got 5 minutes to spam the channel with CR links :) 20:56:02 <dave-mccowan> #link https://review.openstack.org/205894 20:56:24 <dave-mccowan> #link https://review.openstack.org/212876 20:56:38 <dave-mccowan> #link https://review.openstack.org/212967 20:56:46 <arunkant> As i said above, 3 linked changes for ACL on barbican client side. (1 # link https://review.openstack.org/#/c/206699/ ) 20:56:56 * hockeynut is hoping that trojan to disable CTRL-V is working 20:57:01 <dave-mccowan> the first one is first priority, but is larger. the second two are more bite-sized. 20:59:24 <redrobot> alrighty y'all, thanks for coming! 20:59:26 <redrobot> #endmeeting