| *** ametts has quit IRC | 00:06 | |
| *** crc32 has joined #openstack-barbican | 00:24 | |
| greghaynes | I get this nice error message why trying to use barbicanclient Authentication failure: Expecting to find domain in user - the server could not comply with the request since it is either malformed or otherwise incorrect. The client is assumed to be in error. (HTTP 400) | 00:27 |
|---|---|---|
| *** david-lyle is now known as david-lyle_afk | 00:33 | |
| greghaynes | maybe we should by default be specifying the default domain id | 00:36 |
| greghaynes | since it appears to not be optional | 00:36 |
| greghaynes | morganfainberg: ^ | 00:37 |
| morganfainberg | hi | 00:37 |
| greghaynes | HAI | 00:37 |
| morganfainberg | i swear i'm not lurking in your channel here | 00:37 |
| greghaynes | heh, *my* channel? ;) | 00:37 |
| morganfainberg | >.> | 00:37 |
| greghaynes | so yea, looks like domain is required for /v3/auth/tokens? | 00:38 |
| morganfainberg | are you authing with username? | 00:38 |
| morganfainberg | or user id? | 00:38 |
| greghaynes | keystone docs says this isnt true, the error message im getting says otherwise | 00:38 |
| morganfainberg | with username, yes domain is required | 00:38 |
| morganfainberg | user_id should not be | 00:38 |
| morganfainberg | usernames are not unique across keystone, only unique within a domain | 00:38 |
| greghaynes | {"auth": {"identity": {"password": {"user": {"domain": {"id": "default"}, "password": "unset", "name": "admin"}}, "methods": ["password"]}}} | 00:38 |
| greghaynes | ah, ok | 00:38 |
| morganfainberg | :) | 00:39 |
| morganfainberg | see easy answer | 00:39 |
| greghaynes | morganfainberg: any reason the keystoneclient doesnt default to domain "default"? | 00:39 |
| greghaynes | or keystone server just assume that? | 00:39 |
| morganfainberg | how does the client know you mean default domain? | 00:39 |
| morganfainberg | how do i know you're not in error by forgetting to add it and then are trying to auth against a user that isn't you. | 00:40 |
| morganfainberg | default domain is a special construct for v2->v3 compat | 00:40 |
| morganfainberg | it just is where we stick people / things that are made via the v2 api | 00:41 |
| morganfainberg | it' should probably be named "v2_compat_domain" not "Default", but i think we'd get more questions that way | 00:41 |
| greghaynes | aha! so you just dont want there to actually be a default really | 00:41 |
| greghaynes | just also to not break the world | 00:42 |
| *** nkinder has joined #openstack-barbican | 00:46 | |
| *** atiwari2 has quit IRC | 00:47 | |
| *** jkf has quit IRC | 00:47 | |
| greghaynes | morganfainberg: another question while youre here :) Ive noticed the version discovery used in barbicanclient isnt (it just assumes os-auth-url is /v3) and other clients tend to have randomish behavior for this situation | 00:48 |
| greghaynes | morganfainberg: any idea if theres a plan / spec / similar on what clients should be doing? | 00:48 |
| morganfainberg | jamielennox, ^ | 00:48 |
| * morganfainberg summons the person who has the most information on this, | 00:48 | |
| greghaynes | awesome :) | 00:48 |
| jamielennox | umm | 00:48 |
| jamielennox | reading | 00:48 |
| morganfainberg | but there is some work we've been pushing, nothing formal | 00:49 |
| morganfainberg | jamielennox, version disc stuff | 00:49 |
| *** atiwari2 has joined #openstack-barbican | 00:49 | |
| morganfainberg | just the last question | 00:49 |
| jamielennox | more domain discovery | 00:49 |
| jamielennox | oh - not that bit | 00:49 |
| greghaynes | yea, just version discovery | 00:49 |
| jamielennox | greghaynes: the barbican URL in the servcie catalog is unversioned right? | 00:49 |
| jamielennox | i did a bunch of things for barbican | 00:50 |
| *** kgriffs is now known as kgriffs|afk | 00:50 | |
| greghaynes | Im not even to service catalog yet, we just set OS_AUTH_URL in tripleo | 00:50 |
| jamielennox | ok so OS_AUTH_URL is keystone - where you send the auth request to | 00:51 |
| greghaynes | (I am also just learning about keystoneish stuff so feel free to tell me im way off ;)) | 00:51 |
| jamielennox | as part of the auth response you get a service catalog, and in that there is an entry for barbican | 00:51 |
| jamielennox | the barbican client takes that value out of the service catalog and that's what it uses to talk to the barbican server | 00:52 |
| greghaynes | yep, so we set OS_AUTH_URL=foo:port/v2. When barbicanclient is first trying to hit auth/tokens its asuuming OS_AUTH_URL ends with v3 and errors | 00:52 |
| jamielennox | ah this is the CLI | 00:52 |
| greghaynes | yes | 00:52 |
| jamielennox | let me have a look | 00:53 |
| jamielennox | ok so the cli is taking an args.endpoint as well as the OS_AUTH_URL | 00:55 |
| jamielennox | oh, optionally | 00:55 |
| greghaynes | hrm, so I wonder if we should just not be specifying v2 in our OS_AUTH_URL? | 00:56 |
| jamielennox | it looks like it's doing the right thing | 00:56 |
| greghaynes | (this is for tripleo) | 00:56 |
| jamielennox | sort of | 00:56 |
| jamielennox | you can set os-identity-api-version to 2 to use v2 auth | 00:57 |
| jamielennox | it just defaults to v3 auth | 00:58 |
| greghaynes | aha, ty | 01:00 |
| greghaynes | It does seem like version disc works if I just set to auth-url to /... I wonder how many of the other clients work with that | 01:01 |
| jamielennox | greghaynes: they all have a bad habit of doing there own thing | 01:05 |
| jamielennox | however OS_AUTH_URL is pretty standard and this is the only client i've seen that doesn't expect it to end with /v2. | 01:06 |
| jamielennox | 0 | 01:06 |
| greghaynes | yea, and we run all of them, and I bet /v2 is just the least common denomonator | 01:06 |
| * greghaynes might try and see how mant things break if we just dont specify a version though | 01:07 | |
| *** dimtruck is now known as zz_dimtruck | 01:16 | |
| *** bdpayne_ has quit IRC | 01:46 | |
| *** atiwari2 has quit IRC | 01:57 | |
| greghaynes | redrobot: You see the ML reply from sdague? | 01:59 |
| greghaynes | redrobot: and https://review.openstack.org/#/c/150645/ | 02:00 |
| *** kebray has quit IRC | 02:00 | |
| greghaynes | and https://review.openstack.org/#/c/150618/2 | 02:04 |
| greghaynes | :) | 02:04 |
| greghaynes | fun times | 02:04 |
| *** bdpayne has joined #openstack-barbican | 02:17 | |
| *** alpha_ori has quit IRC | 02:21 | |
| *** alee has joined #openstack-barbican | 02:26 | |
| *** alpha_ori has joined #openstack-barbican | 02:33 | |
| redrobot | greghaynes just saw that reply... it's an interesting problem because the proposal bot keeps us in sync with global requirements. I wonder if there's anything we could have done to avoid this? | 02:33 |
| greghaynes | well, the first thing is probably adding the stable job | 02:34 |
| greghaynes | so we could know before releasing :) | 02:35 |
| greghaynes | I am also unclear on what the correct fix is, though | 02:37 |
| * greghaynes asks some people who are smarter than I | 02:37 | |
| *** kebray has joined #openstack-barbican | 02:39 | |
| greghaynes | redrobot: ok, so I big thing is definitely that we have a test. Now, seems like its not a big deal that were pinned in the stable branch, but if we want to fix that were going to have to backport oslo.serialization 1.2.0 | 02:47 |
| greghaynes | basically, clients + stable branches = pain so test and expect things to break is what ive been told :) | 02:48 |
| redrobot | greghaynes haha, yeah, definitely been feeling the pain lately :) | 02:49 |
| *** crc32 has quit IRC | 03:16 | |
| openstackgerrit | Ade Lee proposed openstack/barbican: Add code to generate a CSR in the stored key case https://review.openstack.org/150670 | 04:01 |
| openstackgerrit | Ade Lee proposed openstack/barbican: Add support for simple cmc requests to Dogtag plugin https://review.openstack.org/146611 | 04:06 |
| *** woodster_ has quit IRC | 04:13 | |
| *** zz_dimtruck is now known as dimtruck | 04:35 | |
| *** Nirupama has joined #openstack-barbican | 05:33 | |
| *** kebray has quit IRC | 05:33 | |
| *** dimtruck has quit IRC | 05:39 | |
| *** dimtruck has joined #openstack-barbican | 05:39 | |
| *** chellygel has quit IRC | 05:39 | |
| *** insequent has quit IRC | 05:39 | |
| *** chellygel has joined #openstack-barbican | 05:39 | |
| *** alee has quit IRC | 05:40 | |
| *** alee has joined #openstack-barbican | 05:40 | |
| *** insequent has joined #openstack-barbican | 05:46 | |
| *** kebray has joined #openstack-barbican | 05:48 | |
| *** woodster_ has joined #openstack-barbican | 06:11 | |
| *** kebray has quit IRC | 07:22 | |
| *** jaosorior has joined #openstack-barbican | 07:35 | |
| *** jamielennox is now known as jamielennox|away | 08:09 | |
| *** woodster_ has quit IRC | 08:23 | |
| *** bdpayne has quit IRC | 08:40 | |
| *** bdpayne has joined #openstack-barbican | 08:45 | |
| *** bdpayne has quit IRC | 09:15 | |
| *** openstackgerrit has quit IRC | 10:50 | |
| *** openstackgerrit has joined #openstack-barbican | 10:50 | |
| openstackgerrit | Juan Antonio Osorio Robles proposed openstack/barbican: Handle SystemExit properly in migration script https://review.openstack.org/150756 | 11:38 |
| *** rm_you| has quit IRC | 11:49 | |
| *** rm_you| has joined #openstack-barbican | 11:49 | |
| openstackgerrit | Juan Antonio Osorio Robles proposed openstack/barbican: Handle SystemExit properly in migration script https://review.openstack.org/150756 | 12:23 |
| openstackgerrit | Juan Antonio Osorio Robles proposed openstack/barbican: Add 'history' option to the migration script https://review.openstack.org/150764 | 12:39 |
| openstackgerrit | Juan Antonio Osorio Robles proposed openstack/barbican: Add 'history' option to the migration script https://review.openstack.org/150764 | 12:42 |
| *** woodster_ has joined #openstack-barbican | 12:45 | |
| *** Nirupama has quit IRC | 13:29 | |
| *** darrenmoffat has quit IRC | 13:42 | |
| *** darrenmoffat has joined #openstack-barbican | 13:43 | |
| openstackgerrit | Tim Kelsey proposed openstack/barbican-specs: Adding spec for Barbican MKEK Model. https://review.openstack.org/148948 | 13:44 |
| *** rellerreller has joined #openstack-barbican | 13:47 | |
| *** SheenaG1 has joined #openstack-barbican | 14:04 | |
| *** lisaclark1 has joined #openstack-barbican | 14:27 | |
| *** dimtruck is now known as zz_dimtruck | 14:39 | |
| jaosorior | woodster_: ping | 14:40 |
| openstackgerrit | Juan Antonio Osorio Robles proposed openstack/barbican: Add 'history' option to the migration script https://review.openstack.org/150764 | 15:08 |
| openstackgerrit | Juan Antonio Osorio Robles proposed openstack/barbican: Add 'current' option to the migration script https://review.openstack.org/150806 | 15:08 |
| *** lisaclark1 has quit IRC | 15:10 | |
| *** bdpayne has joined #openstack-barbican | 15:11 | |
| *** zz_dimtruck is now known as dimtruck | 15:12 | |
| *** lisaclark1 has joined #openstack-barbican | 15:13 | |
| *** kgriffs|afk is now known as kgriffs | 15:19 | |
| *** bdpayne_ has joined #openstack-barbican | 15:24 | |
| *** bdpayne has quit IRC | 15:28 | |
| *** kebray has joined #openstack-barbican | 15:29 | |
| jaosorior | or... is anybody familiar with alembic? | 15:32 |
| *** kebray has quit IRC | 15:36 | |
| *** tkelsey has joined #openstack-barbican | 15:42 | |
| *** woodster_ has quit IRC | 15:43 | |
| *** woodster_ has joined #openstack-barbican | 15:49 | |
| *** ametts has joined #openstack-barbican | 15:49 | |
| openstackgerrit | Ade Lee proposed openstack/barbican: Add code to generate a CSR in the stored key case https://review.openstack.org/150670 | 15:53 |
| alee | woodster_, ping | 15:54 |
| woodster_ | alee, morning | 15:57 |
| alee | woodster_, morning -- I've put up a few patches for review :) | 15:58 |
| alee | woodster_, but I wanted to ask frst about the identify-ca models patch .. | 15:58 |
| alee | so that I make sure to address the comments correctly | 15:58 |
| *** tkelsey has quit IRC | 15:59 | |
| alee | woodster_, specifically https://review.openstack.org/#/c/147323/ | 15:59 |
| alee | woodster_, line 801 -- do you think a constraint is needed? | 16:00 |
| rellerreller | woodster_ alee jaosorior What does you guys think of limiting the scope of the content types spec to not include encrypted keys? | 16:00 |
| woodster_ | alee, ok, I'll take a look. Also, regarding the per-secret rbac bp, were you ok with adding a new role such as 'read_shared' to allow such users access to whitelisted secrets?: https://review.openstack.org/#/c/127353/ | 16:01 |
| rellerreller | I would like to make progress with the current spec and my work, and I think adding encrypted types could open up another can of worms. | 16:01 |
| *** david-lyle_afk is now known as david-lyle | 16:01 | |
| alee | woodster_, yes -- I plan to work on the next version of the spec as soon as I get the next models patch out. | 16:02 |
| woodster_ | alee, I don't see the harm in adding a constraint, I'd say go for it | 16:02 |
| rellerreller | Plus I think with the containers passphrase for keys and the transport keys may be using different specs | 16:02 |
| woodster_ | rellerreller, let me take a look real quick | 16:03 |
| alee | rellerreller, I'm ok with leaving out transport key stuff for now - but I'm a little concerned with making private key storage anything other than what openssl does. | 16:03 |
| alee | rellerreller, I just submitted a patch that does manipulations for the stored key case using pyopenssl | 16:04 |
| alee | and all code currently written assumes a format like openssl | 16:04 |
| alee | if we do -- whatever openssl does, you get the encrypted case automatically | 16:04 |
| alee | rellerreller, I think that --- I could be wrong here -- openssl is the dominant use case. | 16:05 |
| rellerreller | alee I hear your concern about openssl but I feel like it could limit the sharing. I'm not sure what their encoding is called. They just call it traditional format. It's not that specific. | 16:06 |
| rellerreller | alee I agree that I think openssl and ssh keys are the common use case | 16:06 |
| rellerreller | alee I just don't want to limit other libraries. | 16:07 |
| alee | rellerreller, I understand -- it seems though -- at least looking at the page I pointed out yesterday - that the format is in fact pkcs8? | 16:07 |
| rellerreller | I would hate for some library that needs public/private keys to have to convert to "openssl format." I feel like that adds a weird dependency for them instead of just using pkcs8, which is common and openssl supports | 16:08 |
| rellerreller | alee The format of the openssl keys are not pkcs8 by default. They are in the "traditional" format, whatever that mean. | 16:09 |
| rellerreller | alee I have been parsing the format to learn about them. | 16:09 |
| alee | rellerreller, how do you get openssl to use pkcs8? or is it transparent? | 16:10 |
| rellerreller | alee The openssl traditional format is actually just the private key structure. It is a subset of the PKCS8 structure. It essentially is missing the version number, algorithm ID. | 16:10 |
| alee | rellerreller, so if openssl reads pkcs8, it automatically knows what to do? | 16:10 |
| rellerreller | alee openssl has a command called pkcs8. You use that to convert to and from pkcs8 | 16:11 |
| rellerreller | I actually do not know if openssl would be able to automatically determine the key encoding for use. I would need to run a test for that. | 16:11 |
| alee | rellerreller, yeah - I agree with you in principle - but I'd like to know what openssl does when it receives pkcs8 | 16:12 |
| rellerreller | alee any good ideas on how to test that quickly? | 16:12 |
| alee | given that its the dominant use case. | 16:12 |
| alee | rellerreller, maybe using pyopenssl to read in a private key | 16:13 |
| alee | ? | 16:13 |
| alee | rellerreller, best case is that it reads it automatically | 16:13 |
| rellerreller | alee OK, I'll see if I can run a test real quick today | 16:14 |
| alee | in which case I have no objections | 16:14 |
| alee | woodster_, so -- that constaint will look like .. | 16:14 |
| alee | __table_args = (sa.UniqueConstraint('ca_id', 'key', name = '...') ) ? | 16:15 |
| alee | and ca_id and key should be designated primary keys? | 16:15 |
| alee | woodster_, also I'm confused about your coment on line 884 | 16:16 |
| woodster_ | alee, ok, I'll take a look | 16:18 |
| alee | woodster_, in PreferredCertificateAuthority, project_id must be unique .. why is a constraint necessary? | 16:18 |
| woodster_ | rellerreller, alee, just left comments on the content types bp | 16:18 |
| woodster_ | alee, yeah, you'd have to set key and value to primary keys, and then the constraint would be on 'key' and 'value'...so this is enforcing what the SQLAlchemy mapping collection should enforce, but in the database. I wouldn't add the FK to the constraint though | 16:20 |
| alee | woodster : __table_args = (sa.UniqueConstraint('key', 'value', name = '...') ) ? | 16:22 |
| alee | eh? I'm confused now .. | 16:23 |
| woodster_ | alee, in PreferredCertificateAuthority you have two primary keys defined...I'd remove it from ca_id if you just want the project ID to be primary. An interesting note is that the ModelBase these entities extend, the 'id' is marked as primary too, but doesn't appear to cause issues, though I've read multiple PKs with no constraint could cause sqlalchemy | 16:23 |
| woodster_ | confusion. | 16:23 |
| alee | woodster_, ok will remove primary key from ca_id in PreferredCertificateAuthrotity | 16:24 |
| woodster_ | alee, so if you remove the PK from ca_id, I don't think you need the constraint | 16:24 |
| alee | woodster_, cool -- back to the other constraint though in CertiiftcateAuthority Metadatum | 16:25 |
| alee | what should the constraint be? | 16:25 |
| woodster_ | alee, jaosorior, so Juan is suggesting having a composite key constraint on the key/value pairs in that table I believe, is that correct Juan? | 16:26 |
| woodster_ | alee, jaosorior for a proper mapping, there should never be duplicate key/value records in that table, so the constraint would enforce that in the db | 16:27 |
| alee | woodster_, I thought rellerreller was suggesting constraint on ca_id/key | 16:27 |
| alee | there should never be duplicate records for ca_id/key | 16:28 |
| woodster_ | alee, ah got it, yeah that is the proper one, as multiple ca_id records can store key/values in there, good point | 16:28 |
| alee | so the constraint should be on ca_id and key .. | 16:28 |
| woodster_ | alee, so yes, the PK mark on 'key' and 'ca_id', with a constraint on those two would work then | 16:28 |
| alee | ok - hd me confused for a sec :) | 16:29 |
| alee | will make changes and resubmit momentarily -- I'll tackle any coverage gaps in a subsequent CR | 16:29 |
| woodster_ | alee, sounds good | 16:31 |
| woodster_ | alee, yeah sorry about that! | 16:32 |
| *** paul_glass has joined #openstack-barbican | 16:35 | |
| openstackgerrit | Ade Lee proposed openstack/barbican: Added new model classes for CAs https://review.openstack.org/147323 | 17:02 |
| *** tkelsey has joined #openstack-barbican | 17:05 | |
| woodster_ | rellerreller, I added a comment regarding holding on the content type bp...I think we should still try to land ti | 17:12 |
| woodster_ | alee, the CR LGTM | 17:12 |
| *** kebray has joined #openstack-barbican | 17:12 | |
| *** gyee has joined #openstack-barbican | 17:13 | |
| rellerreller | woodster_ Thanks! I added a comment to your comment. | 17:15 |
| rellerreller | woodster_ I just said that I agreed. | 17:15 |
| woodster_ | rellerreller, alee, jaosorior so it seems like a new version of this could address all the concerns out there, so folks agree though? Are there still open questions folks have? I'd be fine with putting off some of the more controversial types to a future bp if that helps this one land quicker.... | 17:20 |
| woodster_ | tkelsey: ^^^^ forgot to mention you... | 17:20 |
| *** kebray has quit IRC | 17:21 | |
| tkelsey | woodster_: thanks for the ping, looking | 17:21 |
| alee | woodster_, cool thanks. | 17:21 |
| jaosorior | woodster_: a new version of what? | 17:21 |
| alee | jaosorior, rellerreller -- get those +2's out please :) https://review.openstack.org/#/c/147323 | 17:22 |
| woodster_ | jaosorior: the content types bp: https://review.openstack.org/#/c/145073/ | 17:22 |
| alee | woodster_, rellerreller will look again shortly -- in meeting right now .. | 17:22 |
| jaosorior | Will look into them in a bit. I'm on my phone. | 17:23 |
| *** kebray has joined #openstack-barbican | 17:25 | |
| *** atiwari has joined #openstack-barbican | 17:29 | |
| rellerreller | alee I just verified that openssl can use PKCS8 keys without command line modifications. Specifying traditional key or PKCS8 key has some effect. No additional command line options were needed to distinguish between the two. | 17:36 |
| *** lisaclark1 has quit IRC | 18:00 | |
| *** rellerreller has quit IRC | 18:03 | |
| *** openstackgerrit has quit IRC | 18:14 | |
| *** openstackgerrit has joined #openstack-barbican | 18:14 | |
| alee | rellerreller, eh? sorry - I'm a little confused by those two statements ... | 18:31 |
| *** SheenaG1 has quit IRC | 18:32 | |
| *** dimtruck is now known as zz_dimtruck | 19:00 | |
| *** kgriffs is now known as kgriffs|afk | 19:01 | |
| woodster_ | rm_work, alee I added statements to the rbac blueprint (https://review.openstack.org/#/c/127353/) with the aim of fine tuning the desired interaction...please take a look when you can | 19:12 |
| *** tkelsey has quit IRC | 19:17 | |
| alee | woodster_, will do thanks -- I'm drafting a new version right now .. | 19:18 |
| alee | woodster_, please take a look at the other code patches out there for identifying-cas and stored-key-cert-generation when you can | 19:19 |
| *** zz_dimtruck is now known as dimtruck | 19:28 | |
| *** lisaclark1 has joined #openstack-barbican | 19:43 | |
| *** lisaclark1 has quit IRC | 19:45 | |
| *** lisaclark1 has joined #openstack-barbican | 19:47 | |
| woodster_ | alee, will do thanks | 20:00 |
| *** lisaclark1 has quit IRC | 20:01 | |
| *** ametts has quit IRC | 20:02 | |
| *** paul_glass has quit IRC | 20:03 | |
| *** paul_glass has joined #openstack-barbican | 20:05 | |
| *** lisaclark1 has joined #openstack-barbican | 20:08 | |
| *** kgriffs|afk is now known as kgriffs | 20:08 | |
| *** lisaclark1 has quit IRC | 20:08 | |
| *** lisaclark1 has joined #openstack-barbican | 20:09 | |
| *** jaosorior has quit IRC | 20:14 | |
| *** jaosorior has joined #openstack-barbican | 20:53 | |
| *** kebray has quit IRC | 21:02 | |
| openstackgerrit | Juan Antonio Osorio Robles proposed openstack/barbican-specs: Change GET decrypted secrets to unique URI https://review.openstack.org/125798 | 21:04 |
| openstackgerrit | Juan Antonio Osorio Robles proposed openstack/barbican: Remove unnecessary checks from migration commands https://review.openstack.org/150973 | 21:11 |
| jaosorior | rellerreller: ping | 21:11 |
| jaosorior | alee: +2 given | 21:13 |
| alee | jaosorior, awesome thanks | 21:13 |
| jaosorior | by the way, for the rest of the people, would sure use more input on this CR https://review.openstack.org/#/c/150396/ | 21:14 |
| jaosorior | woodster_: What about this bug? https://bugs.launchpad.net/barbican/+bug/1404978 | 21:15 |
| alee | jaosorior, don't forget the other patches in the series :) | 21:16 |
| jaosorior | are you still seeing that error? | 21:16 |
| jaosorior | alee: I won't. But will review them tomorrow morning with proper coffee and everything :P | 21:16 |
| jaosorior | it's 11pm here | 21:16 |
| alee | jaosorior, sure np :) | 21:16 |
| alee | jaosorior, is that directed to me -- "are you still seeing that error?" | 21:17 |
| jaosorior | alee: I did leave some input and poked you a bit about some old CRs | 21:17 |
| jaosorior | no, that "are you still seeing that error?" was directed to woodster_ | 21:17 |
| jaosorior | alee: this one is next in my queue to review tomorrow https://review.openstack.org/#/c/146611/ | 21:18 |
| jaosorior | went ahead and added the rest of the core reviewers for that CR | 21:18 |
| alee | jaosorior, perfect - should be an easy one | 21:18 |
| alee | thanks | 21:18 |
| jaosorior | got time to check this one out? this should be quite straight forward: https://review.openstack.org/#/c/150386/ | 21:20 |
| woodster_ | jaosorior, oh wow, I didn't link that bug fix to the bug :\ It was fixed here: https://github.com/openstack/barbican/commit/81a4dbfd0eecb299c492e33b227acc16b70f9c83 | 21:20 |
| woodster_ | jaosorior, I'll add this to the bug | 21:20 |
| jvrbanac_ | jaosorior, merged | 21:21 |
| jaosorior | woodster_: cool! | 21:21 |
| jaosorior | niiiice, thanks jvrbanac! | 21:21 |
| jaosorior | and yeah, I'm just going through the bug list and trying to keep it clean | 21:21 |
| jaosorior | I still don't know what to do about this one though https://bugs.launchpad.net/barbican/+bug/1365187 | 21:22 |
| jaosorior | and woodster_ I also don't know what's up with this one https://bugs.launchpad.net/barbican/+bug/1373533 :/ | 21:22 |
| *** jvrbanac_ has quit IRC | 21:23 | |
| *** jvrbanac has joined #openstack-barbican | 21:23 | |
| woodster_ | redrobot: ^^^^ | 21:24 |
| jaosorior | on a side note.... http://allanmcrae.com/2015/01/who-you-gonna-call/ awwww yeah | 21:26 |
| woodster_ | nice! | 21:27 |
| jaosorior | But yeah, woodster_, redrobot, jvrbanac if you guys could help out with this one https://review.openstack.org/#/c/150396/ I would sure use more input | 21:28 |
| openstackgerrit | Merged openstack/barbican: Added new model classes for CAs https://review.openstack.org/147323 | 21:31 |
| jaosorior | alee: heads up, you gotta rebase this change dude https://review.openstack.org/#/c/147981/ | 21:33 |
| alee | jaosorior, ah phooey -- ok will do right now - thanks | 21:35 |
| jaosorior | alee: probably the same will happen with the rest of the depending CRs | 21:37 |
| jaosorior | are you using the git-review plugin? | 21:37 |
| jaosorior | it works wonders :P | 21:37 |
| jvrbanac | +2 | 21:41 |
| jaosorior | aaaand I'm off. Have a good day folks! | 21:44 |
| openstackgerrit | Ade Lee proposed openstack/barbican: Add code to populate CA tables and select plugin based on ca_id https://review.openstack.org/150070 | 21:44 |
| openstackgerrit | Ade Lee proposed openstack/barbican: Added new repository classes and controller classes for CAs https://review.openstack.org/147981 | 21:44 |
| woodster_ | jaosorior, take care | 21:51 |
| *** jaosorior has left #openstack-barbican | 21:51 | |
| woodster_ | alee, I added a long winded comment to your CR: https://review.openstack.org/#/c/150670 | 21:51 |
| alee | woodster_, one of my outstanding CR's contains the barbican_metadata structure. I did not use it here because we need that CR to land first | 21:55 |
| woodster_ | alee, oh so that CSR is actually placed into that barbican meta then? And barbican just persists that with the order? | 21:56 |
| alee | woodster_, well - the CR I'm referring to https://review.openstack.org/150070 just adds that parameter to the plugin interface | 21:57 |
| *** lisaclark1 has quit IRC | 21:57 | |
| alee | it doesn't actually store the barbican_metadata | 21:57 |
| alee | I think I need another CR to actually store the barbican_metadata | 21:57 |
| alee | perhaps in another db table? | 21:58 |
| woodster_ | alee, well are you thinking the CSR will eventually go into that barbican_metadata instead of order_meta though? | 21:58 |
| alee | yeah | 21:58 |
| alee | as long as we end up storing it | 21:58 |
| alee | I suggest we take a look at that once these CRs land. | 21:59 |
| alee | I can add a TODO comment in there in the next iteration | 21:59 |
| woodster_ | alee, ok, yes it would need to be stored for sure. It would be used for barbican to keep track of core things during the processing of an order, which might be many days potentially | 21:59 |
| alee | woodster_, yup and the csr is something that will be needed for future operations like renewal | 22:00 |
| alee | woodster_, so I'll put in a comment indicating that we plan to store the csr in the barbican_metadata in a future cr | 22:01 |
| woodster_ | alee, well should the csr be added as an element to the certificate container? | 22:01 |
| *** briancurtin has joined #openstack-barbican | 22:01 | |
| woodster_ | alee, that comment would be good, and then fix the elif and should be good to go | 22:02 |
| alee | woodster_, potentially - though I'm not sure its a good idea | 22:02 |
| alee | cool - will add /change and resubmit now. | 22:02 |
| openstackgerrit | Ade Lee proposed openstack/barbican: Add code to generate a CSR in the stored key case https://review.openstack.org/150670 | 22:09 |
| alee | woodster_, done | 22:09 |
| woodster_ | alee, I see your point actually...it's in a loop there | 22:10 |
| alee | you mean the elif? | 22:10 |
| woodster_ | alee, I was thinking it had to be either private key or passphrase, but your loop thru the secrets one by one | 22:10 |
| alee | it doesn't really matter tbh | 22:10 |
| woodster_ | alee, yep the elif...you had it right, sorry...twice today! | 22:10 |
| alee | woodster_, ok - let me change it back .. | 22:11 |
| woodster_ | alee, well it is slightly more wasteful as both ifs need to be evaluated even if its a private key. I think Juan would tag it too. | 22:11 |
| openstackgerrit | Merged openstack/python-barbicanclient: Drop old namespace for some oslo libraries https://review.openstack.org/150386 | 22:12 |
| *** kebray has joined #openstack-barbican | 22:12 | |
| openstackgerrit | Ade Lee proposed openstack/barbican: Add code to generate a CSR in the stored key case https://review.openstack.org/150670 | 22:13 |
| alee | woodster_, ok changed back :) | 22:14 |
| woodster_ | alee +2 thanks again | 22:15 |
| alee | cool thanks! | 22:15 |
| woodster_ | alee, just a question on https://review.openstack.org/#/c/146611/ | 22:16 |
| alee | woodster_, I'm not sure the question is phrased correctly .. | 22:21 |
| alee | woodster_, let me paste it here .. | 22:22 |
| alee | Could this operation be reattempted in the future, or is it a fatal error? If the latter, then you return a retry ResultDTO, otherwise this exception will mark the order as ERROR and terminate it | 22:22 |
| alee | Do you mean "if the former" ? | 22:22 |
| woodster_ | alee, oh yes, that's correct. Not sure what conditions raise that PKI error, but doesn't seem to be a endpoint connection issue, so probably fatal | 22:23 |
| alee | right - its a catchall exception so probably fatal | 22:24 |
| alee | so rethrowing the exception is correct | 22:24 |
| woodster_ | alee, cool | 22:24 |
| *** lisaclark1 has joined #openstack-barbican | 22:35 | |
| *** lisaclark1 has quit IRC | 22:54 | |
| alee | woodster_, ? | 22:56 |
| *** jorge_munoz has left #openstack-barbican | 22:59 | |
| openstackgerrit | Nathan Reller proposed openstack/barbican-specs: Content Types https://review.openstack.org/145073 | 23:03 |
| *** openstackgerrit has quit IRC | 23:06 | |
| woodster_ | alee: hey | 23:06 |
| *** openstackgerrit has joined #openstack-barbican | 23:06 | |
| alee | woodster_, hey -- just commenting on the per-spec thing to make sure I caught what everyone agreed on | 23:07 |
| alee | woodster_, just wondering -- what did we decide on "list"? | 23:07 |
| alee | woodster_, are we deciding to defer it to L+? and just focus on "read"? | 23:08 |
| alee | woodster_, admittedly "list" is not well defined .. | 23:09 |
| alee | woodster_, or is "list" == "read" ie. you should only be able to get metadata for the secrets you can get | 23:10 |
| woodster_ | alee: I recall this first effort was for GETting secret metadata and decrypt only...all other operations would function as they do now, with current roles | 23:10 |
| woodster_ | alee: I think that limits scope but you could still mention other stuff considered in the future | 23:11 |
| alee | woodster_, would you consider getting metadata and getting secrets separate operations ? | 23:12 |
| alee | ie. "list" and "read" | 23:12 |
| alee | we could rename these "get-metadata" and "get-secret" to make it clearer? | 23:13 |
| rm_work | yeah it seemed very ambiguous to me as they were origianally worded | 23:14 |
| rm_work | because none were actually referring to the LIST endpoint | 23:14 |
| rm_work | *originally | 23:14 |
| alee | "get-secret", "get-metadata", "write-secret", "change-secret-acl" | 23:14 |
| woodster_ | alee: yes, different operations | 23:14 |
| alee | "delete-secret" | 23:14 |
| alee | woodster_, ok and we want to support "get-secret" and "get-metadata" for K | 23:15 |
| alee | woodster_, rm_work - ok for renamed operations? | 23:15 |
| *** bdpayne_ has quit IRC | 23:15 | |
| rm_work | I think that's right | 23:16 |
| rm_work | we were EVER going to allow people to write-secret on another person's project? | 23:16 |
| rm_work | secrets are immutable, so it wouldn't mean anything with regard to a specific secret... | 23:16 |
| alee | rm_work, true -- but thats why its L+ :) | 23:17 |
| rm_work | hmmm | 23:17 |
| alee | rm_work, most likely we would not -- but this also applies to containers .. | 23:17 |
| *** paul_glass has quit IRC | 23:18 | |
| rm_work | containers are also immutable tho... | 23:18 |
| alee | rm_work, well - what happens when you want to renew a cert? | 23:18 |
| woodster_ | rm_work only typed containers are immutable I recall | 23:18 |
| woodster_ | alee, renewals/reissues are new containers | 23:18 |
| alee | woodster_, ok | 23:19 |
| woodster_ | alee trying to understand the 'get-xxxx' notation there | 23:19 |
| woodster_ | alee you mean on the acl table | 23:20 |
| alee | woodster_, right -- so given that this applies to containers too .. | 23:20 |
| woodster_ | ? | 23:20 |
| rm_work | woodster_: uhh, pretty sure ALL containers are immutable, no? | 23:20 |
| alee | I mean for a particular secret, we may have an acl that looks like this .. | 23:20 |
| alee | { | 23:21 |
| alee | "get-secret": { | 23:21 |
| alee | "user_ids": ["some_user_id", | 23:21 |
| alee | "another_user_id"], | 23:21 |
| alee | "group_ids": ["some_group_id"], | 23:21 |
| alee | "allowed_project": [""], | 23:21 |
| alee | "get-metadata": { ... }, | 23:21 |
| alee | "write-secret": { ... }, | 23:21 |
| alee | } | 23:21 |
| rm_work | yeah, so what is the purpose of write-secret <_< | 23:21 |
| woodster_ | rm_work, they shouldn't be, as a container might be used to just group secrets, and that list can change over time. That was the original intent anyway...they could very well be immutable the way implemented though. Only typed containers need to conceptually be unchanged by clients | 23:21 |
| alee | (seeing as ya'll like the json formulation better .. | 23:21 |
| rm_work | if it's a shared two-stage in stage 1? | 23:21 |
| rm_work | woodster_: as coded now I believe they are 100% immutable | 23:22 |
| rm_work | woodster_: and AFAIK that was always the design | 23:22 |
| rm_work | I think I agree that there's not a great reason generic containers couldn't be mutable | 23:22 |
| rm_work | but I also feel like if we brought it up, someone would probably convince me otherwise | 23:23 |
| woodster_ | alee so 'get-secret' is decyrpted gets correct? Would it be sufficient to just have 'get-secret' to mean either get metadata or decrypted? | 23:23 |
| rm_work | ehhh | 23:23 |
| alee | woodster_, rm_work it may very well be that there is never going to be a reason for write_secret -- or write_container. Either way, we won't sweat it till the need arises. | 23:23 |
| rm_work | might want them to be separate? dunno | 23:23 |
| woodster_ | alee ...and for this bp only the 'get-secret' would be implemented | 23:23 |
| alee | woodster_, right - thats what I asked you .. do you want to treat the operations separately? | 23:24 |
| woodster_ | just trying to understand a use case where I can just see metadata but not decrypt it...maybe an auditor whitelist thing I guess. | 23:25 |
| woodster_ | alee I thought you meant list vs get | 23:25 |
| alee | woodster_, thats what I meant | 23:25 |
| alee | for me -- list == get metadata | 23:25 |
| alee | but maybe not for you ? | 23:26 |
| alee | I guess they are not the same .. | 23:26 |
| rm_work | yeah that is why i said it was ambiguously worded | 23:26 |
| rm_work | it makes sense to me for there to be two different roles | 23:26 |
| rm_work | read-meta and read-payload | 23:26 |
| alee | GET /secrets will give me a bunch of links to secrets | 23:26 |
| alee | thats one definition of list | 23:27 |
| rm_work | yeah THAT is LIST | 23:27 |
| rm_work | the thing people are calling "list" in that BP is more like get-meta | 23:27 |
| alee | GET /secret/foo gives me metadata | 23:27 |
| alee | rm_work, yeah - thats my fault :) | 23:27 |
| woodster_ | alee, maybe for now just have 'get-decrypted' and 'get-metadata' for this bp then? | 23:27 |
| alee | GET /secret/foo/payload gives me payload | 23:28 |
| rm_work | maybe avoiding the term 'secret' altogether is the best plan -- also because as you said, it would apply to containers, and that would be confusing | 23:28 |
| rm_work | so read-meta read-payload | 23:28 |
| rm_work | or get-meta get-payload | 23:28 |
| rm_work | whatever | 23:28 |
| alee | woodster_, I actually think we should do list --> whch is what you'd get by doing GET /secrets | 23:28 |
| alee | and "get" - which should be for metadata and payload | 23:29 |
| rm_work | alee: well, how would that apply to a secret exactly? | 23:29 |
| woodster_ | I'm thinking get-decrypted is most direct...get-payload would work but would need to be described briefly...no biggy | 23:29 |
| rm_work | you give someone the 'list' role on a secret | 23:29 |
| rm_work | does that mean it shows up in their secret list? | 23:29 |
| rm_work | if so, I think we decided we weren't ever going to allow that to happen anyway, so it's kinda moot | 23:29 |
| woodster_ | I think GET /secrets is a different action altogether...covered by current operation only, not touched by this bp. | 23:30 |
| *** kebray has quit IRC | 23:30 | |
| alee | ok - no list then .. | 23:30 |
| alee | that makes things easier | 23:30 |
| woodster_ | yeah, trying to get a list of my whitelisted secrets would not be performant I think, and not needed IMHO | 23:30 |
| rm_work | alee: I think the current thought is that allowing shared secrets to show up in a GET list is a bad idea from a security perspective, in the same way keystone has no method of enumerating Trusts | 23:30 |
| alee | rm_work, sure I can appreciate that | 23:31 |
| woodster_ | that too! | 23:31 |
| rm_work | maybe I am being overly paranoid | 23:31 |
| rm_work | but Barbican is for security, and paranoia is good in security :P | 23:31 |
| *** kebray has joined #openstack-barbican | 23:31 | |
| woodster_ | my angle on this is start small scope and consider other needs later. This gets us the LBaaS use case and probably cinder/nova encryption too, correct? | 23:32 |
| rm_work | I believe so | 23:32 |
| alee | woodster_, rm_work - we could also argue that you should not be able to get metadata on a secret without decrypted. | 23:32 |
| alee | and just have one "get" operation | 23:32 |
| rm_work | so, for the initial work (K release) I'd assume just the get operation | 23:32 |
| rm_work | and ... fff | 23:32 |
| rm_work | i dunno | 23:32 |
| rm_work | my gut feeling is that having them separate makes sense | 23:33 |
| rm_work | but also that it'd be annoying to do | 23:33 |
| rm_work | and it'd really mess with the client | 23:33 |
| rm_work | (if you could get the payload for something but not the meta) | 23:33 |
| rm_work | the client would need some changes | 23:33 |
| alee | rm_work, right -- that does not make sense | 23:33 |
| alee | rm_work, the client willneed changes in any case | 23:33 |
| rm_work | heh, true | 23:33 |
| woodster_ | well, I'm curious if there is a valid audit use case...I can see a secret is in barbican, just not allowed to decrypt it | 23:34 |
| rm_work | also, "would really mess with the client" is not a great reason to [not] do something | 23:34 |
| rm_work | woodster_: yeah I would assume that is a more valid scenario | 23:34 |
| rm_work | so maybe we could say that one is a superset of the other? | 23:34 |
| rm_work | get-meta is meta-only, and get-secret is the whole shebang? | 23:35 |
| rm_work | or rather... hmmm | 23:35 |
| rm_work | "get" vs. "get-meta-only" | 23:35 |
| rm_work | I shy away from "get-secret" still because applying that to a container is dumb | 23:35 |
| woodster_ | sooo....what about containers then? If I'm whitelisted on a container, but some of the secrets are not so whitelisted, do I not get to see them in the container metadata? Gets on the individual secrets would still work as defined. | 23:36 |
| alee | rm_work, woodster_ well maybe we need to just acknowledge that containers are different and just have "get-container"? | 23:36 |
| alee | a container is all metadata in any case | 23:37 |
| woodster_ | oy, that policy file/logic is getting gnarly dudes! | 23:37 |
| woodster_ | does setting a user on a container whitelist get cascaded down to the secrets too? :) | 23:37 |
| woodster_ | ...I'd suggest no | 23:38 |
| woodster_ | ...esp. for bp #1 | 23:38 |
| alee | woodster_, me too | 23:38 |
| alee | I think you need to set perm on the secret explicitly | 23:38 |
| woodster_ | what about just a simple 'get' for now, and that means full access. If we decide we need to fine grain that access, we can add 'get-meta' and 'get-payload' later, correct? | 23:39 |
| alee | yup - we could do that .. | 23:40 |
| alee | so "get" to be implemented first | 23:40 |
| woodster_ | simple == more better | 23:40 |
| alee | and later , "delete", "change-acl", "write" (maybe) | 23:41 |
| alee | ok cool - thats what I'm writin' | 23:41 |
| woodster_ | yep, I'll add to the L discussion etherpad out here: https://etherpad.openstack.org/p/barbican-L-design-sessions | 23:41 |
| alee | woodster_, cool I have stuff to add to that too shortly | 23:42 |
| woodster_ | alee soudns good! | 23:43 |
| rm_work | ugh i am distracted for a sec, will try to come back and read this in a few | 23:44 |
| alee | ok being attacked by munchkin -- dinner time | 23:44 |
| woodster_ | rm_work one thousand and one... | 23:44 |
| *** alee is now known as alee_dinner | 23:44 | |
| rm_work | yeah just "get" for now is fine | 23:51 |
| rm_work | we can add the others later | 23:51 |
| rm_work | and I was also wondering what would happen about a container... right now it'd be fine because really the container just has secret_refs so at least getting the container would get those -- it wouldn't break the current client workflow at all | 23:52 |
| rm_work | but it would be kinda useless | 23:52 |
| rm_work | possibly later we could look into "get-container" cascades "get-meta-only" onto secrets or something, but whatever | 23:52 |
| woodster_ | rm_work, yeah agreed | 23:56 |
| woodster_ | I'm heading out too, take care rm_work | 23:58 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!