Monday, 2017-10-23

*** noslzzp has joined #openstack-barbican00:37
*** hieulq has joined #openstack-barbican00:43
*** noslzzp has quit IRC01:29
*** noslzzp has joined #openstack-barbican01:30
*** liujiong has joined #openstack-barbican01:46
*** namnh has joined #openstack-barbican02:21
openstackgerritDave McCowan proposed openstack/barbican master: Fix Race Condition in get_or_create_project()
*** dave-mccowan has quit IRC03:05
*** hieulq has quit IRC03:23
*** hieulq has joined #openstack-barbican03:23
*** jaosorior has joined #openstack-barbican05:02
*** nickFro has joined #openstack-barbican06:29
*** nickFro has quit IRC06:36
*** nickFro has joined #openstack-barbican07:00
*** pcaruana has joined #openstack-barbican07:00
*** serlex has joined #openstack-barbican07:02
*** nickFro has quit IRC07:16
openstackgerritNam Nguyen Hoai proposed openstack/barbican master: Migrate to Zuul v3
openstackgerritMerged openstack/barbican master: Fix Race Condition in get_or_create_project()
openstackgerritJuan Antonio Osorio Robles proposed openstack/barbican master: Use oslo.messaging's filter_rule for keystone notificatoins
openstackgerritJuan Antonio Osorio Robles proposed openstack/barbican master: Use oslo.messaging's filter_rule for keystone notifications
*** liujiong has quit IRC09:58
*** liujiong has joined #openstack-barbican09:59
*** liujiong has quit IRC10:20
*** namnh has quit IRC10:22
*** pbourke has quit IRC10:37
*** pbourke has joined #openstack-barbican10:39
openstackgerritOpenStack Proposal Bot proposed openstack/barbican master: Updated from global requirements
openstackgerritOpenStack Proposal Bot proposed openstack/castellan master: Updated from global requirements
*** dave-mccowan has joined #openstack-barbican11:03
*** raildo has joined #openstack-barbican12:13
*** raildo has quit IRC12:13
*** raildo has joined #openstack-barbican12:20
*** pcaruana has quit IRC12:41
openstackgerritMurali Annamneni proposed openstack/barbican master: Use oslo.db options for database sync and upgrade
*** jaosorior has quit IRC14:08
*** namnh has joined #openstack-barbican14:18
*** peter-hamilton has joined #openstack-barbican14:44
*** jaosorior has joined #openstack-barbican14:57
*** agrebennikov has joined #openstack-barbican15:44
*** salmankhan has joined #openstack-barbican16:35
*** jaosorior has quit IRC16:35
*** jaosorior has joined #openstack-barbican16:36
*** salmankhan has quit IRC16:39
*** serlex has quit IRC16:58
*** rmascena has joined #openstack-barbican17:28
*** raildo has quit IRC17:30
*** abishop has joined #openstack-barbican17:35
abishopdave-mccowan: do you recall our earlier discussion (mostly on openstack-dev list) of the cinder/nova ConfKeyManager?17:47
dave-mccowanhi abishop.  yes17:51
abishopso I have another idea ;-)17:51
abishopI understand the concern that you and kfarr expressed about adding ConfKeyManager to Castellan17:51
abishopbut I will need a way to solve the user's problem of how to migrate from the ConfKeyManager to Barbican without disrupting service17:52
abishopI have a WPI that basically provides a read-only "migration" layer so that requests for the all-zeros key ID return the value that would be returned by the ConfKeyManager17:53
abishoprather than trying to describe, I thought I might toss it up for a WIP review and see if it addresses your concerns17:54
dave-mccowansure, that sounds good.17:55
abishopso I guess this is not much more than a heads-up, but I do want to keep searching for a workable solution17:55
abishopwill add kfarr, too (don't see her often on irc)17:56
abishopseparate topic, but do you know who is familiar with the Barbican policy stuff that controls the ability to create secrets?17:57
dave-mccowani'll take a look.  i certainly think your migration feature is super important, so i'm sure we'll find the appropriate solution.17:58
abishopcool, thx17:58
dave-mccowanabishop it's pretty well documented.  i'll find a link, unless you have a specific question.17:58
abishopthe 2nd topic is the cinder code I hope will be able to create a new barbican key for each entry in its volumes and snapshots tables17:59
abishopbut I don't think the "cinder" user is able to create barbican keys17:59
abishopfirst hack at some code failed due to auth error when trying to create a key order18:00
dave-mccowanmy recollection is that cinder passes through the user's credentials18:00
abishopsure, when doing so on behalf of a user request18:01
abishopthis would be cinder itself trying to create keys, as it attempts to replace old all-zeros confkeys with new Barbican key IDs18:01
*** namnh has quit IRC18:03
dave-mccowansorry, getting pulled away.  back in an hour18:04
abishopk, thx18:04
*** salmankhan has joined #openstack-barbican18:20
*** namnh has joined #openstack-barbican19:03
dave-mccowanabishop ping19:06
abishopdave-mccowan: hey19:07
dave-mccowanBarbican permissions are done by project.  The default method is role based (RBAC).  The four roles are Admin, Creator, Observer, Auditor.  Admin and Creator roles have permissions to create secrets for a project.19:08
*** namnh has quit IRC19:08
dave-mccowanSo, if a project owner wants to give the cinder user permission to write secrets for his project, he'd do a "openstack role add" to assign the "cinder" user the role of "creator" in project "foo".19:09
dave-mccowani think that covers your use case.19:09
abishophmm, interesting19:10
dave-mccowanAnother access method is via ACL, but that only works for giving read access to secrets.19:10
abishopcan an ACL also grant ability to delete a secret?19:10
dave-mccowanThe third method is to customize the policy.json file, which is not really the way things should be done.19:10
dave-mccowanACLs have only been implemented for read access so far.19:11
abishopyuck, that's an issue considering we're trying to find a way to essentially create barbican keys on behalf of someone else (the user associated with a volume)19:12
abishopkfarr showed a WIP script that created the barbican key as an admin, and then added an acl for the volume's owner19:13
abishopbut cinder wants to delete the key when the volume is deleted19:13
abishopand it sounds like ACL won't allow for that19:13
dave-mccowanabishop RBAC would allow for that.  if cinder is given the role of admin for a project, then cinder can create, read, and delete secrets for that project.  any user with a role of admin, creator, or observer in the project would also be able to read that secret.19:24
dave-mccowan(giving a service account (cinder) admin privileges for a project might give some heartburn, which is why we added ACLs.19:24
dave-mccowanif cinder needs create and delete privileges, and the user needs read privileges, then ACLS. work.  The secrets would be part of the Cinder project, and the user could be given read-only access via ACL.19:26
abishopdave-mccowan: but I don't think that fits the use case. volumes are deleted as requested by a user, and so the key deletion would happen in that context19:27
abishopso if we made the cinder user an admin, it could create barbican keys that are being migrated, but after that it will be the user who provides the context for volume (and key) deletion19:28
dave-mccowanabishop with that case, cinder would need be an admin in potentially several projects.  it would need to know which project to create the context for when storing new secrets.19:30
abishopI think it may have that info, but I'm not familiar with how an admin-like cinder user could create a context for another user19:31
dave-mccowanabishop what triggers the migration?  if it is an API call from a user, then the provided auth context could be used to create the migrated secrets.19:31
abishopI've read some that suggests it's possible, but I've never seen any details19:31
abishopwell, we were hoping to have a cinder thread search for keys to migrate and doing them all19:32
abishopso no user trigger19:32
dave-mccowanlol.  it's as if we're trying to find an exploit to hack through barbican's authentication methods.19:34
dave-mccowanit seems we need an action on the user to some extent.  if not to request the migration, then to give cinder permissions (assigned role) to do so on its behalf.19:35
abishopyeah, I fear we're trying to do something that's explicitly thwarted19:35
abishopeven the idea of giving cinder extra privs will probably give someone the cramps19:36
abishophow ugly would it be to enhance acl to allow user to delete a key that was created by the "cinder" user?19:37
dave-mccowanabishop pretty clean actually.  the api is in place, just need to fill in the details, which can be reasonably extrapolated from read ACL code.19:39
abishopthe more I think about it, though, the more I think that having cinder (as the "cinder" user) create the keys may be problemattic19:41
abishopkfarr's script would do it as the admin, so there's no need to enhance the cinder user's privs19:42
dave-mccowanabishop seems like the secrets would be owned by cinder's project, for which it would already be an admin.19:45
abishopdave-mccowan: I'm probably not coding the incantation correctly when I tried having the cinder user create a key19:46
dave-mccowanabishop (i assume cinder has a project...  i don't know how that works... if each service has their own project, or if the all share the "admin" project, not to be confused with "admin" role or "admin" username)19:47
abishopI'm afraid I don't have much experience with this stuff19:47
dave-mccowanabishop i can look to see what devstack does, but not sure if that will be universal.19:48
abishopdave-mccowan: well, it would be great if I can learn what devstack does as it might provide a pattern I could follow19:48
abishop(btw, it will be a while before I can post that WIP for handling all-zeros key ID. I roached the VM on which I prototyped the code)19:49
dave-mccowanabishop i have a tiny devstack up now, only with barbican and keystone running.  The "barbican" user has the "admin" role in the "service" project.19:52
dave-mccowani would guess that cinder runs with the same role.  i can check the next time i start up a bigger deployment.19:53
abishopdave-mccowan: I'll see what I can learn once I finish rebuilding my own devstack19:54
dave-mccowan"openstack role assignment list --user cinder" will tell us what we start with.19:55
abishopthx for tip; good stuff for me to learn19:56
*** salmankhan has quit IRC20:05
*** namnh has joined #openstack-barbican20:05
*** namnh has quit IRC20:09
*** salmankhan has joined #openstack-barbican20:15
*** peter-hamilton has quit IRC20:31
*** salmankhan has quit IRC20:44
*** rmascena has quit IRC20:50
*** dave-mccowan has quit IRC21:28
*** namnh has joined #openstack-barbican22:07
*** namnh has quit IRC22:11
*** dave-mccowan has joined #openstack-barbican22:49
*** ssathaye has quit IRC23:12
*** ssathaye has joined #openstack-barbican23:13
*** agrebennikov has quit IRC23:19
*** dave-mccowan has quit IRC23:27
*** namnh has joined #openstack-barbican23:56

Generated by 2.15.3 by Marius Gedminas - find it at!