| *** dviroel|out is now known as dviroel | 00:20 | |
| *** dviroel is now known as dviroel|out | 00:32 | |
| *** dviroel|out is now known as dviroel | 11:23 | |
| gmann | dmendiza[m]: knikolla regarding RBAC policy pop-up meeting. I checked with ricolin about his availability and I was thinking every alternate Tuesday 15 UTC. but you have keystone meeting at same time? | 13:58 |
|---|---|---|
| dmendiza[m] | gmann: I think knikolla is out this week. | 13:59 |
| gmann | dmendiza[m]: knikolla other time we can do is 14 UTC Alternate Tuesday, but it will be too early for dansmith ? | 13:59 |
| gmann | dmendiza[m]: ok, I am thinking to start from next week | 13:59 |
| gmann | 26th Tuesday onwards.. | 13:59 |
| dansmith | 1400 is not too early for me | 14:00 |
| gmann | yeah | 14:00 |
| dmendiza[m] | Hmm... | 14:00 |
| gmann | 15 seems best option but it conflict with keystone meeting | 14:00 |
| dmendiza[m] | We could try discussing SRBAC during Keystone meeting? | 14:00 |
| gmann | 15 UTC | 14:00 |
| gmann | yeah that is one option | 14:00 |
| dmendiza[m] | not sure if we need a full hour for SRBAC? | 14:00 |
| gmann | we prefer to discuss in video/voice call for productive | 14:01 |
| gmann | dmendiza[m]: not an hr as such, 30 min or so is ok. | 14:01 |
| gmann | 15:30 - 16 UTC can be good | 14:02 |
| gmann | but is it ok to switch to voice call ? we can keep keystone meeting open on IRC and capture key points | 14:02 |
| *** dasm|off is now known as dasm | 14:03 | |
| gmann | dansmith: ah sorry, I misread for your line and missed *not too..* :) I think I am half awake :) | 14:05 |
| dansmith | NOT too early... NOT. :) | 14:05 |
| * dansmith tries bigger font | 14:05 | |
| gmann | :) | 14:05 |
| gmann | dansmith: dmendiza[m] ricolin so Tuesday (26th) 14 UTC ok for every one ? | 14:05 |
| dansmith | yeah, I haven't been coming but I guess I need to fix that | 14:06 |
| dmendiza[m] | 1430-1500 would work out better for me | 14:06 |
| dmendiza[m] | I have a conflict 1400-1430, and might not be able to get out of it. | 14:07 |
| gmann | ok I think we can start with 30 min and if we have more topics to discuss other than current open points then we can see to extend or make it for an hr | 14:07 |
| gmann | I will change this to 14:30 - 15.00 UTC on alternate tuesday starting with 26th https://meetings.opendev.org/#Secure_Default_Policies_Popup-Team_Meeting | 14:08 |
| gmann | thanks | 14:08 |
| gmann | dansmith: dmendiza[m] ricolin https://review.opendev.org/c/opendev/irc-meetings/+/838727 | 14:18 |
| *** dviroel is now known as dviroel|lunch | 15:31 | |
| dansmith | dmendiza[m]: are you aware of any advice against projects writing keystone tokens to their databases and/or logs? | 15:53 |
| dansmith | AFAIK, we generally try to keep them only in the context object which we pass along via RPC and in memory but never store in a lot of cases | 15:53 |
| dansmith | and storing them seems like a Bad Idea(tm) but I'm wondering if there's any actual guidance on this | 15:54 |
| dmendiza[m] | writing token to logs seems risky | 15:54 |
| dansmith | for sure | 15:55 |
| dansmith | dmendiza[m]: but no guidance specifically that you know of? | 16:00 |
| dansmith | dmendiza[m]: and .. thoughts on the database? | 16:00 |
| dansmith | if there's someone else I should ask, feel free to redirect :) | 16:01 |
| dmendiza[m] | dansmith: I don't know of any guidance off the top of my head. I'd ask knikolla but he's out this week on PTO | 16:03 |
| dansmith | okay | 16:03 |
| dmendiza[m] | DB doesn't seem too bad (or at least not as bad as putting a token in the logs) | 16:04 |
| dmendiza[m] | since you need DB access credentials to get to it, vs just being able to read the log | 16:04 |
| dansmith | well, the log presumably requires more permission to read than the db really | 16:04 |
| dansmith | every machine in the cluster has access to the db over the network, so one compromised machine can read tokens for everyone that has one in the DB, vs just what would have been logged on that machine since rotation ocurred | 16:05 |
| dansmith | really one compromised service is all it takes actually | 16:06 |
| dansmith | so glance stores admin's tokens in the db to do something, and a compromised service that can read the glance db then has a token that is good for a *lot* of damage to every service and keystone itself, presumably, for $ttl | 16:07 |
| dmendiza[m] | I added this as a topic for the next Keystone meeting to get knikolla's thoughts: https://etherpad.opendev.org/p/keystone-weekly-meeting | 16:08 |
| dansmith | cool, thanks | 16:08 |
| dansmith | I think if there's a clear bit of guidance here (like writing them to logs specifically) it would be good to get that written down somewhere, | 16:09 |
| dansmith | and I'd definitely say some guidance about the DB would be good too | 16:09 |
| dansmith | like "try not to ever do that, but if you do, there should be some automated cleanup when the token is no longer needed or something" | 16:09 |
| dansmith | or just "don't do that" :) | 16:10 |
| dansmith | I'm surprised we don't have some generic "security practices" document similar to the api guidelines somewhere | 16:11 |
| *** dviroel|lunch is now known as dviroel | 16:31 | |
| *** ministry is now known as __ministry | 16:36 | |
| *** dasm is now known as dasm|off | 20:53 | |
| *** dviroel is now known as dviroel|out | 22:27 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!