| opendevreview | Winicius Allan Bezerra da Silva proposed openstack/keystone master: api-ref: add missing enabled field on endpoint https://review.opendev.org/c/openstack/keystone/+/971148 | 00:07 |
|---|---|---|
| opendevreview | Winicius Allan Bezerra da Silva proposed openstack/keystone master: api-ref: add missing enabled field on endpoint https://review.opendev.org/c/openstack/keystone/+/971148 | 00:27 |
| *** mhen_ is now known as mhen | 03:01 | |
| *** zseguin_ is now known as zseguin | 04:18 | |
| *** zseguin_ is now known as zseguin | 05:46 | |
| *** zseguin is now known as Guest33702 | 05:47 | |
| opendevreview | Merged openstack/keystone master: api-ref: Add description field in Endpoint https://review.opendev.org/c/openstack/keystone/+/970170 | 08:22 |
| opendevreview | Merged openstack/keystone stable/2025.1: Fix getting token from application credentials token https://review.opendev.org/c/openstack/keystone/+/951641 | 09:50 |
| opendevreview | Merged openstack/keystone stable/2025.1: Import LOG where it is used https://review.opendev.org/c/openstack/keystone/+/970342 | 10:03 |
| nate | Hi ! | 10:57 |
| nate | I have a question about public, admin and internal endpoints in openstack. From a security perspective, if I separate public from admin/internal with different FQDNs and ingress-nginx instances, can each openstack service (nova, ironic, neutron), run a process *-api for each endpoint (while specifying for each process the endpoint type to run), to avoid for example admin | 11:04 |
| nate | operations on a public endpoint ? I see various options in openstack services to specify the endpoint to use for inter-service communications, but I struggle to understand if each endpoint comes with security enforcement stronger than just FQDN separation ? | 11:04 |
| nate | The keystone doc specifies "OpenStack uses three API endpoint variants for each service: admin, internal, and public. The admin API endpoint allows modifying users and tenants by default, while the public and internal APIs do not allow these operations. In a production environment, the variants might reside on separate networks that service different types of users for | 11:05 |
| nate | security reasons. For instance, the public API network might be visible from the Internet so customers can manage their clouds. The admin API network might be restricted to operators within the organization that manages cloud infrastructure. The internal API network might be restricted to the hosts that contain OpenStack services. Also, OpenStack supports multiple regions | 11:05 |
| nate | for scalability. For simplicity, this guide uses the management network for all endpoint variations and the default RegionOne region.". How can a keystone process can know from which endpoint comes the request ? From HTTP header in the request or in the configuration file of the process ? | 11:05 |
| opendevreview | Winicius Allan Bezerra da Silva proposed openstack/keystone master: api-ref: add missing enabled field on endpoint https://review.opendev.org/c/openstack/keystone/+/971148 | 12:19 |
| stephenfin | nate: I suspect this is a question best directed to openstack-discuss. This feels like something existing operators would know a lot about but they don't often hang out on IRC | 12:37 |
| nate | Thanks, I'll ask it there | 12:54 |
| gtema | Nate, Keystone does not care, it is just a field that is returned to the user. Same is likely valid for services: it is just a possibility for you to expose certain services on different networks, but the API does not know anything about it | 12:59 |
| nate | gtema: So this just a field returned in the response when the user asks for the catalog of endpoints. There are no restrictions whatsoever in the code of each endpoint type ? So when the doc says "The admin API endpoint allows modifying users and tenants by default" it is wrong ? | 13:04 |
| nate | It suggests that it is not the case on others but that this is possible right ? | 13:05 |
| nate | It suggests that it is not possible via others endpoints (specifically public) but that this not the case right ? | 13:05 |
| frickler | nate: which doc exactly are you looking at? admin endpoints were only a thing with identity v2.0, which is long gone | 13:06 |
| nate | frickler: The doc is here https://docs.openstack.org/mitaka/install-guide-obs/keystone-services.html, last updated in 2019. The example shows /v3 urls | 13:07 |
| frickler | nate: yes, that document is very much obsolete, you should rather look at the docs for current openstack versions | 13:08 |
| nate | Ok thanks ! Too bad, such a security feature on endpoints would have been practical haha. Thanks for the help ! | 13:09 |
| frickler | you could still add something like waf in front of your public endpoints and do filtering as you like there, then make the internal endpoints only accessible from your internal services | 13:11 |
| nate | frickler: Yes indeed, this is what we already have but we want additional layers for our security. Regarding the obsolete doc, do you know how can we make it disappear since it is wrong ? | 13:15 |
| opendevreview | Merged openstack/keystoneauth master: Drop redundant target-version option https://review.opendev.org/c/openstack/keystoneauth/+/970668 | 13:15 |
| gtema | Admin endpoints exists even now, but again: keystone only delivers list of endpoints to the user and that's it | 13:18 |
| gtema | Admin/public/internal is the "interface" and just an enum based value for keystone | 13:18 |
| frickler | nate: I've brought it up in the #openstack-tc channel now, not sure if there is a reason to keep it around | 13:18 |
| nate | gtema: Yes endpoint type still exist indeed, but it just seem to be a string, with not that much software implication around it. | 13:19 |
| nate | frickler: Great, thanks ! | 13:19 |
| gtema | I said exactly that. But it is not simply a string - enum with 3 possible values | 13:20 |
| nate | gtema: Yes indeed. Sorry I was rephrasing it to make sure I understood well | 13:21 |
| opendevreview | Merged openstack/keystonemiddleware master: Add cryptography package as an optional dependency https://review.opendev.org/c/openstack/keystonemiddleware/+/940278 | 13:45 |
| opendevreview | Merged openstack/keystonemiddleware master: s3token: Stop loading deprecated options https://review.opendev.org/c/openstack/keystonemiddleware/+/967263 | 13:45 |
| *** ykarel_ is now known as ykarel | 14:00 | |
| opendevreview | Merged openstack/keystoneauth master: ruff: Enable S checks https://review.opendev.org/c/openstack/keystoneauth/+/970458 | 14:16 |
| opendevreview | Merged openstack/keystoneauth master: docs: Update note on v2 API https://review.opendev.org/c/openstack/keystoneauth/+/970459 | 14:16 |
| opendevreview | Merged openstack/keystoneauth master: typing: Simplify mypy configuration https://review.opendev.org/c/openstack/keystoneauth/+/970460 | 14:16 |
| opendevreview | Takashi Kajinami proposed openstack/keystoneauth master: Enable logging related ruff checks https://review.opendev.org/c/openstack/keystoneauth/+/970587 | 14:19 |
| opendevreview | Merged openstack/keystone master: Drop workaround for sphinx-feature-classification < 0.4.2 https://review.opendev.org/c/openstack/keystone/+/955428 | 14:22 |
| opendevreview | Merged openstack/keystone master: Drop unused tempest from test requirements https://review.opendev.org/c/openstack/keystone/+/932184 | 14:22 |
| opendevreview | Takashi Kajinami proposed openstack/keystonemiddleware master: Replace deprecated warn method https://review.opendev.org/c/openstack/keystonemiddleware/+/971192 | 14:49 |
| opendevreview | Takashi Kajinami proposed openstack/keystonemiddleware master: Replace deprecated warn method https://review.opendev.org/c/openstack/keystonemiddleware/+/971192 | 14:57 |
| opendevreview | Takashi Kajinami proposed openstack/keystone master: Replace deprecated warn method https://review.opendev.org/c/openstack/keystone/+/971194 | 15:02 |
| nate | frickler: Regarding the outdated documentation about keystone endpoints, you said to me that it was valid only for v2, not v3. But the possibly outdated doc contain examples with v3 URL. So I assume that it would someone that mistakenly edited this doc ? | 15:11 |
| opendevreview | Merged openstack/keystone master: Drop flake8-docstrings https://review.opendev.org/c/openstack/keystone/+/962843 | 15:12 |
| opendevreview | Merged openstack/keystone master: Cap hacking https://review.opendev.org/c/openstack/keystone/+/906965 | 15:12 |
| opendevreview | Merged openstack/keystone master: Improve federated mapping documentation clarity https://review.opendev.org/c/openstack/keystone/+/970166 | 15:12 |
| frickler | nate: well maybe my wording was a bit fuzzy. so the identity v2.0 API is the only one within openstack that I'm aware of, where the admin endpoint was useful (and required) since it actually implemented different operations than the other endpoints | 15:36 |
| nate | frickler:oh ok ! Are you then sure that it is not the case in v3 ? | 15:40 |
| frickler | yes | 15:41 |
| nate | frickler: ok thanks ! Do you know why it was abandoned for v3 ? | 15:41 |
| frickler | no, that was done like 10 years ago? you might want to dig in mailinglist archives or old reviews for that | 15:43 |
| nate | frickler: ok, thanks for all the help | 15:57 |
| opendevreview | Takashi Kajinami proposed openstack/keystonemiddleware master: Replace deprecated warn method https://review.opendev.org/c/openstack/keystonemiddleware/+/971192 | 16:03 |
| opendevreview | Takashi Kajinami proposed openstack/keystone master: Replace deprecated warn method https://review.opendev.org/c/openstack/keystone/+/971194 | 22:46 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!