| opendevreview | OpenStack Proposal Bot proposed openstack/keystone master: Imported Translations from Zanata https://review.opendev.org/c/openstack/keystone/+/1007372 | 03:19 |
|---|---|---|
| opendevreview | Grzegorz Grasza proposed openstack/keystone-specs master: Propose consumer-bound EC2 credentials https://review.opendev.org/c/openstack/keystone-specs/+/1010380 | 09:58 |
| opendevreview | Grzegorz Grasza proposed openstack/keystone-specs master: Propose consumer-bound EC2 credentials https://review.opendev.org/c/openstack/keystone-specs/+/1010380 | 10:06 |
| xek | ^ Artem Goncharov (gtema) I'm letting my agent iterate on this idea, which is to close the gap where ec2 credentials are created for swift, but can be used to call other APIs via heat. I also discovered that heat is creating their own ec2 credentials used for signalling. it's created for a dynamically created stack-domain user, so it should be a very limited user, but it still exchanges it for a keystone token | 10:18 |
| xek | digging into the cloudformation AWS compatibility layer in Heat, my conclusion is that it might be a major selling point for Heat, since Heat native APIs are less known | 10:19 |
| xek | my conclusion from that is that we wouldn't be able to deprecate EC2 credentials any time soon | 10:20 |
| xek | or ever | 10:20 |
| gtema | I am also at the same topic expanding vision/adr for the delegation to stop heat needing ec2 creds for it's usecases | 10:20 |
| xek | Yeah, I also tried to feed the agent your vision document, to converge on something. the concepts used in AWS with STS are not incompatible with it, it's just something that we may have to take into account and incorporote it into the main vision, if we can't just deprecate it | 10:23 |
| xek | the spec above is just a security tightening though, it only moves us forward on the security front | 10:24 |
| gtema | sure, I am working on a bigger "rewording" of the vision stripping out the "roadmap" and some technical details into separate docs. I really want that heat stop using ec2 as such so that we can focus on what those in real life are. I am not against of Keystone supporting conceptually ec2 style creds, but the API most likely need to change dramatically to become safe | 10:25 |
| opendevreview | Grzegorz Grasza proposed openstack/keystone master: Bind EC2 credentials to exchange consumers https://review.opendev.org/c/openstack/keystone/+/1010401 | 10:35 |
| opendevreview | Grzegorz Grasza proposed openstack/keystone-specs master: Propose consumer-bound EC2 credentials https://review.opendev.org/c/openstack/keystone-specs/+/1010380 | 10:45 |
| opendevreview | Grzegorz Grasza proposed openstack/keystone-specs master: Propose consumer-bound EC2 credentials https://review.opendev.org/c/openstack/keystone-specs/+/1010380 | 10:49 |
| gtema | Grzegorz Grasza apparently swift is not only using ec2, but also in optional combination with trusts, need to again update my docs | 10:49 |
| gtema | in addition swift uses trust to talk to barbican | 10:50 |
| opendevreview | Grzegorz Grasza proposed openstack/keystone master: Bind EC2 credentials to exchange consumers https://review.opendev.org/c/openstack/keystone/+/1010401 | 11:07 |
| opendevreview | Merged openstack/keystoneauth master: session: Retain ownership after closing connection pools https://review.opendev.org/c/openstack/keystoneauth/+/1010179 | 11:16 |
| opendevreview | Grzegorz Grasza proposed openstack/python-keystoneclient master: Support explicit EC2 credential consumers https://review.opendev.org/c/openstack/python-keystoneclient/+/1010419 | 12:28 |
| opendevreview | Grzegorz Grasza proposed openstack/keystone-tempest-plugin master: Select EC2 consumers in RBAC credential fixtures https://review.opendev.org/c/openstack/keystone-tempest-plugin/+/1010420 | 12:30 |
| opendevreview | Grzegorz Grasza proposed openstack/keystone master: Bind EC2 credentials to exchange consumers https://review.opendev.org/c/openstack/keystone/+/1010401 | 12:32 |
| xek | from operators feedback in swift session - nvidia is using swift s3api https://etherpad.opendev.org/p/swift-indri-ops-feedback | 13:14 |
| gtema | is it what they are talking about now? | 13:15 |
| xek | yep, the operators feedback session is right now | 13:16 |
| gtema | in swift room? | 13:16 |
| xek | yep | 13:16 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!