| *** erhudy has quit IRC | 00:00 | |
| *** Ephur has joined #openstack-keystone | 00:00 | |
| *** Ephur has quit IRC | 00:00 | |
| *** Ephur has joined #openstack-keystone | 00:01 | |
| *** Ephur has quit IRC | 00:01 | |
| stingaci | ayoung: | 00:02 |
|---|---|---|
| *** Ephur has joined #openstack-keystone | 00:02 | |
| *** Ephur has quit IRC | 00:02 | |
| *** Ephur has joined #openstack-keystone | 00:03 | |
| *** Ephur has quit IRC | 00:03 | |
| *** Ephur has joined #openstack-keystone | 00:04 | |
| *** Ephur has quit IRC | 00:04 | |
| *** Ephur has joined #openstack-keystone | 00:04 | |
| *** Ephur has quit IRC | 00:05 | |
| ayoung | stingaci, ok, so the role is "admin_and_matching_domain_id | 00:05 |
| ayoung | dolphm, stevemar you guys are the admins in here, can you ban the Ephur account please | 00:05 |
| ayoung | its making things unusable | 00:05 |
| *** Ephur has joined #openstack-keystone | 00:05 | |
| *** Ephur has quit IRC | 00:06 | |
| *** Ephur has joined #openstack-keystone | 00:06 | |
| stingaci | I just used the value attribute from that rule to craft the following | 00:06 |
| stingaci | "role_admin": "role:admin and domain_id:%(domain_id)s", | 00:06 |
| stingaci | "admin_required": "rule:role_admin or is_admin:1", | 00:06 |
| *** Ephur has quit IRC | 00:06 | |
| *** Ephur has joined #openstack-keystone | 00:07 | |
| stingaci | ayoung: the rest is standard out-of-the-box policy.json | 00:08 |
| *** Ephur has joined #openstack-keystone | 00:08 | |
| *** Ephur has quit IRC | 00:08 | |
| *** Ephur has joined #openstack-keystone | 00:09 | |
| *** Ephur has quit IRC | 00:09 | |
| *** Ephur has joined #openstack-keystone | 00:10 | |
| *** Ephur has quit IRC | 00:10 | |
| ayoung | stingaci, are you familiar with the differnence between project and domain scoped tokens? I assume yes, but worth clarifying | 00:10 |
| stingaci | yes | 00:10 |
| *** Ephur has joined #openstack-keystone | 00:10 | |
| *** Ephur has quit IRC | 00:11 | |
| *** Ephur has joined #openstack-keystone | 00:11 | |
| stingaci | ayoung: does this mean that a project scoped token will not have a domain_id hence why any operations with the previously mentioned rules will fail? | 00:11 |
| ayoung | stingaci, yes | 00:12 |
| ayoung | roughly that | 00:12 |
| *** Ephur has quit IRC | 00:12 | |
| ayoung | it would be project.domain_id for project scoped tokens | 00:12 |
| ayoung | and you don't want that anyway | 00:12 |
| ayoung | that means anyone with admin on anyproject in the domain is a domain admin | 00:12 |
| ayoung | gotta run, | 00:12 |
| *** Ephur has joined #openstack-keystone | 00:12 | |
| stingaci | cheers | 00:12 |
| *** Ephur has quit IRC | 00:13 | |
| *** Ephur has joined #openstack-keystone | 00:13 | |
| *** Ephur has quit IRC | 00:13 | |
| *** Ephur has joined #openstack-keystone | 00:14 | |
| *** Ephur has quit IRC | 00:14 | |
| *** Ephur has joined #openstack-keystone | 00:15 | |
| *** Ephur has quit IRC | 00:15 | |
| *** Ephur has joined #openstack-keystone | 00:16 | |
| *** Ephur has joined #openstack-keystone | 00:17 | |
| *** Ephur has quit IRC | 00:17 | |
| *** Ephur has joined #openstack-keystone | 00:18 | |
| *** Ephur has quit IRC | 00:18 | |
| *** phalmos_ has quit IRC | 00:18 | |
| *** Ephur has joined #openstack-keystone | 00:18 | |
| *** Ephur has quit IRC | 00:19 | |
| *** Ephur has joined #openstack-keystone | 00:19 | |
| *** Ephur has quit IRC | 00:20 | |
| *** Ephur has joined #openstack-keystone | 00:20 | |
| *** Ephur has quit IRC | 00:21 | |
| *** Ephur has joined #openstack-keystone | 00:21 | |
| *** Ephur has quit IRC | 00:21 | |
| *** Ephur has joined #openstack-keystone | 00:22 | |
| *** Ephur has quit IRC | 00:22 | |
| *** Ephur has joined #openstack-keystone | 00:23 | |
| *** Ephur has quit IRC | 00:23 | |
| *** Ephur has joined #openstack-keystone | 00:24 | |
| *** Ephur has quit IRC | 00:24 | |
| *** Ephur has joined #openstack-keystone | 00:25 | |
| *** Ephur has quit IRC | 00:25 | |
| *** Ephur has joined #openstack-keystone | 00:26 | |
| *** Ephur has quit IRC | 00:26 | |
| *** Ephur has joined #openstack-keystone | 00:27 | |
| *** Ephur has quit IRC | 00:27 | |
| *** Ephur has joined #openstack-keystone | 00:27 | |
| *** Ephur has quit IRC | 00:28 | |
| *** Ephur has joined #openstack-keystone | 00:28 | |
| *** Ephur has quit IRC | 00:28 | |
| *** Ephur has joined #openstack-keystone | 00:29 | |
| *** Ephur has quit IRC | 00:29 | |
| *** Ephur has joined #openstack-keystone | 00:30 | |
| *** Ephur has quit IRC | 00:30 | |
| *** Ephur has joined #openstack-keystone | 00:31 | |
| *** Ephur has joined #openstack-keystone | 00:32 | |
| *** Ephur has quit IRC | 00:32 | |
| *** Ephur has joined #openstack-keystone | 00:33 | |
| *** Ephur has quit IRC | 00:33 | |
| *** Ephur has joined #openstack-keystone | 00:34 | |
| *** Ephur has quit IRC | 00:34 | |
| *** Ephur has joined #openstack-keystone | 00:34 | |
| *** Ephur has quit IRC | 00:35 | |
| *** Ephur has joined #openstack-keystone | 00:36 | |
| *** Ephur has joined #openstack-keystone | 00:36 | |
| *** Ephur has quit IRC | 00:36 | |
| *** Ephur has joined #openstack-keystone | 00:37 | |
| *** Ephur has quit IRC | 00:37 | |
| *** Ephur has joined #openstack-keystone | 00:38 | |
| *** Ephur has quit IRC | 00:38 | |
| *** Ephur has joined #openstack-keystone | 00:39 | |
| *** Ephur has quit IRC | 00:39 | |
| *** Ephur has joined #openstack-keystone | 00:40 | |
| *** Ephur has quit IRC | 00:40 | |
| *** Ephur has joined #openstack-keystone | 00:41 | |
| *** Ephur has quit IRC | 00:41 | |
| *** Ephur has joined #openstack-keystone | 00:41 | |
| *** Ephur has quit IRC | 00:42 | |
| *** Ephur has joined #openstack-keystone | 00:42 | |
| *** Ephur has quit IRC | 00:43 | |
| *** Ephur has joined #openstack-keystone | 00:43 | |
| *** stingaci has quit IRC | 00:44 | |
| *** Ephur has joined #openstack-keystone | 00:44 | |
| *** Ephur has quit IRC | 00:44 | |
| *** Ephur has joined #openstack-keystone | 00:45 | |
| *** Ephur has quit IRC | 00:45 | |
| *** Ephur has joined #openstack-keystone | 00:46 | |
| *** Ephur has quit IRC | 00:46 | |
| *** Ephur has joined #openstack-keystone | 00:47 | |
| *** Ephur has quit IRC | 00:47 | |
| *** Ephur has joined #openstack-keystone | 00:48 | |
| *** Ephur has quit IRC | 00:48 | |
| *** Ephur has joined #openstack-keystone | 00:49 | |
| *** Ephur has quit IRC | 00:49 | |
| *** Ephur has joined #openstack-keystone | 00:49 | |
| *** Ephur has quit IRC | 00:50 | |
| *** Ephur has joined #openstack-keystone | 00:50 | |
| *** asettle has joined #openstack-keystone | 00:50 | |
| *** Ephur has quit IRC | 00:51 | |
| *** Ephur has joined #openstack-keystone | 00:51 | |
| *** Ephur has quit IRC | 00:51 | |
| stevemar | ayoung: i guess ephur was kicked? | 00:52 |
| stevemar | ayoung: sorry, was eating dinner | 00:52 |
| stevemar | ayoung: some of the infra people have admin access too, like fungi | 00:52 |
| ayoung | stevemar, not a problem,. thanks | 00:52 |
| *** Ephur has joined #openstack-keystone | 00:52 | |
| *** Ephur has quit IRC | 00:52 | |
| *** gagehugo has joined #openstack-keystone | 00:53 | |
| *** Ephur has joined #openstack-keystone | 00:53 | |
| *** Ephur has quit IRC | 00:53 | |
| *** Ephur has joined #openstack-keystone | 00:54 | |
| *** Ephur has quit IRC | 00:54 | |
| *** Ephur has joined #openstack-keystone | 00:55 | |
| *** hoangcx_ has joined #openstack-keystone | 00:55 | |
| *** Ephur has quit IRC | 00:55 | |
| *** asettle has quit IRC | 00:55 | |
| *** Ephur has joined #openstack-keystone | 00:56 | |
| *** Ephur has quit IRC | 00:56 | |
| *** Ephur has joined #openstack-keystone | 00:56 | |
| *** Ephur has quit IRC | 00:57 | |
| *** Ephur has joined #openstack-keystone | 00:57 | |
| *** Ephur has quit IRC | 00:58 | |
| *** Ephur has joined #openstack-keystone | 00:58 | |
| *** Ephur has quit IRC | 00:59 | |
| *** Ephur has joined #openstack-keystone | 00:59 | |
| *** Ephur has quit IRC | 00:59 | |
| *** Ephur has joined #openstack-keystone | 01:00 | |
| *** Ephur has quit IRC | 01:00 | |
| *** Ephur has joined #openstack-keystone | 01:01 | |
| *** Ephur has quit IRC | 01:01 | |
| *** Ephur has joined #openstack-keystone | 01:02 | |
| *** Ephur has quit IRC | 01:02 | |
| stevemar | ayoung: this is the 3rd or 4th time a spammer has come while i'm at dinner | 01:02 |
| stevemar | ayoung: they definitely pick good times | 01:02 |
| *** Ephur has joined #openstack-keystone | 01:03 | |
| *** spzala has quit IRC | 01:03 | |
| *** Ephur has quit IRC | 01:03 | |
| *** spzala has joined #openstack-keystone | 01:03 | |
| *** Ephur has joined #openstack-keystone | 01:03 | |
| *** spzala has quit IRC | 01:04 | |
| *** spzala has joined #openstack-keystone | 01:04 | |
| *** Ephur has quit IRC | 01:04 | |
| *** Ephur has joined #openstack-keystone | 01:05 | |
| *** Ephur has quit IRC | 01:05 | |
| *** Ephur has joined #openstack-keystone | 01:05 | |
| *** Ephur has quit IRC | 01:06 | |
| *** Ephur has joined #openstack-keystone | 01:06 | |
| *** Ephur has quit IRC | 01:06 | |
| *** Ephur has joined #openstack-keystone | 01:07 | |
| *** Ephur has quit IRC | 01:07 | |
| *** Ephur has joined #openstack-keystone | 01:08 | |
| *** Ephur has quit IRC | 01:08 | |
| *** Ephur has joined #openstack-keystone | 01:09 | |
| *** Ephur has quit IRC | 01:09 | |
| *** tqtran has quit IRC | 01:10 | |
| *** Ephur has joined #openstack-keystone | 01:10 | |
| *** Ephur has quit IRC | 01:10 | |
| *** zhangjl has joined #openstack-keystone | 01:10 | |
| *** Ephur has joined #openstack-keystone | 01:11 | |
| *** Ephur has quit IRC | 01:11 | |
| *** Ephur has joined #openstack-keystone | 01:12 | |
| *** Ephur has quit IRC | 01:12 | |
| *** Ephur has joined #openstack-keystone | 01:13 | |
| *** Ephur has joined #openstack-keystone | 01:13 | |
| *** Ephur has quit IRC | 01:14 | |
| *** Ephur has joined #openstack-keystone | 01:14 | |
| *** Ephur has quit IRC | 01:14 | |
| *** Ephur has joined #openstack-keystone | 01:15 | |
| *** Ephur has quit IRC | 01:15 | |
| *** Ephur has joined #openstack-keystone | 01:16 | |
| *** Ephur has quit IRC | 01:16 | |
| *** Ephur has joined #openstack-keystone | 01:17 | |
| *** Ephur has quit IRC | 01:17 | |
| *** Ephur has joined #openstack-keystone | 01:18 | |
| *** Ephur has quit IRC | 01:18 | |
| *** Ephur has joined #openstack-keystone | 01:19 | |
| *** Ephur has quit IRC | 01:19 | |
| *** Ephur has joined #openstack-keystone | 01:20 | |
| *** Ephur has quit IRC | 01:20 | |
| *** Ephur has joined #openstack-keystone | 01:20 | |
| adriant | stevemar: a blank policy is meant to be 'anyone can access' or default to 'default' rule? | 01:21 |
| *** Ephur has quit IRC | 01:21 | |
| adriant | because just now testing in my devstack... as a non admin I can do region list: https://github.com/openstack/keystone/blob/master/etc/policy.json#L14 | 01:21 |
| *** Ephur has joined #openstack-keystone | 01:21 | |
| adriant | but if I change that line to "rule:default" I can't anymore. | 01:21 |
| *** Ephur has quit IRC | 01:21 | |
| *** Ephur has joined #openstack-keystone | 01:22 | |
| *** Ephur has quit IRC | 01:22 | |
| *** Ephur has joined #openstack-keystone | 01:23 | |
| *** Ephur has quit IRC | 01:23 | |
| *** Ephur has joined #openstack-keystone | 01:24 | |
| *** Ephur has quit IRC | 01:24 | |
| *** Zer0Byte__ has quit IRC | 01:24 | |
| *** Ephur has joined #openstack-keystone | 01:25 | |
| *** Ephur has quit IRC | 01:25 | |
| *** ayoung has quit IRC | 01:25 | |
| *** Ephur has joined #openstack-keystone | 01:26 | |
| *** Ephur has joined #openstack-keystone | 01:26 | |
| *** Ephur has quit IRC | 01:27 | |
| *** Ephur has joined #openstack-keystone | 01:28 | |
| *** Ephur has quit IRC | 01:28 | |
| *** Ephur has joined #openstack-keystone | 01:28 | |
| *** Ephur has quit IRC | 01:29 | |
| agrebennikov_ | hey folks, is it accurate that I cannot use wildcard certs with keystone middleware? | 01:29 |
| *** Ephur has joined #openstack-keystone | 01:29 | |
| *** Ephur has quit IRC | 01:29 | |
| agrebennikov_ | probably jamielennox | 01:30 |
| agrebennikov_ | (sorry for bugging you so early) | 01:30 |
| *** Ephur has joined #openstack-keystone | 01:30 | |
| *** Ephur has quit IRC | 01:30 | |
| jamielennox | agrebennikov_: not early for me, what do you mean you can't use wildcards? for hosting? that should be done via apache/something other than imddleware | 01:31 |
| agrebennikov_ | no | 01:31 |
| *** Ephur has joined #openstack-keystone | 01:31 | |
| agrebennikov_ | for services so that they can authenticate/validate against keystone with https | 01:31 |
| agrebennikov_ | I have my cert for the vip as *.test.com | 01:32 |
| agrebennikov_ | for example | 01:32 |
| *** Ephur has joined #openstack-keystone | 01:32 | |
| agrebennikov_ | and I have my vip as priv.test.com | 01:32 |
| *** Ephur has quit IRC | 01:32 | |
| agrebennikov_ | and even though I specified cafile = <cacert> in keystone_authtoken | 01:32 |
| jamielennox | keystone middleware shouldn't interfere there at all | 01:32 |
| agrebennikov_ | oh, really? | 01:33 |
| *** Ephur has joined #openstack-keystone | 01:33 | |
| *** Ephur has quit IRC | 01:33 | |
| jamielennox | ah, so that's for your (eg) nova service talking to keystone - right | 01:33 |
| jamielennox | that should be fine that just ends up as part of your request to keystone | 01:33 |
| agrebennikov_ | File "/openstack/venvs/glance-13.3.9/lib/python2.7/site-packages/keystoneauth1/session.py", line 490, in _send_request | 01:33 |
| agrebennikov_ | raise exceptions.SSLError(msg) | 01:33 |
| agrebennikov_ | SSLError: SSL exception connecting to https://priv.test.com:35357/v3/auth/tokens: hostname 'priv.test.com' doesn't match u'*.test.com' | 01:33 |
| agrebennikov_ | exactly | 01:34 |
| *** Ephur has joined #openstack-keystone | 01:34 | |
| stevemar | adriant: i thought a blank one allowed any authed user | 01:34 |
| *** Ephur has quit IRC | 01:34 | |
| jamielennox | so requests.post('https://path.to/keystone/v3/auth/tokens', cacert=CONF.keystone_authtoken.cacert) | 01:34 |
| adriant | stevemar: hmmm is '/OS-REVOKE/events' being non-admin accessible a security flaw? because the default policy doesn't limit non-admin access, nor does the code actually default to the default policy | 01:34 |
| *** Ephur has joined #openstack-keystone | 01:34 | |
| adriant | stevemar: that appears to be the case, yes, so I'm not sure what the point of the 'default' rule is then... | 01:34 |
| agrebennikov_ | jamielennox, but what the hell it's complaining about then? | 01:35 |
| agrebennikov_ | is it a problem of request lib? | 01:35 |
| *** Ephur has quit IRC | 01:35 | |
| jamielennox | agrebennikov_: but you generally don't put your wildcard in there, you put the cacert | 01:35 |
| jamielennox | the thing that signed the wildcard | 01:35 |
| agrebennikov_ | sure, it's my ca :) | 01:35 |
| *** Ephur has joined #openstack-keystone | 01:35 | |
| jamielennox | i mean, you can pass normal certs in there so i would expect that to work | 01:35 |
| *** Ephur has quit IRC | 01:36 | |
| jamielennox | agrebennikov_: i would test it first just using requests, like >>> import requests; request.get('https://keystone/v3', cacert='/ptah/to/ca') | 01:36 |
| *** Ephur has joined #openstack-keystone | 01:36 | |
| *** Ephur has quit IRC | 01:36 | |
| agrebennikov_ | hm... let me check | 01:37 |
| agrebennikov_ | since curl --cacert <> works | 01:37 |
| stevemar | adriant: that is an odd choice at first glance | 01:37 |
| stevemar | adriant: we can ask ayoung what his reasoning was | 01:37 |
| *** Ephur has joined #openstack-keystone | 01:37 | |
| *** Ephur has quit IRC | 01:37 | |
| adriant | stevemar: this works: http://paste.openstack.org/show/592155/ | 01:38 |
| jamielennox | i would expect both of these and curl to just back onto openssl though | 01:38 |
| *** Ephur has joined #openstack-keystone | 01:38 | |
| *** Ephur has quit IRC | 01:38 | |
| adriant | stevemar: and I don't think it should... revocation events aren't exactly that unsafe to know, but it's still not good to allow ANY authed user to get them. | 01:38 |
| *** Ephur has joined #openstack-keystone | 01:39 | |
| *** Ephur has joined #openstack-keystone | 01:40 | |
| *** Ephur has quit IRC | 01:40 | |
| *** Ephur has joined #openstack-keystone | 01:41 | |
| agrebennikov_ | hm... is it really "cacert"? | 01:41 |
| *** Ephur has quit IRC | 01:41 | |
| agrebennikov_ | return session.request(method=method, url=url, **kwargs) | 01:41 |
| agrebennikov_ | TypeError: request() got an unexpected keyword argument 'cacert' | 01:41 |
| *** Ephur has joined #openstack-keystone | 01:42 | |
| *** Ephur has quit IRC | 01:42 | |
| agrebennikov_ | jamielennox, | 01:42 |
| adriant | stevemar: eh, don't actually need the user agent header: http://paste.openstack.org/show/592158/ but you get the idea | 01:42 |
| jamielennox | agrebennikov_: oh, no sorry - it's verify | 01:42 |
| *** Ephur has joined #openstack-keystone | 01:42 | |
| jamielennox | verify= | 01:42 |
| *** Ephur has quit IRC | 01:43 | |
| adriant | stevemar: just doing a 'openstack token issue' and pasting the token into that paste should work in a standard devstack. | 01:43 |
| *** zhangjl has quit IRC | 01:43 | |
| *** Ephur has joined #openstack-keystone | 01:43 | |
| *** Ephur has quit IRC | 01:44 | |
| agrebennikov_ | jamielennox, so same thing :/ | 01:44 |
| agrebennikov_ | hostname doesn't match wildcard | 01:44 |
| jamielennox | agrebennikov_: yea, ok, so there's not much we can do about that from a keystone perspective then | 01:44 |
| agrebennikov_ | so it's not the problem of ca | 01:44 |
| *** Ephur has joined #openstack-keystone | 01:44 | |
| jamielennox | it's either requests or urllib3 | 01:44 |
| *** Ephur has quit IRC | 01:44 | |
| agrebennikov_ | right...... | 01:44 |
| jamielennox | my recommendation would be don't use a wildcard as a ca | 01:45 |
| jamielennox | if you want to do that just put a single root above it | 01:45 |
| agrebennikov_ | why? | 01:45 |
| *** Ephur has joined #openstack-keystone | 01:45 | |
| *** Ephur has quit IRC | 01:45 | |
| agrebennikov_ | I mean - it is the cert which is a wildcart | 01:45 |
| jamielennox | caroot -> wildcard | 01:45 |
| agrebennikov_ | not just ca | 01:45 |
| agrebennikov_ | so that I can use same cert for both public and private vips | 01:46 |
| *** Ephur has joined #openstack-keystone | 01:46 | |
| jamielennox | i mean it's mostly just weird to have a ca with a wildcard, largely ca's don't have domains at all you just call it something | 01:46 |
| *** Ephur has quit IRC | 01:46 | |
| jamielennox | but if you have the ca sign your wildcard then you can use the normal ca as the root of trust and it should be fine | 01:47 |
| *** Ephur has joined #openstack-keystone | 01:47 | |
| agrebennikov_ | no, this is not what I'm saying about :) ca can verify the cert in my case. But the library complains about the cert itself | 01:47 |
| *** Ephur has quit IRC | 01:47 | |
| agrebennikov_ | since the cert has a *.whatever | 01:47 |
| agrebennikov_ | while the lib wants it to be Ecactly private.test.com | 01:48 |
| agrebennikov_ | *exactly | 01:48 |
| *** Ephur has joined #openstack-keystone | 01:48 | |
| stevemar | adriant: i think the data there is signed right? | 01:48 |
| *** Ephur has quit IRC | 01:48 | |
| agrebennikov_ | if I don't have ca mentioned at all - ssl just drops me | 01:48 |
| jamielennox | oh, you think this is python's CN validation? | 01:48 |
| agrebennikov_ | with this | 01:48 |
| agrebennikov_ | requests.exceptions.SSLError: [Errno 1] _ssl.c:510: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed | 01:48 |
| agrebennikov_ | yeah | 01:48 |
| jamielennox | there is some special stuff it does there - but that looks like an openssl error message | 01:49 |
| *** Ephur has joined #openstack-keystone | 01:49 | |
| agrebennikov_ | freaking python.... :/ | 01:49 |
| *** Ephur has quit IRC | 01:49 | |
| adriant | stevemar: from my devstack: http://paste.openstack.org/show/592160/ | 01:49 |
| *** Ephur has joined #openstack-keystone | 01:49 | |
| *** Ephur has quit IRC | 01:50 | |
| adriant | stevemar: so as a non-admin user you can see who has logged out, been revoked, and when it seems :/ | 01:50 |
| *** Ephur has joined #openstack-keystone | 01:50 | |
| *** Ephur has quit IRC | 01:51 | |
| jamielennox | agrebennikov_: i haven't looked at how that's done in a while, i'm guessing it's in urllib3 | 01:51 |
| jamielennox | there was a function backported from later pytohns | 01:51 |
| stevemar | adriant: well, tokens don't get revoked at log out now :P | 01:51 |
| *** Ephur has joined #openstack-keystone | 01:51 | |
| adriant | ah, well *shrug* | 01:51 |
| jamielennox | actually the only thing to suggest is ensure you pip install requests[security] which ensures like the SSL libraries are installed | 01:51 |
| stevemar | adriant: im not sure on this one, want to file a security bug and see what the VMT says? | 01:51 |
| jamielennox | but i'd be surprised if that was the proble | 01:51 |
| *** Ephur has quit IRC | 01:52 | |
| *** asettle has joined #openstack-keystone | 01:52 | |
| stevemar | VMT = vulnerability management team | 01:52 |
| *** Ephur has joined #openstack-keystone | 01:52 | |
| *** Ephur has quit IRC | 01:52 | |
| adriant | stevemar: yeah I guess. I'm not sure what someone could do with revocation data, but having it exposed probably isn't a good thing. Might be worth reviewing all the policies to make sure they make sense. | 01:53 |
| adriant | stevemar: I know the trusts default policies are also blank. | 01:53 |
| *** Ephur has joined #openstack-keystone | 01:53 | |
| *** Ephur has quit IRC | 01:53 | |
| *** adrian_otto has quit IRC | 01:54 | |
| stevemar | adriant: yep, there are in-code checks for those | 01:54 |
| *** Ephur has joined #openstack-keystone | 01:54 | |
| agrebennikov_ | jamielennox, nevermind... I know what the problem is.... stupid dumb me | 01:54 |
| agrebennikov_ | it should work fine | 01:54 |
| *** Ephur has quit IRC | 01:54 | |
| stevemar | agrebennikov_: haha, hate it when that happens :P | 01:54 |
| adriant | stevemar: just looking through that now :) | 01:54 |
| stevemar | adriant: ;) | 01:55 |
| agrebennikov_ | I have my wc as *.test.com | 01:55 |
| *** Ephur has joined #openstack-keystone | 01:55 | |
| agrebennikov_ | the vip is called vip.test.com, and it is refistered in the upstream dns | 01:55 |
| *** Ephur has quit IRC | 01:55 | |
| agrebennikov_ | and I decided to use private.vip.test.com as private vip | 01:55 |
| agrebennikov_ | which just seems to be forbidden | 01:55 |
| *** Ephur has joined #openstack-keystone | 01:56 | |
| stevemar | adriant: thinking about the revoke list now, might be worth addressing it, i can't think of another way to get a bunch of user IDs, which i could then auth with and lock out | 01:56 |
| agrebennikov_ | to use second level of the name and expect it to be covered by the wildcard | 01:56 |
| *** Ephur has quit IRC | 01:56 | |
| jamielennox | i love it when that happens, it means we don't have to do anything upstream :) | 01:56 |
| agrebennikov_ | exactly | 01:56 |
| *** asettle has quit IRC | 01:56 | |
| agrebennikov_ | but at the same time I have to go talk to odyssey4me | 01:56 |
| *** Ephur has joined #openstack-keystone | 01:57 | |
| agrebennikov_ | since the ca is not distributed to any container but keystone | 01:57 |
| *** Ephur has quit IRC | 01:57 | |
| agrebennikov_ | but it's a separate story | 01:57 |
| agrebennikov_ | thanks jamielennox stevemar | 01:57 |
| jamielennox | agrebennikov_: maybe the easier way to do this in a deploy is register the certs into the OS instead | 01:57 |
| agrebennikov_ | :) | 01:57 |
| *** Ephur has joined #openstack-keystone | 01:57 | |
| jamielennox | agrebennikov_: you can register one public, one private whatever rather than do it at the keystone level | 01:57 |
| agrebennikov_ | jamielennox, what do you mean? | 01:57 |
| *** Ephur has quit IRC | 01:58 | |
| agrebennikov_ | ah, yes, sure | 01:58 |
| agrebennikov_ | that's not a big deal | 01:58 |
| agrebennikov_ | it is just in the OSA | 01:58 |
| agrebennikov_ | at all | 01:58 |
| adriant | stevemar: if it was revocation events for you, maybe it would be fine, but it seems to list all of them. :( | 01:58 |
| *** Ephur has joined #openstack-keystone | 01:58 | |
| *** Ephur has quit IRC | 01:59 | |
| *** Ephur has joined #openstack-keystone | 01:59 | |
| *** Ephur has quit IRC | 01:59 | |
| *** Ephur has joined #openstack-keystone | 02:00 | |
| *** Ephur has quit IRC | 02:00 | |
| *** Ephur has joined #openstack-keystone | 02:01 | |
| *** Ephur has quit IRC | 02:01 | |
| *** Ephur has joined #openstack-keystone | 02:02 | |
| *** Ephur has quit IRC | 02:02 | |
| *** Ephur has joined #openstack-keystone | 02:03 | |
| *** Ephur has quit IRC | 02:03 | |
| *** Ephur has joined #openstack-keystone | 02:04 | |
| *** Ephur has quit IRC | 02:04 | |
| *** Ephur has joined #openstack-keystone | 02:04 | |
| *** Ephur has quit IRC | 02:05 | |
| *** Ephur has joined #openstack-keystone | 02:05 | |
| *** Ephur has quit IRC | 02:06 | |
| *** Ephur has joined #openstack-keystone | 02:06 | |
| *** Ephur has quit IRC | 02:07 | |
| *** Ephur has joined #openstack-keystone | 02:07 | |
| *** Ephur has quit IRC | 02:07 | |
| *** Ephur has joined #openstack-keystone | 02:08 | |
| *** Ephur has quit IRC | 02:08 | |
| *** zhangjl has joined #openstack-keystone | 02:09 | |
| *** Ephur has joined #openstack-keystone | 02:09 | |
| *** Ephur has quit IRC | 02:09 | |
| *** Ephur has joined #openstack-keystone | 02:10 | |
| *** Ephur has quit IRC | 02:10 | |
| *** Ephur has joined #openstack-keystone | 02:11 | |
| *** Ephur has quit IRC | 02:11 | |
| adriant | stevemar: so should I file a bug? On launchpad? | 02:11 |
| stevemar | adriant: yeah, when doing so go to the advanced options and mark it as security vuln | 02:12 |
| adriant | stevemar: ultimately, it's unsafe because you can gleam some of your user base, and then it's a question of what exactly can someone do given a user_id | 02:12 |
| stevemar | adriant: yeah, that's my thinking, nothing too crazy but still | 02:12 |
| adriant | with that endpoint exposed, you can have a script collecting a list of all users it sees on your cloud | 02:13 |
| adriant | which isn't exactly a good thing | 02:13 |
| adriant | but I'm not intrusion minded enough to think of awful things I could do with a list of user_ids | 02:13 |
| *** namnh has joined #openstack-keystone | 02:24 | |
| stevemar | adriant: repeated auth attempts aren't nice | 02:24 |
| adriant | stevemar: well yes, you can brute force, and if not you can lock out a given user. | 02:26 |
| adriant | stevemar: the lock out is not so bad, but the brute force (if no rate limiting in place) is very bad, and it's with a known user | 02:27 |
| stevemar | adriant: if you don't rate limit you're gonna have a bad time | 02:27 |
| adriant | stevemar: yep | 02:27 |
| *** stingaci has joined #openstack-keystone | 02:32 | |
| *** stingaci has quit IRC | 02:33 | |
| *** stingaci has joined #openstack-keystone | 02:33 | |
| *** guoshan has joined #openstack-keystone | 02:41 | |
| adriant | stevemar: submitted | 02:44 |
| stevemar | adriant: thanks | 02:44 |
| stevemar | 1 | 02:44 |
| stevemar | ! | 02:44 |
| *** stingaci has quit IRC | 02:45 | |
| *** chlong has quit IRC | 02:45 | |
| morgan | ugh | 02:50 |
| morgan | just saw that bug | 02:50 |
| morgan | adriant: please don't use paste for security bugs. | 02:51 |
| morgan | adriant: it is public (and crawled by many things) | 02:51 |
| adriant | morgan: noted, just used it there because devstack data and doesn't show anything useful | 02:51 |
| morgan | better to embed it all in the bug report *or* attach the info to the bug | 02:52 |
| morgan | as an upload, since those are secure | 02:52 |
| *** asettle has joined #openstack-keystone | 02:52 | |
| *** spzala has quit IRC | 02:52 | |
| adriant | yeah, will edit it. Just used a paste there since the paste data doesn't reflect or say anything about what it is about | 02:53 |
| openstackgerrit | Shan Guo proposed openstack/keystone: [api] set `is_admin_project` on tokens for admin project https://review.openstack.org/409678 | 02:55 |
| *** asettle has quit IRC | 02:57 | |
| adriant | morgan: I know in our deployment we've run into weird policy stuff. The note at the end is a suggestion to look a bit deeper, but at least in this case for Keystone, it is a problem. :/ | 02:57 |
| *** chlong has joined #openstack-keystone | 02:59 | |
| morgan | adriant: also, please avoid publically discussing details of private security bugs. | 03:01 |
| morgan | Conversations should be in private or as comments on the bug itself for all reviewers to see. | 03:01 |
| morgan | adriant: not meaning to pick on you here, just doing the VMT work :). | 03:01 |
| adriant | morgan: I'm aware, and I don't mind. That's way the above comment was vague as all hell. :) | 03:02 |
| adriant | but will keep it to email and the report itself. | 03:02 |
| adriant | s/way/why/ | 03:03 |
| morgan | right, but if you look at context, the previous bits you discussed could be put together. I've updated the info so we can get keystone-coresec to look it over and help make a call on severity etc | 03:03 |
| adriant | morgan: noted :) | 03:04 |
| *** zhangjl1 has joined #openstack-keystone | 03:09 | |
| *** zhangjl has quit IRC | 03:10 | |
| *** stingaci has joined #openstack-keystone | 03:25 | |
| *** agrebennikov_ has quit IRC | 03:26 | |
| *** raginbajin has quit IRC | 03:27 | |
| *** raginbajin has joined #openstack-keystone | 03:32 | |
| *** stingaci has quit IRC | 03:38 | |
| *** stingaci has joined #openstack-keystone | 03:42 | |
| *** harlowja has quit IRC | 03:43 | |
| *** asettle has joined #openstack-keystone | 03:53 | |
| *** spzala has joined #openstack-keystone | 03:54 | |
| *** asettle has quit IRC | 03:58 | |
| *** nicolasbock has quit IRC | 03:58 | |
| *** stingaci has quit IRC | 04:09 | |
| *** dikonoor has joined #openstack-keystone | 04:09 | |
| openstackgerrit | Tony Breeds proposed openstack/oslo.policy: Add Constraints support https://review.openstack.org/410024 | 04:10 |
| *** harlowja has joined #openstack-keystone | 04:21 | |
| *** links has joined #openstack-keystone | 04:22 | |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Pass ?allow_expired https://review.openstack.org/382100 | 04:23 |
| openstackgerrit | Tony Breeds proposed openstack/pycadf: Add Constraints support https://review.openstack.org/410036 | 04:27 |
| * stevemar thinks tonyb forgot to indent in the if block | 04:28 | |
| tonyb | stevemar: Ummm in tox_install.sh? | 04:29 |
| tonyb | Oh phooey | 04:29 |
| stevemar | tonyb: y, line 17? | 04:29 |
| stevemar | tonyb: i don't remember if that's allowed in bash or not | 04:30 |
| tonyb | stevemar: it's correct and does what I wan it just looks ugly | 04:30 |
| tonyb | stevemar: It probably won't pass bashate either :( | 04:31 |
| stevemar | tonyb: oh def not bashate | 04:31 |
| stevemar | but most projects don't have that enabled i feel | 04:31 |
| tonyb | stevemar: Yeah but it still needs fixing. | 04:32 |
| *** udesale has joined #openstack-keystone | 04:32 | |
| * stevemar goes off to sleep | 04:33 | |
| openstackgerrit | Tony Breeds proposed openstack/pycadf: Add Constraints support https://review.openstack.org/410036 | 04:34 |
| openstackgerrit | Tony Breeds proposed openstack/oslo.policy: Add Constraints support https://review.openstack.org/410024 | 04:39 |
| *** adrian_otto has joined #openstack-keystone | 04:41 | |
| *** hoangcx_ is now known as hoangcx | 04:42 | |
| *** madhaviy has joined #openstack-keystone | 04:43 | |
| *** liujiong has joined #openstack-keystone | 04:46 | |
| *** spzala has quit IRC | 04:49 | |
| *** spzala has joined #openstack-keystone | 04:49 | |
| *** spzala has quit IRC | 04:49 | |
| jamielennox | stevemar: https://review.openstack.org/#/c/410039/1/lib/keystone is the failure for allow_expired | 04:53 |
| *** asettle has joined #openstack-keystone | 04:54 | |
| *** madhaviy has quit IRC | 04:56 | |
| *** asettle has quit IRC | 04:59 | |
| *** tqtran has joined #openstack-keystone | 05:07 | |
| *** harlowja has quit IRC | 05:08 | |
| *** agrebennikov_ has joined #openstack-keystone | 05:08 | |
| *** tqtran has quit IRC | 05:11 | |
| *** rdo has quit IRC | 05:11 | |
| *** rdo has joined #openstack-keystone | 05:18 | |
| *** guoshan has quit IRC | 05:29 | |
| *** dikonoor has quit IRC | 05:35 | |
| *** adrian_otto has quit IRC | 05:39 | |
| *** adrian_otto has joined #openstack-keystone | 05:40 | |
| *** stingaci has joined #openstack-keystone | 05:42 | |
| *** stingaci has quit IRC | 05:46 | |
| *** dikonoor has joined #openstack-keystone | 05:55 | |
| *** asettle has joined #openstack-keystone | 05:55 | |
| *** adriant has quit IRC | 05:56 | |
| *** harlowja has joined #openstack-keystone | 05:56 | |
| *** asettle has quit IRC | 06:00 | |
| *** namnh has quit IRC | 06:01 | |
| *** hoangcx has quit IRC | 06:01 | |
| *** hoangcx has joined #openstack-keystone | 06:01 | |
| *** namnh has joined #openstack-keystone | 06:01 | |
| *** guoshan has joined #openstack-keystone | 06:04 | |
| *** tovin07 has quit IRC | 06:06 | |
| *** tovin07__ has joined #openstack-keystone | 06:06 | |
| *** stingaci has joined #openstack-keystone | 06:08 | |
| *** stingaci has quit IRC | 06:09 | |
| *** diazjf has joined #openstack-keystone | 06:11 | |
| *** diazjf has quit IRC | 06:11 | |
| *** Ephur has joined #openstack-keystone | 06:13 | |
| *** dikonoo has joined #openstack-keystone | 06:13 | |
| *** Ephur has quit IRC | 06:17 | |
| *** links has quit IRC | 06:34 | |
| *** tovin07__ has quit IRC | 06:34 | |
| *** tovin07__ has joined #openstack-keystone | 06:35 | |
| *** tovin07__ has quit IRC | 06:35 | |
| *** tovin07__ has joined #openstack-keystone | 06:35 | |
| *** agrebennikov_ has quit IRC | 06:36 | |
| *** Zer0Byte__ has joined #openstack-keystone | 06:37 | |
| *** links has joined #openstack-keystone | 06:39 | |
| *** frickler has quit IRC | 06:40 | |
| *** richm has quit IRC | 06:41 | |
| *** tovin07__ is now known as tovin07_afk | 06:42 | |
| *** adrian_otto has quit IRC | 06:42 | |
| *** tovin07_afk has quit IRC | 06:50 | |
| *** asettle has joined #openstack-keystone | 06:56 | |
| *** asettle has quit IRC | 07:01 | |
| *** ravelar has quit IRC | 07:12 | |
| *** nkinder has quit IRC | 07:14 | |
| *** nkinder has joined #openstack-keystone | 07:23 | |
| *** harlowja has quit IRC | 07:25 | |
| *** tobberydberg has joined #openstack-keystone | 07:52 | |
| *** frickler has joined #openstack-keystone | 07:53 | |
| *** Zer0Byte__ has quit IRC | 07:54 | |
| *** asettle has joined #openstack-keystone | 07:57 | |
| *** jaosorior has joined #openstack-keystone | 07:59 | |
| *** stingaci has joined #openstack-keystone | 08:01 | |
| *** asettle has quit IRC | 08:02 | |
| *** basilAB has quit IRC | 08:04 | |
| *** rcernin has joined #openstack-keystone | 08:05 | |
| *** stingaci has quit IRC | 08:05 | |
| *** pnavarro has joined #openstack-keystone | 08:07 | |
| *** basilAB has joined #openstack-keystone | 08:09 | |
| *** pcaruana has joined #openstack-keystone | 08:10 | |
| *** tqtran has joined #openstack-keystone | 08:10 | |
| *** jaosorior has quit IRC | 08:12 | |
| *** jaosorior has joined #openstack-keystone | 08:12 | |
| *** tqtran has quit IRC | 08:14 | |
| *** stingaci has joined #openstack-keystone | 08:20 | |
| *** rcernin has quit IRC | 08:22 | |
| *** stingaci has quit IRC | 08:24 | |
| *** rcernin has joined #openstack-keystone | 08:25 | |
| *** wanghua has joined #openstack-keystone | 08:49 | |
| *** zzzeek has quit IRC | 09:00 | |
| *** zzzeek has joined #openstack-keystone | 09:01 | |
| *** asettle has joined #openstack-keystone | 09:20 | |
| *** asettle has quit IRC | 09:22 | |
| *** asettle has joined #openstack-keystone | 09:22 | |
| *** mvk has quit IRC | 09:23 | |
| *** mvk has joined #openstack-keystone | 09:54 | |
| *** liujiong has quit IRC | 10:12 | |
| *** Ephur has joined #openstack-keystone | 10:14 | |
| *** links has quit IRC | 10:16 | |
| *** ravelar has joined #openstack-keystone | 10:18 | |
| *** Ephur has quit IRC | 10:19 | |
| *** hoangcx has quit IRC | 10:21 | |
| *** ravelar has quit IRC | 10:23 | |
| *** guoshan has quit IRC | 10:24 | |
| *** links has joined #openstack-keystone | 10:30 | |
| *** asettle has quit IRC | 10:30 | |
| *** asettle has joined #openstack-keystone | 10:36 | |
| *** asettle has quit IRC | 10:37 | |
| *** asettle has joined #openstack-keystone | 10:37 | |
| *** namnh has quit IRC | 10:38 | |
| *** guoshan has joined #openstack-keystone | 10:39 | |
| *** woodster_ has quit IRC | 10:45 | |
| *** dikonoo has quit IRC | 11:00 | |
| *** dikonoor has quit IRC | 11:01 | |
| *** daemontool has joined #openstack-keystone | 11:02 | |
| *** udesale has quit IRC | 11:02 | |
| *** guoshan has quit IRC | 11:06 | |
| *** zhangjl1 has quit IRC | 11:07 | |
| *** tqtran has joined #openstack-keystone | 11:12 | |
| *** zhugaoxiao has joined #openstack-keystone | 11:13 | |
| *** richm has joined #openstack-keystone | 11:14 | |
| *** guoshan has joined #openstack-keystone | 11:14 | |
| *** links has quit IRC | 11:15 | |
| *** tqtran has quit IRC | 11:17 | |
| samueldmq | morning keystone | 11:18 |
| *** mvk has quit IRC | 11:24 | |
| *** amoralej|off is now known as amoralej | 11:25 | |
| *** links has joined #openstack-keystone | 11:32 | |
| *** mvk has joined #openstack-keystone | 11:37 | |
| *** guoshan has quit IRC | 11:41 | |
| *** nicolasbock has joined #openstack-keystone | 11:45 | |
| *** zhugaoxiao has quit IRC | 11:56 | |
| *** zhugaoxiao has joined #openstack-keystone | 11:56 | |
| *** guoshan has joined #openstack-keystone | 12:07 | |
| *** jaosorior is now known as jaosorior_brb | 12:10 | |
| *** guoshan has quit IRC | 12:27 | |
| *** guoshan has joined #openstack-keystone | 12:27 | |
| *** guoshan has quit IRC | 12:32 | |
| *** tobberydberg has quit IRC | 12:34 | |
| *** tobberydberg has joined #openstack-keystone | 12:34 | |
| *** tobberydberg has quit IRC | 12:38 | |
| *** dikonoo has joined #openstack-keystone | 12:39 | |
| *** dikonoor has joined #openstack-keystone | 12:39 | |
| openstackgerrit | Kseniya Tychkova proposed openstack/keystone-specs: Quota limits https://review.openstack.org/363765 | 12:47 |
| stevemar | samueldmq: o/ | 12:48 |
| stevemar | samueldmq: can you check https://review.openstack.org/#/c/409923/ too, you approved the follow-on | 12:48 |
| samueldmq | stevemar: sure, done | 12:49 |
| samueldmq | :) | 12:49 |
| stevemar | samueldmq: thx | 12:49 |
| samueldmq | anytime | 12:49 |
| openstackgerrit | Kseniya Tychkova proposed openstack/keystone-specs: Quota limits https://review.openstack.org/363765 | 12:49 |
| *** tobberydberg has joined #openstack-keystone | 12:53 | |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Federated authentication via ECP functional tests https://review.openstack.org/324769 | 12:54 |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Settings for test cases https://review.openstack.org/410205 | 12:54 |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Federated authentication via ECP functional tests https://review.openstack.org/324769 | 12:56 |
| *** edmondsw has joined #openstack-keystone | 13:03 | |
| *** dave-mccowan has joined #openstack-keystone | 13:06 | |
| *** edmondsw_ has joined #openstack-keystone | 13:10 | |
| *** stingaci has joined #openstack-keystone | 13:10 | |
| *** tqtran has joined #openstack-keystone | 13:14 | |
| *** stingaci has quit IRC | 13:15 | |
| *** edmondsw_ has quit IRC | 13:16 | |
| *** tqtran has quit IRC | 13:18 | |
| *** asettle has quit IRC | 13:19 | |
| *** nklenke has joined #openstack-keystone | 13:19 | |
| *** asettle has joined #openstack-keystone | 13:19 | |
| rodrigods | stevemar, i guess with https://review.openstack.org/#/c/410205/1 we can have https://review.openstack.org/#/c/324769/23 running fine | 13:44 |
| *** amoralej is now known as amoralej|lunch | 13:44 | |
| rodrigods | the only problem is the related bug | 13:44 |
| stevemar | rodrigods: oh? | 13:56 |
| stevemar | ah, that bug | 13:56 |
| stevemar | seems fine to me | 13:56 |
| rodrigods | curious to check the gate output | 13:57 |
| rodrigods | hopefully it will fail only the keystone-dsvm-v3 (which is the only job it is supposed to run in) | 13:57 |
| *** udesale has joined #openstack-keystone | 13:58 | |
| *** ayoung has joined #openstack-keystone | 13:58 | |
| *** ChanServ sets mode: +v ayoung | 13:58 | |
| *** lamt has joined #openstack-keystone | 14:03 | |
| *** jaosorior_brb is now known as jaosorior | 14:09 | |
| *** guoshan has joined #openstack-keystone | 14:11 | |
| *** agrebennikov_ has joined #openstack-keystone | 14:22 | |
| samueldmq | stevemar: please look at https://review.openstack.org/#/c/409678 when you have a chance | 14:30 |
| samueldmq | stevemar: I've put a couple of suggestions there, not sure which one is better. and since you're a docs expert.... :) | 14:31 |
| *** narasimha_SV has joined #openstack-keystone | 14:31 | |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Federated authentication via ECP functional tests https://review.openstack.org/324769 | 14:32 |
| *** daemontool has quit IRC | 14:33 | |
| *** adrian_otto has joined #openstack-keystone | 14:35 | |
| *** amoralej|lunch is now known as amoralej | 14:36 | |
| *** adrian_otto1 has joined #openstack-keystone | 14:39 | |
| *** adrian_otto has quit IRC | 14:40 | |
| *** zzzeek has quit IRC | 14:43 | |
| *** zzzeek has joined #openstack-keystone | 14:43 | |
| dstanek | ayoung: have you seen https://review.openstack.org/#/c/382672/ ? | 14:44 |
| ayoung | dstanek, nope | 14:44 |
| *** dikonoo has quit IRC | 14:45 | |
| *** dikonoor has quit IRC | 14:45 | |
| ayoung | dstanek, its not a bad idea, although calling it RBAC is probably too limiting | 14:45 |
| dstanek | ayoung: https://github.com/DavidPurcellATT/patrole | 14:46 |
| ayoung | dstanek, none of the Keystone folks were on the review | 14:48 |
| *** udesale has quit IRC | 14:49 | |
| stevemar | ayoung: sounds like it's just additional testing | 14:50 |
| stevemar | no new stuff | 14:50 |
| ayoung | stevemar, it is RBAC in policy.json | 14:50 |
| ayoung | https://review.openstack.org/#/c/410250/1 posted a revert. It will start the discussion anyway. | 14:51 |
| stevemar | "Patrole is a Tempest plugin to test Role Base Access Control for OpenStack API's." | 14:51 |
| stevemar | gagehugo: do you know who david purcell is? | 14:52 |
| stevemar | gagehugo: or his irc handle? | 14:53 |
| stevemar | ayoung: you can still comment on https://review.openstack.org/#/c/382672/ | 14:53 |
| stevemar | ayoung: ah, i see you proposed the revert | 14:53 |
| stevemar | ayoung: good comments on the revert | 14:54 |
| narasimha_SV | if we want configure k2k federation do we need to have keystone setups to configure 1 keystone as IDP and another as SP | 14:54 |
| ayoung | stevemar, and a comment saying "this is to start the conversation..." | 14:54 |
| stevemar | yep, noticed | 14:54 |
| ayoung | morgan, stevemar, BTW, care to re-add the +2s to https://review.openstack.org/#/c/391624/ ? Matt had some reservations with the old one, mostly due to my limiting things to one-operation-one-role | 14:55 |
| ayoung | I made it many to many (still not sure that is right) | 14:55 |
| ayoung | and cleaned up more of the language | 14:55 |
| dstanek | narasimha_SV: yep | 14:55 |
| *** tobberyd_ has joined #openstack-keystone | 14:55 | |
| *** wanghua has quit IRC | 14:56 | |
| ayoung | dstanek, it is Impossible to map from policy rule to API | 14:56 |
| ayoung | you need to understand the code structure of each individual project | 14:56 |
| ayoung | and there will be projects that are written in other languages | 14:56 |
| ayoung | there are projects that are not part of the OpenStack Big tent | 14:57 |
| ayoung | and Keystone needs to support those, too | 14:57 |
| dstanek | ayoung: I'm not taking about mapping to URLs, but to operations | 14:57 |
| lbragstad | we use policy rules today and something already does the mapping anyway | 14:57 |
| *** tobberydberg has quit IRC | 14:59 | |
| lbragstad | s/policy rules/operations/ | 14:59 |
| * dstanek is at the doctor now so he's typing sloooow | 15:00 | |
| *** tobberyd_ has quit IRC | 15:00 | |
| ayoung | lbragstad, dstanek there is even less of a mapping there | 15:01 |
| ayoung | Horizon calls into python-*client | 15:01 |
| ayoung | that builds the URL | 15:01 |
| ayoung | that gets passed to the remote service ... passes through keystonemiddleware into the service | 15:02 |
| ayoung | somewhere deep in the service, it matches a random string to pull out the rule | 15:02 |
| ayoung | for Keystone that random string is a method name on the object] | 15:02 |
| ayoung | but the other services do other things | 15:02 |
| ayoung | so, yeah, two operations on the same resource might get passed through two separate policy checks, nothing we can do to affectthat | 15:03 |
| ayoung | its not really different than the Unix file system approacjh | 15:04 |
| ayoung | you can hard link the same inode into two different directories | 15:04 |
| ayoung | and have different permissions in each directory | 15:04 |
| ayoung | read only in one, writable in the other | 15:04 |
| ayoung | differnt groups, etc | 15:04 |
| *** guoshan has quit IRC | 15:05 | |
| *** guoshan has joined #openstack-keystone | 15:06 | |
| *** udesale has joined #openstack-keystone | 15:08 | |
| *** udesale has quit IRC | 15:10 | |
| *** udesale has joined #openstack-keystone | 15:10 | |
| *** phalmos has joined #openstack-keystone | 15:11 | |
| *** guoshan has quit IRC | 15:11 | |
| *** edtubill has joined #openstack-keystone | 15:12 | |
| *** chlong has quit IRC | 15:13 | |
| *** phalmos_ has joined #openstack-keystone | 15:15 | |
| *** tqtran has joined #openstack-keystone | 15:15 | |
| *** jaugustine has joined #openstack-keystone | 15:16 | |
| *** phalmos has quit IRC | 15:18 | |
| lbragstad | ayoung i think having the url makes maintaining things for the project harder | 15:19 |
| ayoung | lbragstad, harder than impossible? | 15:19 |
| lbragstad | especially if a service has the same operation available across two api versions | 15:19 |
| *** tqtran has quit IRC | 15:20 | |
| lbragstad | as a policy writer - I have to make sure all possible ways a user can do something over every api version in the deployment has the same role(s) | 15:20 |
| openstackgerrit | Ron De Rose proposed openstack/keystone: Require domain_id when registering Identity Providers https://review.openstack.org/399684 | 15:21 |
| ayoung | lbragstad, stop saying policy. We are not talking full policy intentionally here. | 15:22 |
| ayoung | policy is a really hard thing to get right | 15:22 |
| lbragstad | sure - but is this making it any easier? | 15:22 |
| ayoung | so, as an administrator, you have to ensure that multiple URLS that provide access to the same resource do not accidentally provide elevated access to a less privileged user. | 15:22 |
| ayoung | lbragstad, yes | 15:22 |
| ayoung | lbragstad, as I said, today it is impossible | 15:23 |
| ayoung | most of the policy rules in effect today do not enforce RBAC at all | 15:23 |
| ayoung | aside from admin, and that is still broken in multiple projects | 15:23 |
| ayoung | but lets put a pin in admin, grandfather it in, and move back to the other APIS | 15:23 |
| ayoung | long term, I want to remove the admin check from policy | 15:24 |
| ayoung | but that is a tale for another release | 15:24 |
| ayoung | lbragstad, the very real feature request we've had numerous times if for a read only role | 15:24 |
| gagehugo | stevemar: yes I know him | 15:24 |
| ayoung | this is, quite simply, the only way I can see to get that implemented | 15:25 |
| ayoung | the current policy setup derailed the attempt to get a standard set of roles defined | 15:25 |
| ayoung | and there is no support for linking policy.json to the Keystone database | 15:25 |
| lbragstad | ayoung what was the reason? | 15:25 |
| ayoung | we pushed hard on that | 15:25 |
| *** ravelar has joined #openstack-keystone | 15:25 | |
| ayoung | lbragstad, ok, here are the details | 15:25 |
| ayoung | in order to have a read only role, you need to ensure that tokens with only that role are not accepted on APIs that are `write` | 15:26 |
| lbragstad | ayoung sure | 15:26 |
| ayoung | that involves going through every api in every service and ensuring that has, at a minimum, a role elevated above "reader" | 15:26 |
| ayoung | which means changing the policy file everywhere. And, by the way, this breaks if the roles are not already defined in Keystone | 15:27 |
| ayoung | there was not even a consistant Member vs _member_ out there | 15:27 |
| ayoung | and some, like edmondsw have deployments that don't use member at all | 15:27 |
| lbragstad | ok | 15:28 |
| ayoung | we can't mess with policy without breaking a lot of people | 15:28 |
| ayoung | thus, it calls for a mechanism on top OF the existing policy framework | 15:28 |
| ayoung | and, it calls for something targetted at the roles, and in sync with the Keystone server | 15:28 |
| ayoung | the set of roles in Keystone need to drive the RBAC rules | 15:28 |
| ayoung | It is based on the URL to make a mechanism that can work for any service. | 15:29 |
| ayoung | and also to give information to Horizon about what role is required for the service | 15:29 |
| ayoung | and not just Horizon | 15:29 |
| ayoung | trusts, any delegation | 15:29 |
| ayoung | we need a way to say "what is the minimum I need to delegate in order to get that worker access to this API" | 15:30 |
| dstanek | ayoung: couldn't you use summer friendly token instead of URL? | 15:30 |
| ayoung | lbragstad, its a hard problem. I tried to keep the solution as simple as possible | 15:30 |
| ayoung | dstanek, so, I don't think so | 15:31 |
| dstanek | Summer should have been user | 15:31 |
| ayoung | dstanek, you mean something like compute:create_server? | 15:31 |
| ayoung | dstanek, so...I think what we will end up having is a request for a modifyier attribute on roles | 15:31 |
| ayoung | just like we have domain-specific and global today | 15:32 |
| dstanek | yes, the service already maps that... Horizon and clients already come close | 15:32 |
| ayoung | I see three types of roles over time | 15:32 |
| ayoung | organizational, workflow, resource | 15:32 |
| ayoung | admin service and member are orginazational | 15:33 |
| ayoung | workflow is like "create and modify a vm" that has to talk to multiple services | 15:33 |
| ayoung | resources is lie "image:read_image" | 15:33 |
| ayoung | and then the URL patterns would be mapped one-to-one with the resource roles | 15:34 |
| ayoung | and we can evolve toward that, but I don't want to boil the ocean in this spec | 15:34 |
| *** udesale has quit IRC | 15:34 | |
| ayoung | dstanek, that would make for a nicer UI experience | 15:35 |
| ayoung | list_roles should then show the organization roles by default | 15:35 |
| ayoung | but, if I need to figure out how to delegate a subset of operations, I can delegate the workflow role, or even the resource level role and provide least priv | 15:36 |
| ayoung | but...I want this to be incremental | 15:36 |
| lbragstad | ayoung go back to the read only role problem | 15:36 |
| ayoung | so, for now, I want to get the mechanism defined, get a proof of concept out there, let people try it, and get feedback | 15:36 |
| dstanek | ayoung: I want to define the end state even if it's boiling the ocean | 15:37 |
| openstackgerrit | Ron De Rose proposed openstack/keystone: Make user to nonlocal_user a 1:1 relationship https://review.openstack.org/409946 | 15:37 |
| dstanek | the specs will be the roadmap to that vision | 15:37 |
| lbragstad | ayoung what exactly is the problem with defining a set of roles - this was the spec dolphm and jamielennox proposed | 15:37 |
| lbragstad | dstanek ++ | 15:37 |
| dstanek | I just want to understand the vision | 15:37 |
| lbragstad | dstanek right now I can't see what that is | 15:37 |
| ayoung | dstanek, it feels like we need a follow on spec, then, to capture these kinds of ideas | 15:37 |
| dstanek | Yeah, I've been capturing notes, but maybe in the policy meeting we can flesh it out more | 15:38 |
| ayoung | ++ | 15:38 |
| ayoung | dstanek, one big thing that edmondsw and I hashed out last week was defaults | 15:38 |
| ayoung | if we say that the default role for an operation is Member, without having to define each and every operation, it is a huge step forward | 15:39 |
| ayoung | then you can limit yourself to defining new api_roles only for the ones you want to deviate from the norm: those that require elevated, or those that you could grant to a read-only delegate | 15:40 |
| *** stingaci has joined #openstack-keystone | 15:40 | |
| dstanek | Sure, that makes sense | 15:42 |
| dstanek | Doc in here... Be back in a few | 15:42 |
| *** links has quit IRC | 15:42 | |
| *** stingaci has quit IRC | 15:44 | |
| *** adrian_otto has joined #openstack-keystone | 15:48 | |
| *** adrian_otto1 has quit IRC | 15:49 | |
| rderose | rodrigods: yeah, working on it | 15:50 |
| rderose | rodrigods: tough to test this one :) | 15:51 |
| rodrigods | rderose, :) | 15:51 |
| rodrigods | yeah... | 15:51 |
| *** spzala has joined #openstack-keystone | 15:54 | |
| lbragstad | ayoung outside of the fact that changing things in other projects is hard, was there another reason why introducing the read-only role didn't work? | 15:54 |
| ayoung | lbragstad, "other than that Mrs. O'Malley, how are things in Chicago?" | 15:54 |
| lbragstad | ayoung is that a no? | 15:55 |
| *** chris_hultin|AWA is now known as chris_hultin | 15:56 | |
| ayoung | lbragstad, I hadn't really thought about it, but, as I said before, it is not just hard, it is impossible, as the role you need has top be symnced across projects that we don;'t even know exists | 15:56 |
| ayoung | and tagged on every API | 15:57 |
| lbragstad | tagged on every api? | 15:57 |
| ayoung | So, I think that if you did that, you might be able to get a Read-only role | 15:57 |
| *** raildo has joined #openstack-keystone | 15:57 | |
| ayoung | lbragstad, every single API needs to say: only accept Member role, or accept the readonly role, | 15:58 |
| openstackgerrit | Merged openstack/keystone: Revert "API Documentation for user password expires" https://review.openstack.org/409923 | 15:58 |
| lbragstad | by tagged on every api you mean reflected properly in every projects policy.json file | 15:58 |
| edmondsw | ayoung reading back | 15:59 |
| ayoung | you guys are making me think. I need more coffee | 16:01 |
| lbragstad | ayoung if we had an approach before that didn't work i want to understand why and document it | 16:02 |
| dstanek | ayoung: lol | 16:04 |
| *** rcernin has quit IRC | 16:04 | |
| *** daemontool has joined #openstack-keystone | 16:07 | |
| edmondsw | ayoung note that I didn't suggest the default be member (since remember there isn't necessarily a member role in deployments), but rather that the default be to allow any role (i.e. fall back on policy) | 16:07 |
| rodrigods | rderose, for similar cases when you are reviewing: https://github.com/rodrigods/bug-fix-checker :) | 16:07 |
| lbragstad | edmondsw because that would still allow the policy.json file to do the rbac check | 16:07 |
| edmondsw | lbragstad yes | 16:08 |
| lbragstad | edmondsw do you ever have a case where the role check won't be reflective of the scope check? | 16:08 |
| edmondsw | lbragstad, not sure what you mean | 16:09 |
| *** pcaruana has quit IRC | 16:09 | |
| lbragstad | edmondsw like a true admin or owner rule | 16:09 |
| ayoung | edmondsw, noted. And I agree. However, we do also need to have something that we publish in a document or in code that gives the default setup, and the term Member has been used thus far. | 16:11 |
| lbragstad | edmondsw for example, if I have a user that has some non-admin role on a project and I'm able to create things. The check for those resources is admin_or_owner, . | 16:11 |
| *** jaosorior has quit IRC | 16:12 | |
| edmondsw | lbragstad I think so. I'm looking for one | 16:12 |
| *** jaosorior has joined #openstack-keystone | 16:13 | |
| openstackgerrit | Ron De Rose proposed openstack/keystone: Make user to nonlocal_user a 1:1 relationship https://review.openstack.org/409946 | 16:14 |
| edmondsw | lbragstad, so if I understand you correctly, an example would be nova's os-keypairs API... I want to set policy to allow admin or project_manager to view all keypairs but have a same-user scope check for other roles | 16:15 |
| lbragstad | edmondsw right | 16:15 |
| edmondsw | lbragstad, I'm not sure if nova will allow that today or has hardcoded some things around admin... was just starting to work on this | 16:15 |
| lbragstad | edmondsw right - it might not be possible today | 16:15 |
| lbragstad | edmondsw but our existing "owner" check is simply a "does this user have a role on this project" check | 16:16 |
| lbragstad | edmondsw and not a true ownership check | 16:16 |
| lbragstad | edmondsw but I assume we do have cases where a check like that would be useful | 16:16 |
| *** Ephur has joined #openstack-keystone | 16:16 | |
| *** tqtran has joined #openstack-keystone | 16:17 | |
| lbragstad | edmondsw as the owner of the resource I want to be able to do things to it, but i also want the admin (or the domain_admin etc..) to be able to access it | 16:17 |
| edmondsw | lbragstad the nova default for os-keypairs doesn't use admin_or_owner | 16:17 |
| edmondsw | it checks the user id | 16:17 |
| edmondsw | if not admin | 16:17 |
| rderose | rodrigods: got it: https://review.openstack.org/409946 | 16:18 |
| openstackgerrit | Merged openstack/keystone: API Documentation for user password expires https://review.openstack.org/409936 | 16:18 |
| rderose | rodrigods: thanks again | 16:18 |
| lbragstad | edmondsw so - what would happen if nova used keystonemiddleware with the RBAC check enabled? | 16:18 |
| lbragstad | edmondsw would it fail before the user check happens? | 16:18 |
| lbragstad | s/user check/user id check/ | 16:18 |
| edmondsw | lbragstad, you'd need to configure the middleware to allow all roles for os-keypairs in order for the nova default policy to work | 16:19 |
| edmondsw | so you're just passing the buck to policy in that case | 16:19 |
| lbragstad | edmondsw got it | 16:19 |
| edmondsw | and policy will work as it does today | 16:19 |
| lbragstad | edmondsw sure - but would that be the defacto standard for all checks like that? | 16:20 |
| edmondsw | yeah, I think any of those more complicated checks would just have to set the middleware to allow all roles | 16:20 |
| lbragstad | barbican would have usecases that fit into that model, too | 16:20 |
| edmondsw | forunately most policy checks aren't like that | 16:21 |
| *** tqtran has quit IRC | 16:21 | |
| lbragstad | edmondsw it would be nice if they were | 16:21 |
| *** Ephur has quit IRC | 16:21 | |
| edmondsw | lbragstad if they were, this spec would be pointless | 16:22 |
| lbragstad | edmondsw regardless of the spec | 16:22 |
| edmondsw | why would it be ice? | 16:22 |
| edmondsw | nice? | 16:22 |
| lbragstad | edmondsw wouldn't that type of granularity in checks be useful? | 16:23 |
| edmondsw | you CAN change things from the defaults if you need more granularity, but most of the time that's just not needed | 16:23 |
| lbragstad | you'd be able to have access to whatever based on who you are, but an admin still has the ability to do things to those resources | 16:23 |
| dstanek | So is the point of the spec to shortcut policy sometimes? | 16:24 |
| edmondsw | most of the time the decision is thumbs up or down based on role assignment + project | 16:24 |
| -openstackstatus- NOTICE: Launchpad SSO is not currently working, so logins to our services like review.openstack.org and wiki.openstack.org are failing; the admins at Canonical are looking into the issue but there is no estimated time for a fix yet. | 16:24 | |
| *** ChanServ changes topic to "Launchpad SSO is not currently working, so logins to our services like review.openstack.org and wiki.openstack.org are failing; the admins at Canonical are looking into the issue but there is no estimated time for a fix yet." | 16:24 | |
| lbragstad | edmondsw well - that's because the current solution doesn't provide a way to do it otherwise, right? | 16:24 |
| edmondsw | no, it does... but what else would you typically want to look at? | 16:25 |
| edmondsw | dstanek, essentially | 16:25 |
| lbragstad | edmondsw what if there were other things about a user that i wanted to roll into my checks? | 16:26 |
| lbragstad | edmondsw like attributes from a SAML assertion or something like that | 16:26 |
| edmondsw | lbragstad, you could do that today IFF the service exposing the API passed that information to oslo_context. | 16:27 |
| edmondsw | lbragstad though I don't think any are probably passing SAML assertion info today | 16:27 |
| edmondsw | it is all over the place what is or is not passed to oslo_context, which is one of the things that makes it very difficult to modify policy | 16:28 |
| *** jaosorior has quit IRC | 16:28 | |
| edmondsw | ayoung is tackling policy from a keystone perspective. I've been more tackling things from the other side and trying to push changes in nova, cinder, etc. Both may be needed | 16:29 |
| lbragstad | edmondsw sure - i understand that | 16:30 |
| lbragstad | edmondsw again - i'm looking at this as if it were possible, would it be used a lot | 16:30 |
| ayoung | lbragstad, so...admin_or_owner means two different things in different projects | 16:30 |
| ayoung | owner is either "I'm on the project" or "my userid matches the resource" | 16:30 |
| ayoung | in the first case, it is a check of project_id, the second of user_id | 16:31 |
| lbragstad | ayoung sure | 16:31 |
| ayoung | Keystone means it as user_id | 16:31 |
| edmondsw | ayoung, yeah, that's one of those unfortunate things where inconsistency causes confusion | 16:31 |
| ayoung | nova means it as project id | 16:31 |
| ayoung | so, in the case of Keystone, we would use the 'None' option for those URLs, and just let policy decide | 16:31 |
| ayoung | for Nova, we would set the default ot Member, unless you are edmondsw in which case you use "thingamambob" | 16:32 |
| ayoung | or wasit doohickey? | 16:32 |
| ayoung | I forget | 16:32 |
| lbragstad | ayoung in the keystone case, we'd let the RBAC check fall through to the policy.json check | 16:32 |
| edmondsw | ayoung you'd set the default to "" | 16:32 |
| ayoung | lbragstad, right | 16:32 |
| ayoung | edmondsw, nah, for Nova. You want it to "deployer" I think is what you had, right? | 16:32 |
| ayoung | things that are "owner" in Nova should be the base level "Here is what we expect most users to be able to do" | 16:33 |
| lbragstad | edmondsw if you set it to "" wouldn't that still just fall through? | 16:33 |
| ayoung | there is no "" | 16:33 |
| ayoung | There is None | 16:33 |
| ayoung | in my spec | 16:33 |
| ayoung | if it is a valid string, it has to match a role | 16:33 |
| lbragstad | sure - None or "" | 16:34 |
| ayoung | lbragstad, "" will error | 16:34 |
| lbragstad | regardless - you're letting the check fall through, right? | 16:34 |
| ayoung | Yers | 16:35 |
| ayoung | Yep | 16:35 |
| ayoung | WTF just happend to gerrit signin? | 16:36 |
| ayoung | "Provider is not supported, or was incorrectly entered." | 16:36 |
| lbragstad | ayoung launchpad SSO is currently broken | 16:36 |
| ayoung | rapture | 16:37 |
| ayoung | http://docs-draft.openstack.org/24/391624/21/check/gate-keystone-specs-docs-ubuntu-xenial/258e8d3//doc/build/html/specs/keystone/ongoing/role-check-from-middleware.html#object-schema | 16:38 |
| ayoung | looks like I lost the sub-heading I had for these types of rules... | 16:39 |
| ayoung | http://docs-draft.openstack.org/24/391624/21/check/gate-keystone-specs-docs-ubuntu-xenial/258e8d3//doc/build/html/specs/keystone/ongoing/role-check-from-middleware.html#api-role | 16:39 |
| ayoung | lbragstad, so under ^^ there is the line | 16:39 |
| ayoung | "If there are no api_role entities definied for an api entity, the result will have a special value of None for the roles will indicate that the no Role is required, and that the entire token role check can be skipped." | 16:39 |
| ayoung | { "service": "identity", "pattern": "/v", "verb": "GET" role: None} for discover for example | 16:40 |
| lbragstad | ok | 16:40 |
| *** aselius has joined #openstack-keystone | 16:40 | |
| ayoung | we'll need to use lines like that for the unscoped operations | 16:40 |
| lbragstad | but well also need to use them whenever an operation requires a check of the user attributes | 16:41 |
| ayoung | lbragstad, only if we want to bypass the role check | 16:41 |
| lbragstad | like nova's api key example | 16:41 |
| lbragstad | or keystone admin_or_owner check | 16:41 |
| ayoung | lbragstad, are api keys scoped to a project? | 16:41 |
| lbragstad | ayoung edmondsw just confirmed that nova checks the user's id if they aren't admin | 16:42 |
| ayoung | lbragstad, we can make liberal use of them to start. RBAC "tightens up" access, so it won't make things more permissive than they were before | 16:42 |
| ayoung | the minimun effect is "no change" or "denial" | 16:42 |
| lbragstad | or if barbican wanted to implemented some sort of admin_or_owner check similar to what keystone has, or what nova has | 16:43 |
| *** chlong has joined #openstack-keystone | 16:46 | |
| ayoung | https://paste.fedoraproject.org/505835/48164759/ | 16:46 |
| ayoung | "admin_or_owner": "rule:global_admin or project_id:%(project_id)s" | 16:47 |
| edmondsw | ayoung right... but see the os-keypairs rules | 16:49 |
| *** asettle__ has joined #openstack-keystone | 16:49 | |
| ayoung | edmondsw, right. And those are actually a mistake. | 16:50 |
| edmondsw | ayoung a mistake? | 16:50 |
| ayoung | I can't createa vm and then add your key to that VM, so you can log in | 16:50 |
| lbragstad | https://github.com/openstack/nova/blob/master/nova/policies/keypairs.py#L25-L44 | 16:50 |
| ayoung | edmondsw, the way that keys are managed in Nova assumes that only the holder of the private key ever wants to stick them in a VM | 16:50 |
| ayoung | which is not actually the case | 16:50 |
| edmondsw | ayoung, yeah, that makes sense... I can open a bug and submit a patch for that and we'll see what nova says | 16:51 |
| edmondsw | I have a feeling they'll argue (they usually do), but I'd agree with you | 16:51 |
| ayoung | edmondsw, go for it. There are closer windmills for me to tilt at first | 16:51 |
| edmondsw | I've been submitting some other nova policy changes lately, and getting some traction, so maybe I've built up enough good will :) | 16:52 |
| ayoung | http://www.alonzoquixano.com/wp-content/uploads/2014/12/dq.jpg | 16:52 |
| lbragstad | but that's only for showing api keys | 16:52 |
| lbragstad | I wouldn't want someone on the project to delete my api key, i'd still want to have my user id checked in that case | 16:52 |
| edmondsw | lbragstad true... ayoung, that would only be to view them... the update/delete would still have to check user_id | 16:52 |
| ayoung | why? | 16:53 |
| edmondsw | seriously? | 16:53 |
| lbragstad | ayoung if we are on the same project i don't want you to be able to delete my api key | 16:53 |
| *** asettle has quit IRC | 16:53 | |
| ayoung | because the api key should be in the Keystone database | 16:53 |
| lbragstad | I want to manage my own keys | 16:53 |
| edmondsw | worse, I don't want you to be able to replace it with one that you have the private key for | 16:53 |
| ayoung | and there it is managed by you, and then on Nova it is a mapping from user to project based on your role assignments | 16:53 |
| ayoung | I've long thought about this, but have no stomach for the fight | 16:54 |
| edmondsw | ayoung I didn't follow that | 16:54 |
| lbragstad | me either | 16:54 |
| ayoung | OK... a user should have a key as a credential in Keystone. | 16:56 |
| ayoung | when a user joins a project, they can add that key to the project | 16:56 |
| ayoung | when a user creates a vm in a project, they should be able to include any keys that are part of that project | 16:56 |
| ayoung | so, yeah, I should not be able to redefine the "lbrastad" key | 16:57 |
| ayoung | but I should be able to read it | 16:57 |
| ayoung | and an admin should be able to remove it from the project | 16:57 |
| lbragstad | ayoung right - i think we agree on that | 16:57 |
| ayoung | or add an additional one from Keystone | 16:57 |
| ayoung | so, yeah, there are going to be a bunch of funky APIs out there | 16:57 |
| ayoung | the best we can do is provide a means for the RBAC check to get out of the way of them and let them continue to process as is | 16:58 |
| ayoung | the Key API is a great example of stuff that should add the member role onto the policy | 16:58 |
| ayoung | leave the user check in place, as that is what Nova wants | 16:58 |
| ayoung | regardless of what we thinkg | 16:58 |
| ayoung | but only a member should be able to add a key to a proejct | 16:58 |
| ayoung | or remove one | 16:58 |
| ayoung | even if that is their own key | 16:58 |
| edmondsw | s/only a member/anyone/ | 16:59 |
| ayoung | the way the policy is written right now, there is no way to make a reader role that could check the key | 16:59 |
| ayoung | no, only a member | 16:59 |
| edmondsw | ? | 16:59 |
| ayoung | edmondsw, if I have a user with an auditor role, they should not be able to create or delete keys | 16:59 |
| ayoung | even with their own userid | 16:59 |
| *** rcernin has joined #openstack-keystone | 17:00 | |
| edmondsw | ayoung, sure, you're drawing a distinction between the default (anyone, because auditor role doesn't exist by default) and what someone might do in practice | 17:00 |
| ayoung | yes | 17:00 |
| *** ChanServ changes topic to "Meeting Agenda: https://etherpad.openstack.org/p/keystone-weekly-meeting | Ocata goals: https://docs.google.com/spreadsheets/d/156q820cXcEc8Y9YWQgoc_hyOm3AZ2jtMQM3zdDhwGFU/edit?usp=sharing" | 17:01 | |
| -openstackstatus- NOTICE: Canonical admins have resolved the issue with login.launchpad.net, so authentication should be restored now. | 17:01 | |
| ayoung | I am also draw a distinction between what is possible to do now and what we can add with an external layer, without touching the policy files, and breaking the existing checks | 17:01 |
| *** asettle__ is now known as asettle | 17:01 | |
| dstanek | ayoung: a agree that we don't to break anyone, but as we imagine what should be implemented i don't want to be burdoned by that | 17:02 |
| dstanek | we can throw out the parts of our grand scheme that won't work later. as well as provide a transition to the parts that will | 17:02 |
| dstanek | using nova is great for driving usecases, but i'd like to not be hindered by it when defining the vision | 17:03 |
| ayoung | dstanek, you could put in a default that says 'for all APIS, skip the RBAC check" and things will work exactly as they do now, no check | 17:03 |
| ayoung | you could then add,. one by one, explicit checks for some APIs that you want to have a lower role than Member...the read only cases | 17:04 |
| ayoung | but those would still slip by on the None rules | 17:04 |
| dstanek | so, in our future state we want distributed role checks (via middleware), localized policy checks (via keystone) and distributed policy checks (via oslo.policy) for each service request.... is that accurate? | 17:05 |
| ayoung | So you need a decent default, and then identify the exceptions to it | 17:05 |
| *** waj334 has joined #openstack-keystone | 17:06 | |
| ayoung | dstanek, I am not sure I agree with " localized policy checks (via keystone)" unless you are really referring to the " distributed role checks (via middleware)" | 17:06 |
| waj334 | https://etherpad.openstack.org/p/d7afjZnl6Y | 17:06 |
| ayoung | keystone should not be different than the other services for this | 17:06 |
| *** htruta` is now known as htruta | 17:07 | |
| *** mvk has quit IRC | 17:07 | |
| dstanek | ayoung: from what i gathered so far a request to nova will first have a role check in middleware, then a possible call to keystone for policy and then a fall thru to oslo.policy on the service | 17:07 |
| ayoung | the " possible call to keystone for policy" no longer exists | 17:08 |
| ayoung | it was either/or with the role-check in middleware | 17:08 |
| ayoung | and we scrapped it | 17:08 |
| lbragstad | ayoung but the middleware has to get the roles of an operation | 17:08 |
| dstanek | so the middleware will grab the policy rules from keystone? | 17:08 |
| edmondsw | I've gotta grab something to eat... | 17:08 |
| ayoung | Validate a token from Keystone, RBAC check in middleware, policy check from service specific code | 17:08 |
| ayoung | lbragstad, dstanek the call to keystone is to grab the api_roles for the RBAC check | 17:09 |
| dstanek | ayoung: so the future of policy is to keep the policy files around more or less as-is? | 17:09 |
| ayoung | so no check happens in Keystone at that time, except perhaps to say that the remote services is allowed to grab the api_roles file | 17:09 |
| lbragstad | ayoung the RBAC check you're referring to is comparing the roles included in the token validation response to the roles required for an operation | 17:09 |
| ayoung | dstanek, yes | 17:09 |
| ayoung | lbragstad, yes | 17:10 |
| waj334 | Sorry for the random etherpad link, but I just need some insight on this authentication issue I'm having | 17:10 |
| lbragstad | ayoung so the "possible call to keystone for policy" does exist | 17:11 |
| lbragstad | it's the RBAC middleware check | 17:11 |
| lbragstad | specifically, part of the RBAC middleware check | 17:11 |
| openstackgerrit | Richard Avelar proposed openstack/keystone: Add id to conflict error if caused by duplicate id https://review.openstack.org/409010 | 17:11 |
| ayoung | lbragstad, let me rewrite what dstanek put to correct it: | 17:11 |
| dstanek | ayoung: so what's the short, short reason to add role checks to middleware at all if they are likely also in policy? just to trim down the policy files for the defaults? | 17:12 |
| ayoung | a request to nova will first, in middleware, validate the token, then fetch the RBAC rules from Keysonte, and then perform a role check. After that, it will pass controll to the Nova service which will perform a policy check | 17:13 |
| ayoung | dstanek, so, adding them to policy is really hard | 17:13 |
| ayoung | nova, today, has embedded the policy into code | 17:13 |
| ayoung | and making them consistant across all of the services is really problematic | 17:13 |
| ayoung | so, I don't forsee there being any expansion of the current Role checks in policy | 17:14 |
| dstanek | i think you've hightlighed another problem with URLs. a policy writer (maybe even a domain admin) will have to now policy targets (operations), but also URLs | 17:14 |
| ayoung | dstanek, except that the domain admin/policy writer will not do anything with the underlying policy files | 17:15 |
| ayoung | they will *only* work with the URLs | 17:15 |
| *** asettle has quit IRC | 17:15 | |
| ayoung | and those can be tested | 17:15 |
| dstanek | in the discussions that led up to the CP meeting for policy i heard more of a need for change. better way to deploy, maybe a better policy language, etc. | 17:15 |
| ayoung | external of any tool, a user can always tell what URL they are calling | 17:15 |
| ayoung | the same is not true of policy files | 17:15 |
| ayoung | dstanek, think of policy as SELinux. | 17:15 |
| ayoung | I'm trying to add the Unix file system permissions on top of that | 17:16 |
| ayoung | and prevent people from having to mess with SELinux policy | 17:16 |
| * dstanek thinks ayoung uses curl too much. dstanek has no idea what URL is being used when interacting with OpenStack | 17:16 | |
| ayoung | dstanek, you can always see the URL when you use the CLI and pass --debug | 17:16 |
| dstanek | ayoung: but i don't need to. or at least never have in the past. | 17:16 |
| ayoung | you could see it using wireshark | 17:16 |
| dstanek | it's an implementation detail that i shouldn't care about | 17:17 |
| ayoung | dstanek, have you ever had to set up an autonomous service to perform an operation for you in an openstack deployment? | 17:17 |
| ayoung | specificaloly, in one in which you have an admin role | 17:17 |
| ayoung | ? | 17:17 |
| dstanek | you mean have a thing that interacts with a cloud as an admin? | 17:18 |
| ayoung | dstanek, that too | 17:19 |
| dstanek | sure. | 17:20 |
| *** markvoelker has quit IRC | 17:20 | |
| ayoung | dstanek, if you want to do some operation against a service, something you don't know anything about, like, say Trove or Sahara (just guessing, sorry if you know these) how do you know what permissions you need to perform that operation? | 17:20 |
| ayoung | Today, you don't | 17:20 |
| ayoung | I mean, yeah, you could go crawl the code, and you and I are familiar enough that we could probably find out the defaults | 17:21 |
| ayoung | but there is no way for a deployer to advertise "we'ver changed from Member to Performer" for this | 17:21 |
| ayoung | or DBA | 17:21 |
| ayoung | or Hadooper | 17:21 |
| ayoung | and thus you need to create a token as admin, as that is all you know | 17:21 |
| *** markvoelker has joined #openstack-keystone | 17:22 | |
| ayoung | now, ideally you could at least create a trust with just "Member" on it and use that token | 17:22 |
| ayoung | and if you have to set up some autonomys system, the same is true: | 17:22 |
| ayoung | it creates a trust with a subset of your roles | 17:22 |
| ayoung | but...none of the information needed to make that happen is available to the end user | 17:23 |
| dstanek | ayoung: in my ideal world i'd as what a token can do and get back a list like ['instance:create', 'instance:delete', ...] | 17:23 |
| ayoung | so, as an admin, you end up exposing the complete set of control in your cloud to every service | 17:23 |
| ayoung | dstanek, so, we are back to resource level roles. We can absolutelty head toward that | 17:23 |
| ayoung | so what we need is a way to say that "Member implies instance:delete" | 17:24 |
| ayoung | we have that with implied roles | 17:24 |
| dstanek | ayoung: why can't this work for any roles? | 17:24 |
| ayoung | dstanek, it can | 17:24 |
| ayoung | it is just a UI issue | 17:24 |
| *** rcernin has quit IRC | 17:24 | |
| ayoung | when adding a user to a proejct in a webui, or on the CLI, you want to have a reasonable list to pick from | 17:24 |
| ayoung | not every single API in the the catalog | 17:24 |
| ayoung | bad UX | 17:24 |
| dstanek | i'd also what to query with what 'instance:*' stuff can i do with this token | 17:25 |
| ayoung | dstanek, and that is why implied roles were so important. | 17:25 |
| ayoung | hint hint https://review.openstack.org/#/c/290253/ | 17:25 |
| ayoung | dstanek, So, with implied roles, and the api_role mechanism, we can get that information | 17:26 |
| ayoung | yes. it will be URL based, not policy based, but the URLs are what is documented in the api-refs | 17:26 |
| dstanek | ayoung: that why i was thinking that policy should be centrally administered even if it is enfoced by each service | 17:26 |
| ayoung | http://developer.openstack.org/api-guide/quick-start/index.html | 17:26 |
| ayoung | dstanek, even if that were the case, I would advocate splitting RBAC from the rest of it. | 17:27 |
| ayoung | policy is too easy to break | 17:27 |
| ayoung | it is a floor below which we should not pass | 17:27 |
| ayoung | RBAC is a ceiling. | 17:27 |
| dstanek | ayoung: and that's OK....i just want all of this documented in a way that doesn't tie us to the current implementations | 17:28 |
| dstanek | we can debate the particulars after everyone has a shared vision | 17:28 |
| ayoung | dstanek, cool. I think we are on track | 17:28 |
| ayoung | dstanek, just do not underestimate the inertia in the rest of openstack | 17:29 |
| dstanek | ayoung: i hope so :-) i'm just trying to understand where you want us to go | 17:29 |
| ayoung | especially the momentum of Nova. | 17:29 |
| dstanek | ayoung: that's why we have to be quick with our assessment | 17:29 |
| ayoung | dstanek, agreed. And that is why I've been such a noodge with this spec | 17:30 |
| ayoung | dstanek, do you understand the design constraints I've been trying to dance within? | 17:30 |
| dstanek | ayoung: yeah, sorta. i'm just looking to see the solution without those constraints | 17:31 |
| dstanek | if i had a brand new thing what would it look like | 17:31 |
| ayoung | dstanek, good question. But I think it would almost have to look like this spec. | 17:32 |
| ayoung | This spec does scoped RBAC | 17:32 |
| ayoung | if you wanted to do unscoped RBAC, that would work fine this way as well | 17:32 |
| ayoung | and, if you needed an additional role check once you got an object out of the database that would work too | 17:32 |
| ayoung | those are both subsets of the scoped rbac approach | 17:33 |
| dstanek | when you say scoped rbac what do you mean? | 17:33 |
| ayoung | dstanek, so NIST rbac does not have anythign like out projects | 17:33 |
| ayoung | the roles are global | 17:34 |
| ayoung | the RBAC we are doing in Keystone means that the role name itself is not the whole access attribute | 17:34 |
| ayoung | instead it is the tuple of role, projectid | 17:34 |
| ayoung | or domain id... | 17:34 |
| dstanek | right... ok, gotcha | 17:35 |
| ayoung | cool | 17:35 |
| dstanek | is that a standard term? | 17:35 |
| ayoung | so, if and access control has to be done based on the objects out of the database, you have to fetch the object first. | 17:35 |
| *** rcernin has joined #openstack-keystone | 17:35 | |
| *** rcernin has quit IRC | 17:35 | |
| ayoung | dstanek, scoped RBAC? No it is not a standard term | 17:35 |
| ayoung | it was a term that emerged out of discussions about NIST RBAC | 17:36 |
| ayoung | the thing about RBAC is that is assumes the scope is "for this application" or "for this organization" | 17:36 |
| ayoung | so the scoping is implicit | 17:36 |
| dstanek | will any of this get us closer to allowing a domain admin to create their own roles? | 17:36 |
| ayoung | but cloud means scale, and we need a repeatable pattern | 17:36 |
| ayoung | dstanek, domain_specific roles are already a reality | 17:36 |
| ayoung | but those roles cannot directly be used to perform access control | 17:37 |
| ayoung | instead, they need to map to a global role | 17:37 |
| ayoung | and, if we add on this spec, the gloval role then maps to an api_role object which is what provides access | 17:38 |
| dstanek | ayoung: that's what i mean i thought we wanted more flexibiltiy there | 17:38 |
| ayoung | so, with this approach, here is how it would go | 17:38 |
| ayoung | say a domain admin needs a role that can only perform a single op | 17:38 |
| ayoung | say, reboot_server | 17:38 |
| ayoung | they find the API they need to execute, and see that, today it has only the Member role in the api_role table | 17:39 |
| ayoung | so they ask the admin to create a new role, called rebootvm and have Member imply that role | 17:39 |
| ayoung | if a cloud admin makes that change, and then changes the api_role such that it requires rebootvm instead of Member, nothing breaks | 17:39 |
| ayoung | now, the domain admin can create a domain specific role, or they can use the global role, whichever they prefer, for rebootvm | 17:40 |
| ayoung | in essence, a domain specific role is only as powerful as the granularity of the global roles | 17:40 |
| ayoung | which means, at the extreme, we have one role per api | 17:40 |
| ayoung | when we start heading there, we need a way to better list the roles. | 17:41 |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Federated authentication via ECP functional tests https://review.openstack.org/324769 | 17:43 |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Settings for test cases https://review.openstack.org/410205 | 17:43 |
| ayoung | dstanek, so, one thing we could do in Keystone is, when we have a an entry like this: http://git.openstack.org/cgit/openstack/keystone/tree/keystone/assignment/routers.py#n114 we could put in the expected role there | 17:44 |
| knikolla | rodrigods: great work! | 17:46 |
| rodrigods | knikolla, let's hope it works | 17:47 |
| dstanek | ayoung: i need to reflect on this a little :) | 17:47 |
| knikolla | rodrigods: let's hope. patchset 24 passed, but it had skipped the saml2ecpfederation tests | 17:50 |
| rodrigods | knikolla, yeah | 17:50 |
| rodrigods | it wasn't setting the tempest configs | 17:50 |
| lbragstad | ayoung wouldn't that require redeploying policy files, too? | 17:52 |
| dstanek | ayoung: in your experience does any non-service developer use the api-ref? i use it for keystone, but i work on keystone. i don't use it when interactive with nova or other services | 17:53 |
| knikolla | dstanek: i have it bookmarked and consult it very often for cinder/glance, which i don't work on. | 17:55 |
| dstanek | knikolla: why? | 17:56 |
| *** chrisplo has joined #openstack-keystone | 17:57 | |
| knikolla | dstanek: i maintain a proxy that does k2k between services. | 17:58 |
| *** henrynash has joined #openstack-keystone | 17:59 | |
| *** ChanServ sets mode: +v henrynash | 17:59 | |
| stevemar | meeting time! | 17:59 |
| dstanek | knikolla: that's a very specific developer case. not the case of someone just using nova right? | 18:00 |
| lbragstad | dstanek i would think so | 18:00 |
| knikolla | dstanek: true. outside of that specific use case, i've found the python clients to be enough for 99% of purposes. | 18:01 |
| knikolla | that 1% has been using keystone with an unscoped token for changing a user password. the client doesn't play nicely with unscoped tokens there. | 18:02 |
| ayoung | edmondsw, wannt to join #openstack-meeting? | 18:04 |
| edmondsw | ayoung sure, just walked back into the office | 18:04 |
| *** henrynash has quit IRC | 18:06 | |
| *** tqtran has joined #openstack-keystone | 18:06 | |
| *** henrynash has joined #openstack-keystone | 18:06 | |
| *** ChanServ sets mode: +v henrynash | 18:06 | |
| dstanek | knikolla: that's what i expected | 18:07 |
| *** daemontool has quit IRC | 18:08 | |
| *** stingaci has joined #openstack-keystone | 18:10 | |
| *** asettle has joined #openstack-keystone | 18:14 | |
| *** stingaci has quit IRC | 18:14 | |
| *** ravelar has quit IRC | 18:19 | |
| *** spilla has joined #openstack-keystone | 18:20 | |
| *** pnavarro has quit IRC | 18:21 | |
| *** edtubill has quit IRC | 18:21 | |
| *** stingaci has joined #openstack-keystone | 18:34 | |
| *** henrynash has quit IRC | 18:36 | |
| *** henrynash has joined #openstack-keystone | 18:36 | |
| *** ChanServ sets mode: +v henrynash | 18:36 | |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Federated authentication via ECP functional tests https://review.openstack.org/324769 | 18:37 |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Settings for test cases https://review.openstack.org/410205 | 18:37 |
| *** henrynash has quit IRC | 18:40 | |
| *** henrynash has joined #openstack-keystone | 18:41 | |
| *** ChanServ sets mode: +v henrynash | 18:41 | |
| *** ravelar has joined #openstack-keystone | 18:48 | |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Do not manually remove /etc/shibboleth2 folder https://review.openstack.org/410356 | 18:48 |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Do not manually remove /etc/shibboleth folder https://review.openstack.org/410356 | 18:49 |
| *** ravelar has quit IRC | 18:51 | |
| *** itisha has joined #openstack-keystone | 18:55 | |
| stevemar | rderose: want to chat about the idp:domain stuff? | 19:00 |
| ayoung | stevemar, care to re-add your +2 to https://review.openstack.org/#/c/391624/ as I didn't want to presume | 19:00 |
| stevemar | ayoung: added | 19:01 |
| *** narasimha_SV has quit IRC | 19:01 | |
| stevemar | ayoung: i'm open to keeping it alive for the rest of the week and merging it regardless on friday | 19:01 |
| *** henrynash has quit IRC | 19:01 | |
| stevemar | ayoung: you can work on the impl assuming it's approved | 19:01 |
| ayoung | stevemar, I'd rather have it approved with the understanding that we will accept edits | 19:02 |
| ayoung | dstanek, and lbragstad should -2 it now it they want to hold it. | 19:02 |
| stevemar | ayoung: right, was just going to say | 19:02 |
| stevemar | ayoung: give them til EOD to -2 it, otherwise (even if they -1 it) i'll punch it through | 19:03 |
| stevemar | dstanek: lbragstad -- speak now or forever hold your peace | 19:03 |
| lbragstad | stevemar in a meeting | 19:03 |
| ayoung | stevemar, TYVM. I'll hold off on any more edits | 19:03 |
| stevemar | lbragstad: rgr that | 19:04 |
| stevemar | ayoung: np | 19:04 |
| *** asettle has quit IRC | 19:08 | |
| *** rcernin has joined #openstack-keystone | 19:14 | |
| dstanek | edmondsw: lb: https://etherpad.openstack.org/p/keystone-policy-usecases | 19:22 |
| *** henrynash has joined #openstack-keystone | 19:25 | |
| *** ChanServ sets mode: +v henrynash | 19:25 | |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Federated authentication via ECP functional tests https://review.openstack.org/324769 | 19:26 |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Settings for test cases https://review.openstack.org/410205 | 19:26 |
| *** stingaci has quit IRC | 19:28 | |
| *** stingaci has joined #openstack-keystone | 19:29 | |
| *** henrynash has quit IRC | 19:30 | |
| *** diazjf has joined #openstack-keystone | 19:31 | |
| ayoung | dstanek, http://kubernetes.io/docs/admin/authorization/ looking at what Kubernetes does for comparison. Looks like they map it per URL | 19:36 |
| ayoung | nonResourcePath, type string; matches the non-resource request paths (like /version and /apis). * matches all non-resource requests. /foo/* matches /foo/ and all of its subpaths. | 19:36 |
| ayoung | not sure if it is any more mature than what openstack does | 19:36 |
| dstanek | stevemar: in a meeting too :-( | 19:40 |
| *** jaugustine has quit IRC | 19:46 | |
| *** spzala has quit IRC | 19:57 | |
| *** jaugustine has joined #openstack-keystone | 19:58 | |
| openstackgerrit | Steve Martinelli proposed openstack/keystone: Add id to conflict error if caused by duplicate id https://review.openstack.org/409010 | 20:00 |
| openstackgerrit | Steve Martinelli proposed openstack/keystone: Add id to conflict error if caused by duplicate id https://review.openstack.org/409010 | 20:01 |
| *** tobberydberg has joined #openstack-keystone | 20:02 | |
| *** Zer0Byte__ has joined #openstack-keystone | 20:08 | |
| *** spzala has joined #openstack-keystone | 20:10 | |
| *** amoralej is now known as amoralej|off | 20:17 | |
| *** diazjf has quit IRC | 20:19 | |
| *** ravelar has joined #openstack-keystone | 20:25 | |
| openstackgerrit | Steve Martinelli proposed openstack/keystone: Refactors _get_names_from_role_assignments https://review.openstack.org/408074 | 20:32 |
| *** diazjf has joined #openstack-keystone | 20:39 | |
| *** nklenke has quit IRC | 20:47 | |
| *** raildo has quit IRC | 20:51 | |
| *** gyee has joined #openstack-keystone | 20:52 | |
| *** gyee has quit IRC | 20:52 | |
| *** gyee has joined #openstack-keystone | 20:53 | |
| rodrigods | stevemar, tests are passing! | 21:01 |
| rodrigods | knikolla, ^ | 21:01 |
| rodrigods | dstanek, ayoung ^ | 21:02 |
| rodrigods | https://review.openstack.org/#/c/324769/ | 21:02 |
| rodrigods | see my last comment for details on why the job is failing | 21:02 |
| *** spzala_ has joined #openstack-keystone | 21:09 | |
| *** tobberydberg has quit IRC | 21:11 | |
| knikolla | rodrigods: oh, right, that bug. | 21:11 |
| rodrigods | knikolla, yeah... so one tests fails to clean up the env and the next one fails because the env is not clean | 21:12 |
| *** spzala has quit IRC | 21:12 | |
| rodrigods | knikolla, the coolest part is everything working fine against testshib | 21:13 |
| rodrigods | metadata registration, included | 21:14 |
| *** dgonzalez has quit IRC | 21:14 | |
| knikolla | rodrigods: great work! metadata registration was surprising, as it was only a post call. | 21:15 |
| knikolla | i expected more complicated things. | 21:15 |
| rodrigods | yeah... | 21:15 |
| knikolla | rodrigods: do we want a separate job for k2k? | 21:16 |
| *** chris_hultin is now known as chris_hultin|AWA | 21:16 | |
| rodrigods | knikolla, hmm maybe? | 21:16 |
| rodrigods | ideally we would have separate jobs for different deployments | 21:16 |
| rodrigods | i want to rename this one to include "federation" on it | 21:17 |
| knikolla | rodrigods: separate one would be easier in the mod_shib configuration. | 21:18 |
| knikolla | i can probably recycle the k2k-idp part as is from my previous plugin. | 21:18 |
| knikolla | this is looking good for ocata though :) | 21:19 |
| rodrigods | knikolla, ++ | 21:19 |
| *** asettle has joined #openstack-keystone | 21:21 | |
| morgan | stevemar: are you good with a simple context manager example for KSA | 21:28 |
| morgan | as docs? | 21:28 |
| *** chlong has quit IRC | 21:30 | |
| *** amoralej|off is now known as amoralej | 21:36 | |
| *** asettle has quit IRC | 21:39 | |
| *** diazjf has quit IRC | 21:47 | |
| openstackgerrit | Richard Avelar proposed openstack/keystone: Add id to conflict error if caused by duplicate id https://review.openstack.org/409010 | 21:50 |
| stevemar | rodrigods: can you use the same topic for the federated identity work if possible | 21:57 |
| stevemar | fed. identitiy functional tests* | 21:57 |
| rodrigods | stevemar, ++ | 21:57 |
| stevemar | rodrigods: it's hard to find all the related work | 21:57 |
| rodrigods | stevemar, will update everything | 21:57 |
| rodrigods | just a sec | 21:57 |
| stevemar | rodrigods: danke | 21:58 |
| stevemar | rodrigods: and we probably have a blueprint you can reference i would think | 21:58 |
| *** asettle has joined #openstack-keystone | 21:58 | |
| stevemar | meh, less of a concern | 21:58 |
| rodrigods | stevemar, https://review.openstack.org/#/q/status:open+branch:master+topic:federated_identity_functional_tests | 21:59 |
| antwash | dolphm : ping? | 22:00 |
| knikolla | stevemar, rodrigods: i was using the keystone-functional-testing topic :/ | 22:01 |
| *** amoralej is now known as amoralej|off | 22:01 | |
| *** diazjf has joined #openstack-keystone | 22:03 | |
| *** chris_hultin|AWA is now known as chris_hultin | 22:08 | |
| lbragstad | stevemar did you happen to attend this session in barcelona? https://etherpad.openstack.org/p/ocata-xp-unified-capabilities-api | 22:09 |
| *** asettle has quit IRC | 22:09 | |
| *** spilla has quit IRC | 22:13 | |
| *** chris_hultin is now known as chris_hultin|AWA | 22:19 | |
| lbragstad | ayoung ^ | 22:21 |
| openstackgerrit | Samuel Pilla proposed openstack/keystone: Add password expiration queries for PCI-DSS https://review.openstack.org/403898 | 22:21 |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Federated authentication via ECP functional tests https://review.openstack.org/324769 | 22:26 |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Settings for test cases https://review.openstack.org/410205 | 22:26 |
| stevemar | rodrigods maybe use the topic knikolla mentioned instead ;) | 22:27 |
| stevemar | lbragstad: looking.. | 22:27 |
| stevemar | lbragstad: i did not | 22:27 |
| *** dgonzalez has joined #openstack-keystone | 22:27 | |
| rodrigods | stevemar, --' | 22:28 |
| rodrigods | stevemar, let's approve everything! | 22:28 |
| stevemar | rodrigods: maybe not everything :) | 22:28 |
| *** edmondsw has quit IRC | 22:28 | |
| lbragstad | stevemar nova and cinder are both working towards writing capability discovery APIs, and one of the main use cases I'm see is the ability to give nova or cinder a token and say "what can I do?" | 22:28 |
| lbragstad | which surely has overlap with the rbac in middleware spec | 22:29 |
| lbragstad | seeing* | 22:29 |
| rodrigods | knikolla, stevemar https://review.openstack.org/#/q/topic:keystone-functional-testing | 22:29 |
| *** lamt has quit IRC | 22:31 | |
| *** mvk has joined #openstack-keystone | 22:32 | |
| openstackgerrit | Richard Avelar proposed openstack/keystone: Add checks for doctor credential symptoms https://review.openstack.org/409289 | 22:32 |
| *** edmondsw_ has joined #openstack-keystone | 22:32 | |
| *** adriant has joined #openstack-keystone | 22:32 | |
| *** lamt has joined #openstack-keystone | 22:33 | |
| *** gyee has quit IRC | 22:35 | |
| *** edmondsw_ has quit IRC | 22:37 | |
| openstackgerrit | Richard Avelar proposed openstack/keystone: Add checks for doctor credential symptoms https://review.openstack.org/409289 | 22:38 |
| *** spzala_ has quit IRC | 22:40 | |
| lbragstad | stevemar dstanek ayoung - https://review.openstack.org/#/c/306930/12/specs/newton/discovering-system-capabilities.rst | 22:40 |
| lbragstad | has anyone been involved with that ^ | 22:40 |
| dstanek | not i | 22:41 |
| lbragstad | dstanek thats a really good write up | 22:41 |
| ayoung | lbragstad, let them drive one with it | 22:41 |
| ayoung | Ithink it might end up solving part of our problem | 22:41 |
| dstanek | but i do remember hearing about the concept at a summit | 22:41 |
| lbragstad | ayoung i wasn't planning on stopping them from working on it at all | 22:42 |
| lbragstad | or shooting down the idea - I'm just finding some of this out from talking to nova developers | 22:42 |
| ayoung | lbragstad, nah wasn't impying that,just that they can flesh out the idea and we'll let them. I think they are on the right track, it aligns with what we discussed earlier | 22:43 |
| lbragstad | i'm going to poke in their channel to see if there has been any progress on the policy side, specific to roles - since they define that on line 122 | 22:46 |
| *** jaugustine has quit IRC | 22:47 | |
| *** diazjf has quit IRC | 22:49 | |
| *** adrian_otto has quit IRC | 22:50 | |
| *** henrynash has joined #openstack-keystone | 22:56 | |
| *** ChanServ sets mode: +v henrynash | 22:56 | |
| *** henrynash has quit IRC | 22:58 | |
| ayoung | lbragstad, https://review.openstack.org/#/c/350310/ | 23:06 |
| ayoung | Not since september | 23:06 |
| ayoung | rodrigods, care to do the honors on https://review.openstack.org/#/c/391624/ ? | 23:09 |
| rodrigods | ayoung, not at all, wasn't going to wait until eow? | 23:17 |
| ayoung | rodrigods, nah, end of the day | 23:18 |
| rodrigods | done! :) | 23:18 |
| rodrigods | ayoung, have something for you too: https://review.openstack.org/#/c/410356/ | 23:18 |
| rodrigods | a easy one | 23:18 |
| ayoung | rodrigods, done | 23:21 |
| openstackgerrit | Merged openstack/keystone-specs: Role Check from Middleware https://review.openstack.org/391624 | 23:23 |
| *** edmondsw has joined #openstack-keystone | 23:27 | |
| *** edmondsw has quit IRC | 23:31 | |
| *** agrebennikov_ has quit IRC | 23:32 | |
| *** stingaci has quit IRC | 23:40 | |
| *** spzala has joined #openstack-keystone | 23:40 | |
| *** edmondsw has joined #openstack-keystone | 23:47 | |
| rderose | stevemar: you still around? | 23:47 |
| *** chris_hultin|AWA is now known as chris_hultin | 23:52 | |
| *** edmondsw has quit IRC | 23:52 | |
| *** spzala has quit IRC | 23:54 | |
| *** spzala has joined #openstack-keystone | 23:54 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
