| @jjbeckman:matrix.org | Thanks for the prompt response! | 05:52 |
|---|---|---|
| > You can enable openID Connect authentication on the web UI with a third-party Identity Provider. This will enable authenticated users that match your defined admin rules to perform administrative actions such as dequeues and autoholds from the web UI | ||
| I'm unsure we are on the same page here. Let me explain. | ||
| What I have been able to achieve is: | ||
| 1. Enable OpenID Connect authentication between Zuul and Microsoft Authentication | ||
| 2. Copy the web token from the Web UI, and execute a `autohold` command with the `zuul-client` tool | ||
| > perform administrative actions such as dequeues and autoholds from the web UI | ||
| It does no seem that these tasks can be performed from the UI. Are you sure you don't mean from the `zuul-client` CLI tool? | ||
| > Access to Zuul’s REST API and web interface can optionally be restricted. | ||
| Also, this is the point I'm having trouble trying to find out how to achieve. How can one restrict access to the web interface? | ||
| @mhuin:matrix.org | From 2. it looks like you managed to authenticate on the web UI, and your authenticated user is allowed to perform admin tasks | 07:16 |
| @mhuin:matrix.org | so you should be able to perform them from the UI as well, but I guess we should document how a bit more explicitly | 07:17 |
| @mhuin:matrix.org | if you get on the Autoholds tab while authenticated, you'll see a button to create a autohold request | 07:17 |
| @mhuin:matrix.org | on the Status tab, you'll see a kebab near each change; if you click on it you can dequeue or promote the change as desired | 07:19 |
| @mhuin:matrix.org | and finally you can re-enqueue buildsets from the buildset page | 07:19 |
| @mhuin:matrix.org | IIRC there's also a "wizard" on every build page to autohold the next failed build with the same characteristics (change, job) | 07:20 |
| @jjbeckman:matrix.org | > From 2. it looks like you managed to authenticate on the web UI | 09:18 |
| Ah, sorry, my message was misleading. I just assumed that since I was provided a auth token, I would be able to perorm, say a autohold, but didn't actually try it. I just did, and got. | ||
| ``` | ||
| zuulclient.api.ZuulRESTException: Unauthorized - your token might be invalid or expired. | ||
| ``` | ||
| So from what you have described, it appears that I've successfully set up only the authorization part, but have not been able to provide privileges to allow my "authorized" user to do anything. | ||
| Could you please point me to a concrete example of how this can be achieved? | ||
| I have been able to find the following in the documentation, but unable to interpret how one can set it to A) Let users authenticate, B) Let users perform "privileged actions" in the Web UI, C) Do not let unauthenticated users access the Web UI. | ||
| https://zuul-ci.org/docs/zuul/latest/tenants.html#attr-authorization-rule | ||
| Any advice would be much appreciated. | ||
| @mhuin:matrix.org | I thing I find useful is to use https://jwt.io to debug/analyze auth tokens | 09:21 |
| @mhuin:matrix.org | you can see exactly what claims are passed | 09:21 |
| @mhuin:matrix.org | Notably, your tokens might be very short lived and expire quickly | 09:21 |
| @mhuin:matrix.org | this is also useful to write authorization rules, since they are based on claims | 09:22 |
| @mhuin:matrix.org | I assume you followed the steps in https://zuul-ci.org/docs/zuul/latest/howtos/openid-with-microsoft.html#configuring-microsoft-authentication | 09:23 |
| @jjbeckman:matrix.org | > | 09:23 |
| I thing I find useful is to use https://jwt.io to debug/analyze auth tokens | ||
| I see, will look into this, thank you. | ||
| @mhuin:matrix.org | Then you have to configure your tenant to allow users to perform admin tasks if their token's claims match your rules | 09:23 |
| @jjbeckman:matrix.org | > I assume you followed the steps in https://zuul-ci.org/docs/zuul/latest/howtos/openid-with-microsoft.html#configuring-microsoft-authentication | 09:24 |
| Yes! | ||
| @mhuin:matrix.org | you can start with a very simple rule, like: | 09:25 |
| - authorization-rule: | ||
| name: me | ||
| conditions: | ||
| - email: your@email | ||
| @mhuin:matrix.org | provided your token has a claim called "email" - which should be the case, it's a standard one for OpenID | 09:25 |
| @mhuin:matrix.org | https://zuul-ci.org/docs/zuul/latest/tenants.html#authorization-rule | 09:26 |
| @mhuin:matrix.org | Then in your tenant definition, you have to add your admin-rule, like in the second example here https://zuul-ci.org/docs/zuul/latest/tenants.html#tenant | 09:27 |
| @jjbeckman:matrix.org | Ahhh, I see... let me try that. | 09:27 |
| @mhuin:matrix.org | if you prefer, the claim "preferred_username" is also standard. You can check what's present in your token with the jwt debugger. | 09:28 |
| @newbie23:matrix.org | I managed to get a behaviour that should cover our use case by using the metastatic driver and defining a grace-time value = 600 and max-parallel-jobs = 1, so that backing Azure nodes can be reused, but if they are idle for a while (10 minutes) they are deleted. | 09:40 |
| Now however I wonder about the nodepool option max-ready-age: what is the purpose of this option? | ||
| Can I use it to obtain a similar as-above effect by defining a static node + max-ready-age = 600 ? | ||
| @newbie23:matrix.org | > <@clarkb:matrix.org> The metastatic and static drivers are going to be the ones you want to look at. Metastatic won't schedule them in an intelligent reuse manner. But depending on your needs this may be fine. With static you would set up static nodes and specific labels that could be used. | 09:41 |
| I managed to get a behaviour that should cover our use case by using the metastatic driver and defining a grace-time value = 600 and max-parallel-jobs = 1, so that backing Azure nodes can be reused, but if they are idle for a while (10 minutes) they are deleted. | ||
| Now however I wonder about the nodepool option max-ready-age: what is the purpose of this option? | ||
| Can I use it to obtain a similar as-above effect by defining a static node + max-ready-age = 600 ? | ||
| @jjbeckman:matrix.org | 09:48 | |
| Set it as suggested and this time, I get: | ||
| `zuulclient.api.ZuulRESTException: Insufficient privileges to perform the action.` | ||
| From `zuul-client`, and no change in the Web UI 🤔 | ||
| @jjbeckman:matrix.org | There also seems to be a `read_protected` setting in the source code, but I'm unable to find any mention of it in the docs. Would this have something to do with achieving rejecting access to unauthenticated users? | 09:53 |
| ``` | ||
| ❯ grep -niIr read_protected | ||
| zuul/web/__init__.py:870: read_protected = bool(self.zuulweb.abide.api_root.access_rules) | ||
| zuul/web/__init__.py:871: auth_info['read_protected'] = read_protected | ||
| zuul/web/__init__.py:889: read_protected = bool(tenant.access_rules) | ||
| zuul/web/__init__.py:890: auth_info['read_protected'] = read_protected | ||
| tests/unit/test_web.py:1593: "read_protected": False, | ||
| tests/unit/test_web.py:1650: 'read_protected': False, | ||
| tests/unit/test_web.py:3632: info['info']['capabilities']['auth']['read_protected']) | ||
| web/src/App.jsx:151: if (auth.info.read_protected && !user.data) { | ||
| web/src/App.jsx:158: if (auth.info.read_protected && user.scope.length<1) { | ||
| web/src/App.jsx:234: (!auth.info.read_protected || user.data)) { | ||
| ❯ | ||
| ``` | ||
| @mhuin:matrix.org | > <@jjbeckman:matrix.org> Set it as suggested and this time, I get: | 10:01 |
| > `zuulclient.api.ZuulRESTException: Insufficient privileges to perform the action.` | ||
| > | ||
| > From `zuul-client`, and no change in the Web UI 🤔 | ||
| That's progress, than means your token is valid but it doesn't match your authorization rule | ||
| @jpew:matrix.org | newbie23: IIUC max-ready-age is how long nodepool will let a "ready" node sit unused before shutting it down and replacing it with another one. For example, we do tests on Windows nodes and they take minutes to spin up, so we have maybe 20 "ready" WIndows nodes that are always running in nodepool and nodepool will hand them out as soon as a job that needs a windows node starts up, reducing the time the job has to wait. However, if any of those 20 nodes sits for more than say 60 minutes (max-ready-age) without being used by a job, nodepool will shut it down and replace it with a new one (all numbers are just examples, IDK what our actual values are) | 13:41 |
| @jim:acmegating.com | jjbeckman: read-access is controlled via https://zuul-ci.org/docs/zuul/latest/tenants.html#attr-tenant.access-rules and https://zuul-ci.org/docs/zuul/latest/tenants.html#api-root | 13:49 |
| -@gerrit:opendev.org- Simon Westphahl proposed: [zuul/nodepool] 884234: Double check node request during node cleanup https://review.opendev.org/c/zuul/nodepool/+/884234 | 15:16 | |
| -@gerrit:opendev.org- Simon Westphahl proposed: [zuul/nodepool] 884234: Double check node request during node cleanup https://review.opendev.org/c/zuul/nodepool/+/884234 | 15:17 | |
| -@gerrit:opendev.org- Simon Westphahl proposed: [zuul/nodepool] 884234: Double check node request during node cleanup https://review.opendev.org/c/zuul/nodepool/+/884234 | 15:29 | |
| -@gerrit:opendev.org- Simon Westphahl proposed: [zuul/nodepool] 884234: Double check node request during node cleanup https://review.opendev.org/c/zuul/nodepool/+/884234 | 15:30 | |
| -@gerrit:opendev.org- Simon Westphahl proposed: [zuul/nodepool] 884234: Double check node request during node cleanup https://review.opendev.org/c/zuul/nodepool/+/884234 | 15:32 | |
| @jpew:matrix.org | I get the warning when I use podman, does anyone the correct way to fix it (or maybe it's not a problem at all): | 15:35 |
| ``` | ||
| 2023-05-24 15:33:10.718273 | ubuntu-jammy | time="2023-05-24T15:32:43Z" level=warning msg="The cgroupv2 manager is set to systemd but there is no systemd user session available" | ||
| 2023-05-24 15:33:10.718562 | ubuntu-jammy | time="2023-05-24T15:32:43Z" level=warning msg="For using systemd, you may need to login using an user session" | ||
| 2023-05-24 15:33:10.718611 | ubuntu-jammy | time="2023-05-24T15:32:43Z" level=warning msg="Alternatively, you can enable lingering with: `loginctl enable-linger 1000` (possibly as root)" | ||
| 2023-05-24 15:33:10.718665 | ubuntu-jammy | time="2023-05-24T15:32:43Z" level=warning msg="Falling back to --cgroup-manager=cgroupfs" | ||
| ``` | ||
| @jpew:matrix.org | * I get this warning when I use podman, does anyone the correct way to fix it (or maybe it's not a problem at all): | 15:35 |
| ``` | ||
| 2023-05-24 15:33:10.718273 | ubuntu-jammy | time="2023-05-24T15:32:43Z" level=warning msg="The cgroupv2 manager is set to systemd but there is no systemd user session available" | ||
| 2023-05-24 15:33:10.718562 | ubuntu-jammy | time="2023-05-24T15:32:43Z" level=warning msg="For using systemd, you may need to login using an user session" | ||
| 2023-05-24 15:33:10.718611 | ubuntu-jammy | time="2023-05-24T15:32:43Z" level=warning msg="Alternatively, you can enable lingering with: `loginctl enable-linger 1000` (possibly as root)" | ||
| 2023-05-24 15:33:10.718665 | ubuntu-jammy | time="2023-05-24T15:32:43Z" level=warning msg="Falling back to --cgroup-manager=cgroupfs" | ||
| ``` | ||
| @clarkb:matrix.org | > <@jpew:matrix.org> I get this warning when I use podman, does anyone the correct way to fix it (or maybe it's not a problem at all): | 15:45 |
| > | ||
| > ``` | ||
| > 2023-05-24 15:33:10.718273 | ubuntu-jammy | time="2023-05-24T15:32:43Z" level=warning msg="The cgroupv2 manager is set to systemd but there is no systemd user session available" | ||
| > 2023-05-24 15:33:10.718562 | ubuntu-jammy | time="2023-05-24T15:32:43Z" level=warning msg="For using systemd, you may need to login using an user session" | ||
| > 2023-05-24 15:33:10.718611 | ubuntu-jammy | time="2023-05-24T15:32:43Z" level=warning msg="Alternatively, you can enable lingering with: `loginctl enable-linger 1000` (possibly as root)" | ||
| > 2023-05-24 15:33:10.718665 | ubuntu-jammy | time="2023-05-24T15:32:43Z" level=warning msg="Falling back to --cgroup-manager=cgroupfs" | ||
| > ``` | ||
| you need to pass `--cgroup-manager=cgroupfs` it says it is falling back to that but it doesn't actually do that | ||
| @clarkb:matrix.org | jpew: alternatively figure out a way to have your login session create a sufficiently robust systemd session for podman | 15:46 |
| @clarkb:matrix.org | (I haven'tfigured that out. ssh + pam doesn't seem to do it despite using the systemd session login stuff) | 15:46 |
| @fungicide:matrix.org | i guess there's an open bug report somewhere for the "doesn't actually do that" part of the behavior | 15:46 |
| @clarkb:matrix.org | fungi: not sure, but passing it explicitly makes the problems go away. I think it doesn't work at all in some cases without it | 15:46 |
| @jpew:matrix.org | Ah, I can configure that it containers.conf instead of having to pass it on the command line. Perfect | 15:50 |
| @clarkb:matrix.org | there is an equivalent config file option too which is what we did in zuul-jobs | 15:51 |
| @clarkb:matrix.org | yup that | 15:51 |
| @clarkb:matrix.org | I think it is only an issue for rootless containers too | 15:51 |
| @clarkb:matrix.org | if root it doesn't happen | 15:51 |
| -@gerrit:opendev.org- Simon Westphahl proposed: [zuul/nodepool] 884241: Double check node allocation in a few more places https://review.opendev.org/c/zuul/nodepool/+/884241 | 16:01 | |
| @jim:acmegating.com | Clark: since we still haven't added a USER line to the nodepool dockerfile, i believe our functional test has been running the builder container as root, even though the bind mounts are owned by the nodepool user. under podman that's causing permission errors that didn't appear to happen under docker. i think the solution is to adjust our tests to run the container as the nodepool user (which i believe was the original intent). | 18:12 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/nodepool] 883952: DNM: See if newer podman means we can remove the cgroup hack https://review.opendev.org/c/zuul/nodepool/+/883952 | 18:14 | |
| @jim:acmegating.com | Clark: so that's what latest ps does ^ | 18:14 |
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/nodepool] 884263: Revert "Pull OpenDev images from quay.io" https://review.opendev.org/c/zuul/nodepool/+/884263 | 18:14 | |
| @clarkb:matrix.org | corvus: interesting | 18:14 |
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul-storage-proxy] 884264: Revert "Pull OpenDev images from quay.io" https://review.opendev.org/c/zuul/zuul-storage-proxy/+/884264 | 18:16 | |
| @jim:acmegating.com | Clark: yeah, i'm assuming since docker daemon runs as root that it's letting the container-root user have host-root level perms and thus override the directory perms, but that escalation path isn't available to the user-level podman process (and likewise, under your change where we run podman as root, that allows container-root to have host-root) | 18:16 |
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul-registry] 884267: Revert "Pull OpenDev images from quay.io" https://review.opendev.org/c/zuul/zuul-registry/+/884267 | 18:21 | |
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul-client] 884269: Revert "Pull OpenDev images from quay.io" https://review.opendev.org/c/zuul/zuul-client/+/884269 | 18:23 | |
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/gcp-authdaemon] 884271: Revert "Pull OpenDev images from quay.io" https://review.opendev.org/c/zuul/gcp-authdaemon/+/884271 | 18:25 | |
| -@gerrit:opendev.org- Joshua Watt proposed: [zuul/nodepool] 884278: Add squashfs-tools to docker image https://review.opendev.org/c/zuul/nodepool/+/884278 | 19:11 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!