| *** rm_work is now known as rm_work|away | 00:07 | |
| *** zz_dimtruck is now known as dimtruck | 00:11 | |
| *** yuanying_ has joined #openstack-barbican | 00:36 | |
| *** yuanying has quit IRC | 00:40 | |
| *** alee has quit IRC | 00:40 | |
| *** yuanying_ has quit IRC | 00:42 | |
| *** yuanying has joined #openstack-barbican | 00:45 | |
| *** yuanying has quit IRC | 00:52 | |
| *** mikeymeitbual has joined #openstack-barbican | 01:08 | |
| *** yuanying has joined #openstack-barbican | 01:12 | |
| *** openstack has joined #openstack-barbican | 01:23 | |
| *** openstackgerrit has joined #openstack-barbican | 01:23 | |
| *** yuanying has joined #openstack-barbican | 01:23 | |
| *** alee has joined #openstack-barbican | 01:59 | |
| *** dave-mccowan has joined #openstack-barbican | 02:05 | |
| *** diazjf has joined #openstack-barbican | 02:28 | |
| *** diazjf has left #openstack-barbican | 02:50 | |
| *** kfarr1 has joined #openstack-barbican | 02:56 | |
| *** dave-mccowan has quit IRC | 02:56 | |
| *** xaeth_afk is now known as xaeth | 02:57 | |
| *** crc32 has quit IRC | 03:10 | |
| *** yuanying_ has joined #openstack-barbican | 03:16 | |
| *** yuanying_ has quit IRC | 03:18 | |
| *** yuanying has quit IRC | 03:18 | |
| *** yuanying_ has joined #openstack-barbican | 03:18 | |
| openstackgerrit | Merged openstack/python-barbicanclient: Added secret type command line option https://review.openstack.org/201767 | 03:28 |
|---|---|---|
| *** yuanying_ has quit IRC | 03:30 | |
| *** yuanying has joined #openstack-barbican | 03:32 | |
| *** yuanying has quit IRC | 03:37 | |
| *** yuanying has joined #openstack-barbican | 03:38 | |
| *** lisaclark has quit IRC | 03:45 | |
| *** briancurtin has quit IRC | 03:45 | |
| *** jraim has quit IRC | 03:45 | |
| *** woodster_ has quit IRC | 03:45 | |
| *** codekobe has quit IRC | 03:46 | |
| *** lisaclark_ has quit IRC | 03:47 | |
| *** lisaclark has joined #openstack-barbican | 03:49 | |
| *** rm_work|away has quit IRC | 03:52 | |
| *** codekobe has joined #openstack-barbican | 03:55 | |
| *** briancurtin has joined #openstack-barbican | 03:56 | |
| *** jraim has joined #openstack-barbican | 03:56 | |
| *** yuanying has quit IRC | 04:00 | |
| *** yuanying has joined #openstack-barbican | 04:01 | |
| *** yuanying has quit IRC | 04:02 | |
| *** kfarr1 has quit IRC | 04:06 | |
| *** yuanying has joined #openstack-barbican | 04:07 | |
| *** alee has quit IRC | 04:09 | |
| *** lisaclark_ has joined #openstack-barbican | 04:18 | |
| *** woodster_ has joined #openstack-barbican | 04:32 | |
| *** rm_work has joined #openstack-barbican | 04:40 | |
| *** rm_work is now known as rm_work|away | 05:23 | |
| openstackgerrit | Merged openstack/barbican: Added opaque data support to KMIP secret store https://review.openstack.org/200692 | 05:24 |
| *** alee has joined #openstack-barbican | 05:29 | |
| *** rm_work|away is now known as rm_work | 05:56 | |
| *** rm_work is now known as rm_work|away | 05:58 | |
| *** shohel has joined #openstack-barbican | 06:19 | |
| *** xaeth is now known as xaeth_afk | 06:38 | |
| *** DTadrzak has quit IRC | 07:28 | |
| *** DTadrzak has joined #openstack-barbican | 07:42 | |
| *** tkelsey has joined #openstack-barbican | 09:09 | |
| *** dimtruck is now known as zz_dimtruck | 09:27 | |
| *** jaosorior has joined #openstack-barbican | 09:41 | |
| *** mmdurrant has quit IRC | 10:09 | |
| openstackgerrit | Juan Antonio Osorio Robles proposed openstack/barbican: ** DO NOT MERGE ** https://review.openstack.org/202146 | 10:20 |
| openstackgerrit | Juan Antonio Osorio Robles proposed openstack/barbican: ** DO NOT MERGE ** https://review.openstack.org/202146 | 10:33 |
| *** mmdurrant has joined #openstack-barbican | 11:59 | |
| *** darrenmoffat has quit IRC | 12:30 | |
| *** darrenmoffat has joined #openstack-barbican | 12:31 | |
| openstackgerrit | Juan Antonio Osorio Robles proposed openstack/barbican: ** DO NOT MERGE ** https://review.openstack.org/202146 | 12:31 |
| *** alee has quit IRC | 12:56 | |
| openstackgerrit | Juan Antonio Osorio Robles proposed openstack/barbican: ** DO NOT MERGE ** https://review.openstack.org/202146 | 13:11 |
| openstackgerrit | Juan Antonio Osorio Robles proposed openstack/barbican: ** DO NOT MERGE ** https://review.openstack.org/202146 | 13:16 |
| *** gyee has joined #openstack-barbican | 13:27 | |
| cbader | rm_work: take a look at this pastebin, http://paste.openstack.org/show/380787/ it show running the mv command for devstack | 13:36 |
| jaosorior | cbader: what's up there? Seems to me like that's the way it's supposed to be, you try to move that directory without the proper permissions | 13:43 |
| cbader | jaosorior: I did do it with sudo the second time. What I am saying is the command didn't create the devstack directory for the move. | 13:44 |
| cbader | jaosorior: I tried to run the setup.sh for barbican and it fails in a number a places. I am having an issue getting barbican to start with nova, cinder, glance and other services. | 13:45 |
| jaosorior | what do you mean it didn't create the devstack directory for the move? What happened there is that it moved the devstack directory to a new directory called stack in the opt directory | 13:46 |
| jaosorior | setup.sh? Where is that script? | 13:47 |
| cbader | jaosorior: it is on the https://gist.github.com/rm-you/6feacb91182f5c011018 | 13:48 |
| jaosorior | cbader: In that case what you want is to create the /opt/stack directory first, and then do the mv | 13:49 |
| cbader | jaosorior: thank you for the help yes I did that. I was just commenting on the script that didn't work the way the author intended. | 13:50 |
| jaosorior | cbader: Oh, alright. Sorry, that's the only thing I saw about that and was a bit out of context | 13:50 |
| openstackgerrit | Juan Antonio Osorio Robles proposed openstack/barbican: ** DO NOT MERGE ** https://review.openstack.org/202146 | 13:51 |
| cbader | jaosorior: I am trying to get barbican to run with my devstack if I load the other services it fails to stack. | 13:52 |
| jaosorior | weird | 13:54 |
| *** alee has joined #openstack-barbican | 13:56 | |
| *** Kevin_Bishop has joined #openstack-barbican | 14:00 | |
| *** pglass has joined #openstack-barbican | 14:04 | |
| *** kfarr has joined #openstack-barbican | 14:08 | |
| *** woodster_ has quit IRC | 14:11 | |
| jaosorior | alee, hockeynut: I had already a workflow for this one https://review.openstack.org/#/c/199142/ but I had to change it because of the issues with the new mock. So basically only changes are in the testing code | 14:13 |
| *** kfarr has quit IRC | 14:15 | |
| alee | jaosorior, you have been re-acked | 14:20 |
| jaosorior | alee: Awesome, thanks dude | 14:21 |
| *** SheenaG has joined #openstack-barbican | 14:24 | |
| *** SheenaG has left #openstack-barbican | 14:24 | |
| *** silos has joined #openstack-barbican | 14:32 | |
| *** kfarr has joined #openstack-barbican | 14:33 | |
| *** zz_dimtruck is now known as dimtruck | 14:34 | |
| jaosorior | redrobot: ping | 14:41 |
| *** xaeth_afk is now known as xaeth | 14:55 | |
| openstackgerrit | Juan Antonio Osorio Robles proposed openstack/barbican: ** DO NOT MERGE ** https://review.openstack.org/202146 | 14:58 |
| *** chadlung has joined #openstack-barbican | 15:01 | |
| *** diazjf has joined #openstack-barbican | 15:22 | |
| *** gyee has quit IRC | 15:34 | |
| redrobot | jaosorior pong | 15:38 |
| *** gyee has joined #openstack-barbican | 15:39 | |
| jaosorior | redrobot: hey man, I was looking into the porting of the dogtag patches. I was just wandering if there's a kilo/stable branch for project-config changes. Since if there is, I will also need to port those | 15:39 |
| *** ig0r_ has quit IRC | 15:40 | |
| redrobot | jaosorior I don't think so | 15:40 |
| redrobot | jaosorior why is why moving the job to voting will affect both master and stable/kilo | 15:41 |
| jaosorior | redrobot: Alright | 15:41 |
| redrobot | jaosorior but there's always a chance I have no idea what I'm talking about and they do support different configurations across branches... | 15:41 |
| jaosorior | At the moment the dogtag gate is not working. Not sure if it's because some changes were introduced in dogtag itself, or somewhere else. But I'm fixing that before doing the backporting | 15:41 |
| *** jorge_munoz has quit IRC | 15:44 | |
| *** jorge_munoz has joined #openstack-barbican | 15:45 | |
| openstackgerrit | Merged openstack/barbican: Updated from global requirements https://review.openstack.org/201817 | 15:49 |
| silos | Is there a consensus for either merging or rebasing a branch with master after is hasn't been synced with master in a while? Just wondering what everyone else has been doing. | 15:50 |
| redrobot | silos I usually let gerrit merge whatever I have. I only rebase if gerrit finds a merge conflict. | 15:58 |
| redrobot | silos unless I notice the merge conflict before I submit | 15:59 |
| redrobot | silos so I guess the short answer is "no consensus" :) | 15:59 |
| silos | redrobot: haha thanks. | 15:59 |
| silos | It isn't a big problem now cause I haven't even made any commits on the local branch yet but I was just wondering for future reference. thanks. | 15:59 |
| *** silos1 has joined #openstack-barbican | 16:07 | |
| *** silos has quit IRC | 16:09 | |
| *** crc32 has joined #openstack-barbican | 16:11 | |
| *** woodster_ has joined #openstack-barbican | 16:20 | |
| *** spotz_zzz is now known as spotz | 16:26 | |
| *** SheenaG has joined #openstack-barbican | 16:29 | |
| *** gyee has quit IRC | 16:35 | |
| *** crc32 has quit IRC | 16:38 | |
| *** crc32 has joined #openstack-barbican | 16:39 | |
| *** alee is now known as alee_lunch | 16:42 | |
| *** crc32 has quit IRC | 16:56 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/barbican: Updated from global requirements https://review.openstack.org/202696 | 16:59 |
| *** chadlung_ has joined #openstack-barbican | 17:04 | |
| *** chadlung has quit IRC | 17:04 | |
| *** chadlung has joined #openstack-barbican | 17:06 | |
| *** chadlung_ has quit IRC | 17:06 | |
| *** shohel has quit IRC | 17:07 | |
| *** chadlung has quit IRC | 17:12 | |
| *** chadlung has joined #openstack-barbican | 17:12 | |
| *** rm_work|away is now known as rm_work | 17:13 | |
| *** chadlung has quit IRC | 17:17 | |
| *** chadlung has joined #openstack-barbican | 17:17 | |
| *** chadlung_ has joined #openstack-barbican | 17:20 | |
| *** chadlung has quit IRC | 17:20 | |
| *** chadlung_ has quit IRC | 17:22 | |
| *** chadlung has joined #openstack-barbican | 17:22 | |
| *** chadlung has quit IRC | 17:26 | |
| cbader | I am getting error in bringing up barbican on stable/kilo I have a pastebin of the error here. http://paste.openstack.org/show/381347/ any help appriciated. | 17:29 |
| *** shohel has joined #openstack-barbican | 17:33 | |
| *** vivek__ has joined #openstack-barbican | 17:36 | |
| *** kfarr has quit IRC | 17:40 | |
| *** vivek__ has quit IRC | 17:44 | |
| rm_work | cbader: yeah, you did the command differently in your paste | 17:46 |
| rm_work | cbader: that would fail | 17:46 |
| rm_work | [stack@carl-stack1:~]↥ 1 $ sudo mv devstack/ /opt/stack | 17:46 |
| rm_work | ^^ that is wrong | 17:46 |
| rm_work | mv /tmp/devstack /opt/stack/ | 17:46 |
| rm_work | THAT is correct | 17:46 |
| rm_work | the stack user needs to exist first | 17:47 |
| cbader | rm_work: I am trying to get barbican to work stable/kilo moved off master | 17:47 |
| rm_work | which happens via: | 17:47 |
| rm_work | /tmp/devstack/tools/create-stack-user.sh | 17:47 |
| rm_work | which is the line right before it | 17:47 |
| rm_work | notice the extra / at the end | 17:47 |
| cbader | rm_work:thank you for info | 17:47 |
| rm_work | that explains why you were seeing weird results :) | 17:48 |
| cbader | rm_work: great thanks can you look at the pastebin and see if you have seen that error. | 17:48 |
| rm_work | which pastebin | 17:48 |
| rm_work | https://gist.github.com/rm-you/6feacb91182f5c011018 ? | 17:49 |
| rm_work | err | 17:49 |
| rm_work | http://paste.openstack.org/show/380787/ | 17:49 |
| rm_work | ? | 17:49 |
| cbader | rm_work:yes 380787 | 17:49 |
| rm_work | no | 17:49 |
| rm_work | that should not happen | 17:49 |
| rm_work | if you ran the script, it would create the user | 17:49 |
| rm_work | so the /opt/stack directory would exist | 17:49 |
| cbader | rm_work: thanks for help | 17:49 |
| rm_work | then the mv command (which you typed incorrectly in that paste) would run properly and move the directory into /opt/stack/devstack | 17:50 |
| cbader | rm_work: in my group we don't run devstack out of the /opt/stack directory is there some requirement that I do. I have it off the /home/stack directory. | 17:52 |
| rm_work | ah, no | 17:52 |
| rm_work | you don't have to | 17:52 |
| rm_work | but that is non-standard | 17:52 |
| rm_work | just change the lines: | 17:52 |
| cbader | rm_work: oh just following group practices. | 17:52 |
| rm_work | 11-13 | 17:53 |
| rm_work | all of the copy lines | 17:53 |
| rm_work | just change /tmp/devstack to /home/stack/devstack | 17:53 |
| rm_work | assuming you already have a devstack install | 17:53 |
| cbader | rm_work: I need to edit the local.conf to add my blade enviromentals do I need the rabbit mysql and key in the service enble line of local.conf | 17:54 |
| rm_work | so from barbican/contrib/devstack/local.conf | 17:55 |
| rm_work | https://github.com/openstack/barbican/blob/master/contrib/devstack/local.conf | 17:55 |
| rm_work | you will need all the services | 17:55 |
| rm_work | so yes make sure rabbit mysql key barbican | 17:56 |
| rm_work | because barbican will need rabbitmq, mysql, and keystone | 17:56 |
| cbader | rm_work:they are already started as part of the rest of the keystone, cinder, nova, glance and other services. Ok thanks | 17:57 |
| *** gyee has joined #openstack-barbican | 17:57 | |
| *** kfarr has joined #openstack-barbican | 17:57 | |
| rm_work | yeah so they should already exist in your enable services line? | 17:57 |
| cbader | rm_work: thanks will try. | 17:58 |
| *** kfarr has quit IRC | 18:02 | |
| *** alee_lunch is now known as alee | 18:09 | |
| *** xek has quit IRC | 18:10 | |
| *** DTadrzak has quit IRC | 18:10 | |
| *** vivek_ has joined #openstack-barbican | 18:11 | |
| *** DTadrzak has joined #openstack-barbican | 18:12 | |
| *** xek has joined #openstack-barbican | 18:13 | |
| *** kfarr has joined #openstack-barbican | 18:17 | |
| *** tkelsey has quit IRC | 18:22 | |
| *** crc32 has joined #openstack-barbican | 18:24 | |
| *** shohel has quit IRC | 18:30 | |
| *** kfarr has quit IRC | 18:40 | |
| *** rm_work is now known as rm_work|away | 18:45 | |
| *** jaosorior has quit IRC | 18:46 | |
| *** kfarr has joined #openstack-barbican | 18:55 | |
| kfox1111 | redrobot: alive? | 19:43 |
| redrobot | kfox1111 o/ | 19:43 |
| kfox1111 | :) | 19:43 |
| kfox1111 | any discussion hapen with the designate folks yet? | 19:43 |
| kfox1111 | we have a need for a feature that crosses both designate and barbican. not clear which it kind of belongs to. if I need a spec in barbican, designate, both, or crossproject. | 19:44 |
| kfox1111 | do you have a preference? | 19:45 |
| *** nkinder has quit IRC | 19:45 | |
| redrobot | kfox1111 I think maybe both? With a description of the problem, and a focus on the changes needed in each one? | 19:45 |
| redrobot | kfox1111 not sure what the crossproject specs are for? | 19:46 |
| kfox1111 | so, basically, designate provides dns for *.*.cloud.pnnl.gov. | 19:46 |
| kfox1111 | I need ssl certs that are signed by one ca that match those dns names. | 19:46 |
| kfox1111 | so barbican can provide the one ca, and the signing api, | 19:46 |
| kfox1111 | but designate's the source of ownership truth. | 19:46 |
| kfox1111 | so its not clear, does the user interact with designate and it proxies parts over to barbican, | 19:47 |
| kfox1111 | or the other way around. | 19:47 |
| redrobot | kfox1111 what's the use case? | 19:47 |
| kfox1111 | the most common one strangely. :) user launches a web server, and wants https to work. :) | 19:48 |
| kfox1111 | self signed is really really bad. :/ | 19:48 |
| kfox1111 | each tenant having its own ca, having to load it into the browser of everyone else is a no go either. :/ | 19:48 |
| kfox1111 | each tenant gets their own subdomain under their own control in designate. so project foo gets *.foo.cloud.pnnl.gov | 19:49 |
| kfox1111 | so we don't want to just allow anyone to create certs for subdomains they don't own. | 19:50 |
| kfox1111 | designate maintains those permissions. | 19:50 |
| redrobot | kfox1111 RE: "self signed is really really bad" so you need x.509 certs to be issued by a public CA? | 19:50 |
| kfox1111 | we have a CA at the lab, and I'm thinking we write a plugin to make that ca available to barbican. | 19:51 |
| kfox1111 | that ca's cert is already loaded into every browser at the lab. | 19:51 |
| redrobot | kfox1111 so not necessarily a public CA, but you want to define what the trusted root is? | 19:51 |
| *** dave-mcc has joined #openstack-barbican | 19:52 | |
| kfox1111 | need a way to issue certs to that shared ca, but not allow one tenant to create a cert in a domain not registered to them. | 19:52 |
| kfox1111 | I'm not too familior with ca's. I was under the impression a ca could sign certs for all sites, not just subdomains. | 19:53 |
| kfox1111 | if you can create subca's that can be restricted to a particular subdomain, and the ca's chain of trust works without loading anything but the root ca into the browser, that would work too. | 19:53 |
| redrobot | Designate knows which tenant owns which subdomain? | 19:55 |
| kfox1111 | correct. you end up creating a subdomain in the primary domain, and then you can "transfer" it from one tenant to another. | 19:55 |
| kfox1111 | so our mgmt tenant owns cloud.pnnl.gov, we create foo.cloud.pnnl.gov in it for the foo project, and then transfer it to them. | 19:55 |
| kfox1111 | then can further subdomain it and transfer bits if they like. | 19:56 |
| kfox1111 | very cool in some ways. :) | 19:56 |
| kfox1111 | makes for getting valid ssl certs a bit tricky though, without some kind of integration with designate. | 19:57 |
| redrobot | kfox1111 does Designate have an API that exposes which subdomains belong to a tenant? | 19:58 |
| kfox1111 | not sure. I'll go look. If not, I'm sure it could be part of the blueprint. | 19:59 |
| redrobot | kfox1111 so the tricky part is going to be making the subdomain determination... that should be handled by the CA. Barbican is not a full CA itself, but rather defers the actual provisioning of the cert to a 3rd party CA. | 20:00 |
| redrobot | afaik, DogTag does have support for private roots | 20:00 |
| redrobot | so you could run dogtag as your CA | 20:00 |
| redrobot | with a self signed root that you mark as trusted in your clients | 20:00 |
| redrobot | the tricky part is going to be configuring the auth piece based on the DN of the cert request. | 20:01 |
| kfox1111 | yeah. | 20:01 |
| kfox1111 | http://designate.readthedocs.org/en/latest/rest/v2/zones.html | 20:01 |
| redrobot | from barbican's point of view, we just forward the request to the CA and then store it when it's ready | 20:01 |
| kfox1111 | There isn't a get zone by name, only by id. but I'm sure it coudl be added. | 20:02 |
| kfox1111 | the question is, does the user go to designate to fetch the cert, since it already knows if the user is allowed or not, and proxy the call over to barbican, | 20:02 |
| kfox1111 | or does the call go to a barbican api, and barbican calls over to designate for subdomain ownership verification? | 20:03 |
| redrobot | kfox1111 I think that would be the easiest way to do this, since Designate knows whether the DN is allowed or not. | 20:03 |
| redrobot | kfox1111 barbican doesn't know anything about which DNs are allowed or not, so we would have to develop a smart CA that can make that determination, and then plugin that newly developed CA into barbican. | 20:04 |
| redrobot | for public CAs, they have processes to determine if your DN is valid or not... but I have no idea how to automate that with a self signed root. | 20:04 |
| kfox1111 | ok. so designate would basically have its own tenant, manage barbican keys in there, and deal with the DN's itself? The user would only request a cert from designate? | 20:04 |
| kfox1111 | in that case, barbican would simply just be a CA/secret store. | 20:05 |
| kfox1111 | which sounds about right... | 20:05 |
| redrobot | kfox1111 yeah, for the user it could be as easy as checking a box that says they need TLS | 20:05 |
| kfox1111 | yeah. thats my hope. :) | 20:05 |
| redrobot | then designate can craft the CSR with the correct DN, and Barbican would just trust the request because it came from Designate. | 20:05 |
| kfox1111 | ok. I'll raise it as a designate spec, since it would be driven by them, and see how it fly's. | 20:06 |
| redrobot | kfox1111 with the per-project CAs, we could even make that self-signed root private and available only to the designate service user | 20:06 |
| kfox1111 | yeah, I think that part would be critical. | 20:06 |
| *** rm_work|away is now known as rm_work | 20:07 | |
| redrobot | kfox1111 yep, sounds like the correct approach to me. ping me when you have the spec up for review. | 20:07 |
| kfox1111 | ok. will do. thanks for the help. :) | 20:07 |
| *** nkinder has joined #openstack-barbican | 20:34 | |
| kfox1111 | where's the barbican api docs? | 20:40 |
| redrobot | kfox1111 http://docs.openstack.org/developer/barbican/api/index.html | 20:40 |
| kfox1111 | thx. | 20:40 |
| kfox1111 | one more thought on the designate thing. | 20:41 |
| *** dave-mccowan has joined #openstack-barbican | 20:41 | |
| kfox1111 | user creates an octavia lb thats hosting the dns entry the tenant owns, and wants to do ssl termination in the lb. | 20:41 |
| openstackgerrit | Dave McCowan proposed openstack/barbican: Add RBAC Functional Test for ACL Opeations https://review.openstack.org/200696 | 20:41 |
| kfox1111 | that currently goes to barbican directly, I think. woudl that get changed to talk to designate instead? | 20:42 |
| redrobot | kfox1111 so octavia does not have the DN restrictions you have. They assume the user either has a valid cert, or they can request one from Barbican. They also assume public CA is being used | 20:43 |
| redrobot | rm_work does that sound right? ^^ | 20:43 |
| redrobot | kfox1111 a customer could bring their own domain, for example. as I understand your use case, they are very limited on what that domain can be. | 20:44 |
| *** dave-mcc has quit IRC | 20:44 | |
| kfox1111 | yeah. | 20:44 |
| kfox1111 | hmm... | 20:45 |
| kfox1111 | idea... do secret acl's support tenant's? | 20:45 |
| kfox1111 | if so, you could have designate put in the order for the correct/restricted DN'ed cert, then add the tenant who own's it to that secret's acl. | 20:46 |
| kfox1111 | the user could then fetch it via barbican as normal. | 20:46 |
| dave-mccowan | by default RBAC, access to secrets is limited to a project(tenant) and only to users with a role of [admin,creator,observer] in that project. | 20:48 |
| dave-mccowan | so any secret created for project1 could not be accessed by a user of project 2. no ACL needed. | 20:48 |
| kfox1111 | yeah, so designate would own a project/tenant. have a private ca, create certs in there, | 20:48 |
| kfox1111 | but would want to hand out specific certs to their owners. so would need a tenant level acl on jus the secret, | 20:49 |
| redrobot | kfox1111 I'm not sold on tenant level acl. it seems like a reimplementation of rbac | 20:49 |
| redrobot | kfox1111 what about this: | 20:49 |
| redrobot | Designate requests the cert from their project-specific CA. Barbican trusts the request because it came from Designate, and routes it to the predefined self-signed root. | 20:50 |
| kfox1111 | or some how transfer a secret from the designate tenant to the projects? | 20:50 |
| dave-mccowan | then ACLs could appy. secret would be created in designate's project, and access defined to a list of users in the tenant's project. but, it would have to be a list of specific users. | 20:50 |
| redrobot | then Designate uploads the cert to the users' project. | 20:50 |
| redrobot | yeah... I'm not sure if/when keystone will support impersonation. | 20:50 |
| redrobot | we can do it now in Rackspace cloud... where a token looks like a user token, but in reality is a service level user impersonating the customer. | 20:51 |
| redrobot | Designate -> barbican to provision cert | 20:51 |
| kfox1111 | barbican concern's itself with users too often in my opinion. tenants are the unit of ownership in openstack. | 20:51 |
| redrobot | kfox1111 agreed. by default all our access is scoped to the project (aka tenant) | 20:52 |
| kfox1111 | users go on vacation, and another needs to work in his/her place (I'm going on vacation next week. :) | 20:52 |
| redrobot | kfox1111 ACLs were added because there was a strong push for an alternative way of segregating secrets. | 20:52 |
| kfox1111 | yeah. because tenants -> roles mappings are very corse grained. | 20:52 |
| redrobot | kfox1111 I still don't like ACLs to be honest, but I was outvoted for adding the support | 20:52 |
| kfox1111 | tenant A may need one secret from tenant B. | 20:53 |
| redrobot | kfox1111 you mean a user in poroject A needs a secret from project B? then the user should be granted a new role in Project B | 20:53 |
| kfox1111 | Yeah, I like the way amazon did it. :/ | 20:53 |
| kfox1111 | but then that gives user access to all of project b's secrets. thats too much. | 20:54 |
| redrobot | so you add a new project C, where you add just the secrets you want to share... | 20:54 |
| kfox1111 | the only way to really secure things then is to have one secret per project so you cna assign them. :/ | 20:54 |
| kfox1111 | Yeah. :/ painful. | 20:54 |
| kfox1111 | We don't allow users to create their own projects today. | 20:54 |
| redrobot | it's the way Keystone set up everything... a lot of people don't like it and we end up having to add things to other services to work around it, like ACLs :( | 20:55 |
| kfox1111 | There be draggons there I think. :/ | 20:55 |
| kfox1111 | yeah. the problem is it implies too much to too many projects. | 20:55 |
| kfox1111 | say you create all those tennants for barbican secrets. | 20:55 |
| kfox1111 | each has a nova default quota. | 20:55 |
| kfox1111 | way way too many reasources are now given out on the compute side. | 20:56 |
| kfox1111 | and worse, giving user A access to tenant b's secret via a tenant may give them access to launch vm's in that space. | 20:57 |
| kfox1111 | bleh. | 20:57 |
| kfox1111 | keystone tenants work fairly well as an idea when looked at only from one project's silo, but starts to break down in the big tent. :/ | 20:57 |
| redrobot | kfox1111 so that could be mitigated with namespaced roles, I think | 20:58 |
| redrobot | grant "barbican:read" role on project b | 20:58 |
| redrobot | does not give teh user permission to launch vms for example | 20:59 |
| kfox1111 | yes, but that also means all other keystone supporting projects have to have roles that are required before something can work. | 20:59 |
| kfox1111 | so nova-compute role, and glance and sahara, etc. | 20:59 |
| kfox1111 | none of those exist today. :/ | 20:59 |
| redrobot | there was talk at the summit about adding them | 20:59 |
| redrobot | part of the dynamic policy talks | 20:59 |
| kfox1111 | yeah. I think they will get there eventually. I'm looking forward to it. but I think its at least a year out. :/ | 21:00 |
| *** gyee has quit IRC | 21:02 | |
| kfox1111 | so yay or nay on tenant acls? I don't think they are very different then user acl's. | 21:03 |
| *** SheenaG has quit IRC | 21:03 | |
| kfox1111 | they would let designate continue to own the secret, and delete it when ownership of the subdomain changes. | 21:03 |
| kfox1111 | it would still need to revoke it, and the user might have a copy, but still one less thing to trip over. | 21:04 |
| kfox1111 | another bonus is designate would never have to handle the actual secret then. it would just create it and allow the user to directly fetch it. | 21:05 |
| redrobot | I'm not a fan of tenant acls. we can add it to the agenda next week though. other folks might find it interesting. | 21:06 |
| kfox1111 | k. | 21:06 |
| kfox1111 | thx. | 21:06 |
| kfox1111 | does the order api for a stored key certificate order allow you to specify the DN? | 21:09 |
| kfox1111 | oh... its 2 orders. | 21:11 |
| kfox1111 | so.... hmm.... | 21:11 |
| redrobot | kfox1111 you (the client) crafts the CSR | 21:11 |
| redrobot | CSR includes the DN | 21:12 |
| kfox1111 | designate would have to have some workflow manager of its own... :/ | 21:12 |
| redrobot | kfox1111 yeah... public CAs can take up to a couple of weeks before a cert is issued... so we have to have an async api | 21:12 |
| kfox1111 | so, designate-api gets a request for a ssl cert. validates user owns it. looks in its db, doesn't have a container or order url. generates a certificate, stores it in barbican. sets the container in the db. then creates the barbican order and returns "try again" | 21:13 |
| kfox1111 | on contact, while order url is set, it checks on the order first, fetches the other container url when the order's ready, then clears the order url from the db? | 21:15 |
| kfox1111 | "looking at the stored key certificate order" section of http://docs.openstack.org/developer/barbican/api/quickstart/certificates.html | 21:16 |
| kfox1111 | it would be nice if the private key could be generated in barbican too rather then generate and transfer it in. | 21:16 |
| kfox1111 | but I'd have to set the dn in the request somehow. can that be stuck in the "meta" section? | 21:16 |
| redrobot | kfox1111 we do support that. that's what the "stored key" case is all about | 21:16 |
| redrobot | the key is "stored" in barbican already | 21:16 |
| redrobot | either by you storing it, or by sending an order to generate it | 21:17 |
| rm_work | kfox1111: yeah, stored key create | 21:17 |
| rm_work | isn't DN part of the CSR? | 21:17 |
| rm_work | how could you have a cert request WITHOUT a DN? | 21:17 |
| rm_work | or am i really confused | 21:17 |
| kfox1111 | oh. your right. its in the second order. I see it. | 21:17 |
| redrobot | rm_work you may be confused. :-P | 21:17 |
| kfox1111 | "subject_dn" | 21:18 |
| kfox1111 | so does the second order create a second container? | 21:18 |
| redrobot | kfox1111 not every order creates a container | 21:18 |
| redrobot | kfox1111 only orders which result in multiple secrets | 21:18 |
| redrobot | kfox1111 like ordering a public/private keypair | 21:19 |
| redrobot | kfox1111 or a certificate, which also includes intermediates. | 21:19 |
| kfox1111 | ok, in this specific workflow? :) | 21:19 |
| rm_work | redrobot: when I make a CSR, the DN is essentially 90% of the data I put in | 21:19 |
| redrobot | rm_work yes, CSR does contain the DN | 21:19 |
| kfox1111 | so the initial private key order creates the container, and the certificate order just drops the cert into the same container? | 21:19 |
| rm_work | i thought | 21:19 |
| redrobot | initial order creates an RSA container... it has a ref to the private part. second order includes that secret ref (to the private key only) | 21:20 |
| redrobot | ie. the Cert order does not need the public rsa bits | 21:21 |
| kfox1111 | and where does the cert go then? Another container? | 21:22 |
| *** kfarr has left #openstack-barbican | 21:22 | |
| kfox1111 | I guess it would have to, since it doesn't have a reference to the container. | 21:23 |
| redrobot | kfox1111 yep. cert order creates a cert-type container | 21:23 |
| redrobot | kfox1111 rsa key order creates an rsa-type container | 21:23 |
| kfox1111 | so if we did the acl thing, we'd need tenant acl's on both containers. | 21:25 |
| kfox1111 | or... | 21:25 |
| kfox1111 | the designate api could take in the rsa key container id, generate the cert, and then acl just the cert container. | 21:26 |
| kfox1111 | the formers' more work for designate. the latter's more work for the user. | 21:26 |
| kfox1111 | got a meting I gota go to. thanks for the discussion. | 21:27 |
| *** Kevin_Bishop has quit IRC | 21:39 | |
| *** vivek_ has quit IRC | 21:51 | |
| *** silos1 has left #openstack-barbican | 21:55 | |
| *** SheenaG has joined #openstack-barbican | 21:57 | |
| *** diazjf has left #openstack-barbican | 21:57 | |
| *** vivek_ has joined #openstack-barbican | 21:58 | |
| *** xaeth is now known as xaeth_afk | 22:14 | |
| *** vivek__ has joined #openstack-barbican | 22:15 | |
| *** vivek_ has quit IRC | 22:15 | |
| *** pglass has quit IRC | 22:16 | |
| *** SheenaG has quit IRC | 22:25 | |
| *** spotz is now known as spotz_zzz | 22:34 | |
| *** SheenaG has joined #openstack-barbican | 22:41 | |
| *** alee has quit IRC | 22:42 | |
| *** shohel has joined #openstack-barbican | 22:57 | |
| *** shohel has quit IRC | 23:05 | |
| *** zigo has quit IRC | 23:21 | |
| *** zigo has joined #openstack-barbican | 23:22 | |
| *** dimtruck is now known as zz_dimtruck | 23:25 | |
| *** vivek__ has quit IRC | 23:26 | |
| *** openstackstatus has joined #openstack-barbican | 23:33 | |
| *** ChanServ sets mode: +v openstackstatus | 23:33 | |
| *** SheenaG has quit IRC | 23:43 | |
| *** SheenaG has joined #openstack-barbican | 23:46 | |
| *** vivek_ has joined #openstack-barbican | 23:52 | |
| *** barra204 has joined #openstack-barbican | 23:54 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!