Wednesday, 2015-01-28

*** ametts has quit IRC00:06
*** crc32 has joined #openstack-barbican00:24
greghaynesI 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_afk00:33
greghaynesmaybe we should by default be specifying the default domain id00:36
greghaynessince it appears to not be optional00:36
greghaynesmorganfainberg: ^00:37
morganfainbergi swear i'm not lurking in your channel here00:37
greghaynesheh, *my* channel? ;)00:37
greghaynesso yea, looks like domain is required for /v3/auth/tokens?00:38
morganfainbergare you authing with username?00:38
morganfainbergor user id?00:38
greghayneskeystone docs says this isnt true, the error message im getting says otherwise00:38
morganfainbergwith username, yes domain is required00:38
morganfainberguser_id should not be00:38
morganfainbergusernames are not unique across keystone, only unique within a domain00:38
greghaynes{"auth": {"identity": {"password": {"user": {"domain": {"id": "default"}, "password": "unset", "name": "admin"}}, "methods": ["password"]}}}00:38
greghaynesah, ok00:38
morganfainbergsee easy answer00:39
greghaynesmorganfainberg: any reason the keystoneclient doesnt default to domain "default"?00:39
greghaynesor keystone server just assume that?00:39
morganfainberghow does the client know you mean default domain?00:39
morganfainberghow 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
morganfainbergdefault domain is a special construct for v2->v3 compat00:40
morganfainbergit just is where we stick people / things that are made via the v2 api00:41
morganfainbergit' should probably be named "v2_compat_domain" not "Default", but i think we'd get more questions that way00:41
greghaynesaha! so you just dont want there to actually be a default really00:41
greghaynesjust also to not break the world00:42
*** nkinder has joined #openstack-barbican00:46
*** atiwari2 has quit IRC00:47
*** jkf has quit IRC00:47
greghaynesmorganfainberg: 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 situation00:48
greghaynesmorganfainberg: any idea if theres a plan / spec / similar on what clients should be doing?00:48
morganfainbergjamielennox, ^00:48
* morganfainberg summons the person who has the most information on this,00:48
greghaynesawesome :)00:48
morganfainbergbut there is some work we've been pushing, nothing formal00:49
morganfainbergjamielennox, version disc stuff00:49
*** atiwari2 has joined #openstack-barbican00:49
morganfainbergjust the last question00:49
jamielennoxmore domain discovery00:49
jamielennoxoh - not that bit00:49
greghaynesyea, just version discovery00:49
jamielennoxgreghaynes: the barbican URL in the servcie catalog is unversioned right?00:49
jamielennoxi did a bunch of things for barbican00:50
*** kgriffs is now known as kgriffs|afk00:50
greghaynesIm not even to service catalog yet, we just set OS_AUTH_URL in tripleo00:50
jamielennoxok so OS_AUTH_URL is keystone - where you send the auth request to00:51
greghaynes(I am also just learning about keystoneish stuff so feel free to tell me im way off ;))00:51
jamielennoxas part of the auth response you get a service catalog, and in that there is an entry for barbican00:51
jamielennoxthe barbican client takes that value out of the service catalog and that's what it uses to talk to the barbican server00:52
greghaynesyep, 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 errors00:52
jamielennoxah this is the CLI00:52
jamielennoxlet me have a look00:53
jamielennoxok so the cli is taking an args.endpoint as well as the OS_AUTH_URL00:55
jamielennoxoh, optionally00:55
greghayneshrm, so I wonder if we should just not be specifying v2 in our OS_AUTH_URL?00:56
jamielennoxit looks like it's doing the right thing00:56
greghaynes(this is for tripleo)00:56
jamielennoxsort of00:56
jamielennoxyou can set os-identity-api-version to 2 to use v2 auth00:57
jamielennoxit just defaults to v3 auth00:58
greghaynesaha, ty01:00
greghaynesIt does seem like version disc works if I just set to auth-url to /... I wonder how many of the other clients work with that01:01
jamielennoxgreghaynes: they all have a bad habit of doing there own thing01:05
jamielennoxhowever 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
greghaynesyea, and we run all of them, and I bet /v2 is just the least common denomonator01:06
* greghaynes might try and see how mant things break if we just dont specify a version though01:07
*** dimtruck is now known as zz_dimtruck01:16
*** bdpayne_ has quit IRC01:46
*** atiwari2 has quit IRC01:57
greghaynesredrobot: You see the ML reply from sdague?01:59
greghaynesredrobot: and
*** kebray has quit IRC02:00
greghaynesfun times02:04
*** bdpayne has joined #openstack-barbican02:17
*** alpha_ori has quit IRC02:21
*** alee has joined #openstack-barbican02:26
*** alpha_ori has joined #openstack-barbican02:33
redrobotgreghaynes 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
greghayneswell, the first thing is probably adding the stable job02:34
greghaynesso we could know before releasing :)02:35
greghaynesI am also unclear on what the correct fix is, though02:37
* greghaynes asks some people who are smarter than I02:37
*** kebray has joined #openstack-barbican02:39
greghaynesredrobot: 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.002:47
greghaynesbasically, clients + stable branches = pain so test and expect things to break is what ive been told :)02:48
redrobotgreghaynes haha, yeah, definitely been feeling the pain lately :)02:49
*** crc32 has quit IRC03:16
openstackgerritAde Lee proposed openstack/barbican: Add code to generate a CSR in the stored key case
openstackgerritAde Lee proposed openstack/barbican: Add support for simple cmc requests to Dogtag plugin
*** woodster_ has quit IRC04:13
*** zz_dimtruck is now known as dimtruck04:35
*** Nirupama has joined #openstack-barbican05:33
*** kebray has quit IRC05:33
*** dimtruck has quit IRC05:39
*** dimtruck has joined #openstack-barbican05:39
*** chellygel has quit IRC05:39
*** insequent has quit IRC05:39
*** chellygel has joined #openstack-barbican05:39
*** alee has quit IRC05:40
*** alee has joined #openstack-barbican05:40
*** insequent has joined #openstack-barbican05:46
*** kebray has joined #openstack-barbican05:48
*** woodster_ has joined #openstack-barbican06:11
*** kebray has quit IRC07:22
*** jaosorior has joined #openstack-barbican07:35
*** jamielennox is now known as jamielennox|away08:09
*** woodster_ has quit IRC08:23
*** bdpayne has quit IRC08:40
*** bdpayne has joined #openstack-barbican08:45
*** bdpayne has quit IRC09:15
*** openstackgerrit has quit IRC10:50
*** openstackgerrit has joined #openstack-barbican10:50
openstackgerritJuan Antonio Osorio Robles proposed openstack/barbican: Handle SystemExit properly in migration script
*** rm_you| has quit IRC11:49
*** rm_you| has joined #openstack-barbican11:49
openstackgerritJuan Antonio Osorio Robles proposed openstack/barbican: Handle SystemExit properly in migration script
openstackgerritJuan Antonio Osorio Robles proposed openstack/barbican: Add 'history' option to the migration script
openstackgerritJuan Antonio Osorio Robles proposed openstack/barbican: Add 'history' option to the migration script
*** woodster_ has joined #openstack-barbican12:45
*** Nirupama has quit IRC13:29
*** darrenmoffat has quit IRC13:42
*** darrenmoffat has joined #openstack-barbican13:43
openstackgerritTim Kelsey proposed openstack/barbican-specs: Adding spec for Barbican MKEK Model.
*** rellerreller has joined #openstack-barbican13:47
*** SheenaG1 has joined #openstack-barbican14:04
*** lisaclark1 has joined #openstack-barbican14:27
*** dimtruck is now known as zz_dimtruck14:39
jaosoriorwoodster_: ping14:40
openstackgerritJuan Antonio Osorio Robles proposed openstack/barbican: Add 'history' option to the migration script
openstackgerritJuan Antonio Osorio Robles proposed openstack/barbican: Add 'current' option to the migration script
*** lisaclark1 has quit IRC15:10
*** bdpayne has joined #openstack-barbican15:11
*** zz_dimtruck is now known as dimtruck15:12
*** lisaclark1 has joined #openstack-barbican15:13
*** kgriffs|afk is now known as kgriffs15:19
*** bdpayne_ has joined #openstack-barbican15:24
*** bdpayne has quit IRC15:28
*** kebray has joined #openstack-barbican15:29
jaosorioror... is anybody familiar with alembic?15:32
*** kebray has quit IRC15:36
*** tkelsey has joined #openstack-barbican15:42
*** woodster_ has quit IRC15:43
*** woodster_ has joined #openstack-barbican15:49
*** ametts has joined #openstack-barbican15:49
openstackgerritAde Lee proposed openstack/barbican: Add code to generate a CSR in the stored key case
aleewoodster_, ping15:54
woodster_alee, morning15:57
aleewoodster_, morning  -- I've put up a few patches for review :)15:58
aleewoodster_, but I wanted to ask frst about the identify-ca models patch ..15:58
aleeso that I make sure to address the comments correctly15:58
*** tkelsey has quit IRC15:59
aleewoodster_, specifically
aleewoodster_, line 801 -- do you think a constraint is needed?16:00
rellerrellerwoodster_ 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?:
rellerrellerI 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-lyle16:01
aleewoodster_, 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 it16:02
rellerrellerPlus I think with the containers passphrase for keys and the transport keys may be using different specs16:02
woodster_rellerreller, let me take a look real quick16:03
aleerellerreller, 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
aleerellerreller, I just submitted a patch that does manipulations for the stored key case using pyopenssl16:04
aleeand all code currently written assumes a format like openssl16:04
aleeif we do -- whatever openssl does, you get the encrypted case automatically16:04
aleerellerreller, I think that --- I could be wrong here -- openssl is the dominant use case.16:05
rellerrelleralee 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
rellerrelleralee I agree that I think openssl and ssh keys are the common use case16:06
rellerrelleralee I just don't want to limit other libraries.16:07
aleerellerreller, I understand -- it seems though -- at least looking at the page I pointed out yesterday - that the format is in fact pkcs8?16:07
rellerrellerI 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 supports16:08
rellerrelleralee The format of the openssl keys are not pkcs8 by default. They are in the "traditional" format, whatever that mean.16:09
rellerrelleralee I have been parsing the format to learn about them.16:09
aleerellerreller, how do you get openssl to use pkcs8?  or is it transparent?16:10
rellerrelleralee 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
aleerellerreller, so if openssl reads pkcs8, it automatically knows what to do?16:10
rellerrelleralee openssl has a command called pkcs8. You use that to convert to and from pkcs816:11
rellerrellerI 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
aleerellerreller, yeah - I agree with you in principle - but I'd like to know what openssl does when it receives pkcs816:12
rellerrelleralee any good ideas on how to test that quickly?16:12
aleegiven that its the dominant use case.16:12
aleerellerreller, maybe using pyopenssl to read in a private key16:13
aleerellerreller, best case is that it reads it automatically16:13
rellerrelleralee OK, I'll see if I can run a test real quick today16:14
aleein which case I have no objections16:14
aleewoodster_, so -- that constaint will look like ..16:14
alee__table_args = (sa.UniqueConstraint('ca_id', 'key', name = '...') ) ?16:15
aleeand ca_id and key should be designated primary keys?16:15
aleewoodster_, also I'm confused about your coment on line 88416:16
woodster_alee, ok, I'll take a look16:18
aleewoodster_, in PreferredCertificateAuthority, project_id must be unique .. why is a constraint necessary?16:18
woodster_rellerreller, alee, just left comments on the content types bp16: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' this is enforcing what the SQLAlchemy mapping collection should enforce, but in the database. I wouldn't add the FK to the constraint though16:20
aleewoodster : __table_args = (sa.UniqueConstraint('key', 'value', name = '...') ) ?16:22
aleeeh?  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 sqlalchemy16:23
aleewoodster_, ok will remove primary key from ca_id in PreferredCertificateAuthrotity16:24
woodster_alee, so if you remove the PK from ca_id, I don't think you need the constraint16:24
aleewoodster_, cool -- back to the other constraint though in CertiiftcateAuthority Metadatum16:25
aleewhat 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 db16:27
aleewoodster_, I thought rellerreller was suggesting constraint on ca_id/key16:27
aleethere should never be duplicate records for ca_id/key16:28
woodster_alee, ah got it, yeah that is the proper one, as multiple ca_id records can store key/values in there, good point16:28
aleeso 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 then16:28
aleeok - hd me confused for a sec :)16:29
aleewill make changes and resubmit momentarily -- I'll tackle any coverage gaps in a subsequent CR16:29
woodster_alee, sounds good16:31
woodster_alee, yeah sorry about that!16:32
*** paul_glass has joined #openstack-barbican16:35
openstackgerritAde Lee proposed openstack/barbican: Added new model classes for CAs
*** tkelsey has joined #openstack-barbican17:05
woodster_rellerreller, I added a comment regarding holding on the content type bp...I think we should still try to land ti17:12
woodster_alee, the CR LGTM17:12
*** kebray has joined #openstack-barbican17:12
*** gyee has joined #openstack-barbican17:13
rellerrellerwoodster_ Thanks! I added a comment to your comment.17:15
rellerrellerwoodster_ 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 IRC17:21
tkelseywoodster_: thanks for the ping, looking17:21
aleewoodster_, cool thanks.17:21
jaosoriorwoodster_: a new version of what?17:21
aleejaosorior, rellerreller -- get those +2's out please :)
woodster_jaosorior: the content types bp:
aleewoodster_, rellerreller will look again shortly -- in meeting right now ..17:22
jaosoriorWill look into them in a bit. I'm on my phone.17:23
*** kebray has joined #openstack-barbican17:25
*** atiwari has joined #openstack-barbican17:29
rellerrelleralee 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 IRC18:00
*** rellerreller has quit IRC18:03
*** openstackgerrit has quit IRC18:14
*** openstackgerrit has joined #openstack-barbican18:14
aleerellerreller, eh?  sorry - I'm a little confused by those two statements ...18:31
*** SheenaG1 has quit IRC18:32
*** dimtruck is now known as zz_dimtruck19:00
*** kgriffs is now known as kgriffs|afk19:01
woodster_rm_work, alee I added statements to the rbac blueprint ( with the aim of fine tuning the desired interaction...please take a look when you can19:12
*** tkelsey has quit IRC19:17
aleewoodster_, will do thanks -- I'm drafting a new version right now ..19:18
aleewoodster_, please take a look at the other code patches out there for identifying-cas and stored-key-cert-generation when you can19:19
*** zz_dimtruck is now known as dimtruck19:28
*** lisaclark1 has joined #openstack-barbican19:43
*** lisaclark1 has quit IRC19:45
*** lisaclark1 has joined #openstack-barbican19:47
woodster_alee, will do thanks20:00
*** lisaclark1 has quit IRC20:01
*** ametts has quit IRC20:02
*** paul_glass has quit IRC20:03
*** paul_glass has joined #openstack-barbican20:05
*** lisaclark1 has joined #openstack-barbican20:08
*** kgriffs|afk is now known as kgriffs20:08
*** lisaclark1 has quit IRC20:08
*** lisaclark1 has joined #openstack-barbican20:09
*** jaosorior has quit IRC20:14
*** jaosorior has joined #openstack-barbican20:53
*** kebray has quit IRC21:02
openstackgerritJuan Antonio Osorio Robles proposed openstack/barbican-specs: Change GET decrypted secrets to unique URI
openstackgerritJuan Antonio Osorio Robles proposed openstack/barbican: Remove unnecessary checks from migration commands
jaosoriorrellerreller: ping21:11
jaosorioralee: +2 given21:13
aleejaosorior, awesome thanks21:13
jaosoriorby the way, for the rest of the people, would sure use more input on this CR
jaosoriorwoodster_: What about this bug?
aleejaosorior, don't forget the other patches in the series :)21:16
jaosoriorare you still seeing that error?21:16
jaosorioralee: I won't. But will review them tomorrow morning with proper coffee and everything :P21:16
jaosoriorit's 11pm here21:16
aleejaosorior, sure np :)21:16
aleejaosorior, is that directed to me -- "are you still seeing that error?"21:17
jaosorioralee: I did leave some input and poked you a bit about some old CRs21:17
jaosoriorno, that "are you still seeing that error?" was directed to woodster_21:17
jaosorioralee: this one is next in my queue to review tomorrow
jaosoriorwent ahead and added the rest of the core reviewers for that CR21:18
aleejaosorior, perfect - should be an easy one21:18
jaosoriorgot time to check this one out? this should be quite straight forward:
woodster_jaosorior, oh wow, I didn't link that bug fix to the bug :\  It was fixed here:
woodster_jaosorior, I'll add this to the bug21:20
jvrbanac_jaosorior, merged21:21
jaosoriorwoodster_: cool!21:21
jaosoriorniiiice, thanks jvrbanac!21:21
jaosoriorand yeah, I'm just going through the bug list and trying to keep it clean21:21
jaosoriorI still don't know what to do about this one though
jaosoriorand woodster_ I also don't know what's up with this one  :/21:22
*** jvrbanac_ has quit IRC21:23
*** jvrbanac has joined #openstack-barbican21:23
woodster_redrobot: ^^^^21:24
jaosorioron a side note.... awwww yeah21:26
jaosoriorBut yeah, woodster_, redrobot, jvrbanac if you guys could help out with this one I would sure use more input21:28
openstackgerritMerged openstack/barbican: Added new model classes for CAs
jaosorioralee: heads up, you gotta rebase this change dude
aleejaosorior, ah phooey -- ok will do right now - thanks21:35
jaosorioralee: probably the same will happen with the rest of the depending CRs21:37
jaosoriorare you using the git-review plugin?21:37
jaosoriorit works wonders :P21:37
jaosorioraaaand I'm off. Have a good day folks!21:44
openstackgerritAde Lee proposed openstack/barbican: Add code to populate CA tables and select plugin based on ca_id
openstackgerritAde Lee proposed openstack/barbican: Added new repository classes and controller classes for CAs
woodster_jaosorior, take care21:51
*** jaosorior has left #openstack-barbican21:51
woodster_alee, I added a long winded comment to your CR:
aleewoodster_, one of my outstanding CR's contains the barbican_metadata structure.  I did not use it here because we need that CR to land first21: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
aleewoodster_,  well - the CR I'm referring to just adds that parameter to the plugin interface21:57
*** lisaclark1 has quit IRC21:57
aleeit doesn't actually store the barbican_metadata21:57
aleeI think I need another CR to actually store the barbican_metadata21:57
aleeperhaps 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
aleeas long as we end up storing it21:58
aleeI suggest we take a look at that once these CRs land.21:59
aleeI can add a TODO comment in there in the next iteration21: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 potentially21:59
aleewoodster_, yup and the csr is something that will be needed for future operations like renewal22:00
aleewoodster_, so I'll put in a comment indicating that we plan to store the csr in the barbican_metadata in a future cr22:01
woodster_alee, well should the csr be added as an element to the certificate container?22:01
*** briancurtin has joined #openstack-barbican22:01
woodster_alee, that comment would be good, and then fix the elif and should be good to go22:02
aleewoodster_, potentially - though I'm not sure its a good idea22:02
aleecool - will add /change and resubmit now.22:02
openstackgerritAde Lee proposed openstack/barbican: Add code to generate a CSR in the stored key case
aleewoodster_, done22:09
woodster_alee, I see your point's in a loop there22:10
aleeyou 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 one22:10
aleeit doesn't really matter tbh22:10
woodster_alee, yep the had it right, sorry...twice today!22:10
aleewoodster_, 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
openstackgerritMerged openstack/python-barbicanclient: Drop old namespace for some oslo libraries
*** kebray has joined #openstack-barbican22:12
openstackgerritAde Lee proposed openstack/barbican: Add code to generate a CSR in the stored key case
aleewoodster_, ok changed back :)22:14
woodster_alee +2 thanks again22:15
aleecool thanks!22:15
woodster_alee, just a question on
aleewoodster_, I'm not sure the question is phrased correctly ..22:21
aleewoodster_, let me paste it here ..22:22
aleeCould 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 it22:22
aleeDo 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 fatal22:23
aleeright - its a catchall exception so probably fatal22:24
aleeso rethrowing the exception is correct22:24
woodster_alee, cool22:24
*** lisaclark1 has joined #openstack-barbican22:35
*** lisaclark1 has quit IRC22:54
aleewoodster_, ?22:56
*** jorge_munoz has left #openstack-barbican22:59
openstackgerritNathan Reller proposed openstack/barbican-specs: Content Types
*** openstackgerrit has quit IRC23:06
woodster_alee: hey23:06
*** openstackgerrit has joined #openstack-barbican23:06
aleewoodster_, hey -- just commenting on the per-spec thing to make sure I caught what everyone agreed on23:07
aleewoodster_, just wondering -- what did we decide on "list"?23:07
aleewoodster_, are we deciding to defer it to L+? and just focus on "read"?23:08
aleewoodster_, admittedly "list" is not well defined ..23:09
aleewoodster_, or is "list" == "read" ie. you should only be able to get metadata for the secrets you can get23: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 roles23:10
woodster_alee: I think that limits scope but you could still mention other stuff considered in the future23:11
aleewoodster_, would you consider getting metadata and getting secrets separate operations ?23:12
aleeie. "list" and "read"23:12
aleewe could rename these "get-metadata" and "get-secret" to make it clearer?23:13
rm_workyeah it seemed very ambiguous to me as they were origianally worded23:14
rm_workbecause none were actually referring to the LIST endpoint23:14
alee"get-secret", "get-metadata", "write-secret", "change-secret-acl"23:14
woodster_alee: yes, different operations23:14
aleewoodster_, ok and we want to support "get-secret" and "get-metadata" for K23:15
aleewoodster_, rm_work - ok for renamed operations?23:15
*** bdpayne_ has quit IRC23:15
rm_workI think that's right23:16
rm_workwe were EVER going to allow people to write-secret on another person's project?23:16
rm_worksecrets are immutable, so it wouldn't mean anything with regard to a specific secret...23:16
aleerm_work, true -- but thats why its L+ :)23:17
aleerm_work, most likely we would not -- but this also applies to containers ..23:17
*** paul_glass has quit IRC23:18
rm_workcontainers are also immutable tho...23:18
aleerm_work, well - what happens when you want to renew a cert?23:18
woodster_rm_work only typed containers are immutable I recall23:18
woodster_alee, renewals/reissues are new containers23:18
aleewoodster_, ok23:19
woodster_alee trying to understand the 'get-xxxx' notation there23:19
woodster_alee you mean on the acl table23:20
aleewoodster_, right -- so given that this applies to containers too ..23:20
rm_workwoodster_: uhh, pretty sure ALL containers are immutable, no?23:20
aleeI mean for a particular secret, we may have an acl that looks like this ..23:20
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
rm_workyeah, 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 clients23:21
alee(seeing as ya'll like the json formulation better ..23:21
rm_workif it's a shared two-stage in stage 1?23:21
rm_workwoodster_: as coded now I believe they are 100% immutable23:22
rm_workwoodster_: and AFAIK that was always the design23:22
rm_workI think I agree that there's not a great reason generic containers couldn't be mutable23:22
rm_workbut I also feel like if we brought it up, someone would probably convince me otherwise23: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
aleewoodster_, 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_workmight want them to be separate? dunno23:23
woodster_alee ...and for this bp only the 'get-secret' would be implemented23:23
aleewoodster_, 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 get23:25
aleewoodster_, thats what I meant23:25
aleefor me -- list == get metadata23:25
aleebut maybe not for you ?23:26
aleeI guess they are not the same ..23:26
rm_workyeah that is why i said it was ambiguously worded23:26
rm_workit makes sense to me for there to be two different roles23:26
rm_workread-meta and read-payload23:26
aleeGET /secrets will give me a bunch of links to secrets23:26
aleethats one definition of list23:27
rm_workyeah THAT is LIST23:27
rm_workthe thing people are calling "list" in that BP is more like get-meta23:27
aleeGET /secret/foo gives me metadata23:27
aleerm_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
aleeGET /secret/foo/payload gives me payload23:28
rm_workmaybe avoiding the term 'secret' altogether is the best plan -- also because as you said, it would apply to containers, and that would be confusing23:28
rm_workso read-meta read-payload23:28
rm_workor get-meta get-payload23:28
aleewoodster_, I actually think we should do list  --> whch is what you'd get by doing GET /secrets23:28
aleeand "get" - which should be for metadata and payload23:29
rm_workalee: 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 biggy23:29
rm_workyou give someone the 'list' role on a secret23:29
rm_workdoes that mean it shows up in their secret list?23:29
rm_workif so, I think we decided we weren't ever going to allow that to happen anyway, so it's kinda moot23: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 IRC23:30
aleeok - no list then ..23:30
aleethat makes things easier23:30
woodster_yeah, trying to get a list of my whitelisted secrets would not be performant I think, and not needed IMHO23:30
rm_workalee: 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 Trusts23:30
aleerm_work, sure I can appreciate that23:31
woodster_that too!23:31
rm_workmaybe I am being overly paranoid23:31
rm_workbut Barbican is for security, and paranoia is good in security :P23:31
*** kebray has joined #openstack-barbican23: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_workI believe so23:32
aleewoodster_, rm_work - we could also argue that you should not be able to get metadata on a secret without decrypted.23:32
aleeand just have one "get" operation23:32
rm_workso, for the initial work (K release) I'd assume just the get operation23:32
rm_workand ... fff23:32
rm_worki dunno23:32
rm_workmy gut feeling is that having them separate makes sense23:33
rm_workbut also that it'd be annoying to do23:33
rm_workand it'd really mess with the client23:33
rm_work(if you could get the payload for something but not the meta)23:33
rm_workthe client would need some changes23:33
aleerm_work, right -- that does not make sense23:33
aleerm_work, the client willneed changes in any case23:33
rm_workheh, true23: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 it23:34
rm_workalso, "would really mess with the client" is not a great reason to [not] do something23:34
rm_workwoodster_: yeah I would assume that is a more valid scenario23:34
rm_workso maybe we could say that one is a superset of the other?23:34
rm_workget-meta is meta-only, and get-secret is the whole shebang?23:35
rm_workor rather... hmmm23:35
rm_work"get" vs. "get-meta-only"23:35
rm_workI shy away from "get-secret" still because applying that to a container is dumb23: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
aleerm_work, woodster_ well maybe we need to just acknowledge that containers are different and just have "get-container"?23:36
aleea container is all metadata in any case23: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 no23:38
woodster_...esp. for bp #123:38
aleewoodster_, me too23:38
aleeI think you need to set perm on the secret explicitly23: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
aleeyup - we could do that ..23:40
aleeso "get" to be implemented first23:40
woodster_simple == more better23:40
aleeand later , "delete", "change-acl", "write" (maybe)23:41
aleeok cool - thats what I'm writin'23:41
woodster_yep, I'll add to the L discussion etherpad out here:
aleewoodster_, cool I have stuff to add to that too shortly23:42
woodster_alee soudns good!23:43
rm_workugh i am distracted for a sec, will try to come back and read this in a few23:44
aleeok being attacked by munchkin -- dinner time23:44
woodster_rm_work one thousand and one...23:44
*** alee is now known as alee_dinner23:44
rm_workyeah just "get" for now is fine23:51
rm_workwe can add the others later23:51
rm_workand 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 all23:52
rm_workbut it would be kinda useless23:52
rm_workpossibly later we could look into "get-container" cascades "get-meta-only" onto secrets or something, but whatever23:52
woodster_rm_work, yeah agreed23:56
woodster_I'm heading out too, take care rm_work23:58

Generated by 2.14.0 by Marius Gedminas - find it at!