[15:20:47] yeah, I think the zuul operator is for managing the zuul server components on top of k8s, like I think it's a k8s crd to simplify managing zuul in k8s. dduvall does that sound like your understanding, too? [15:21:13] that is, I think the operator is unnecessary for our setup. [16:23:27] mutante, thcipriani: word. unnecessary :) [16:25:03] <3 [16:25:09] oh wait... sorry [16:25:20] oh noes :) [16:26:05] https://zuul-ci.org/docs/zuul-operator/ is definitely unnecessary [16:27:03] but the docs describe that auth section thusly "With such an authenticator, a Zuul operator can use Zuul’s CLI to issue tokens overriding a tenant’s access rules if need be. A user can then use these tokens with Zuul’s CLI to perform protected actions on a tenant temporarily, without having to modify a tenant’s access rules." [16:27:29] is that really talking about the k8s operator or just an admin [16:27:53] https://zuul-ci.org/docs/zuul/latest/authentication.html [16:38:43] hrm, so this is talking about authenticated access to admin commands via the REST API, which we didn't really talk about in our meetings. [16:39:17] https://zuul-ci.org/docs/zuul/latest/authentication.html# [16:39:40] heh, guess I just linked to the same docs [16:41:03] it's also referring to admin commands via the cli [16:41:15] "In order to use restricted commands in the zuul command line interface, at least one HS256 authenticator should be configured" [16:41:44] right, that's what I'm realizing as I read a bit more here, there's a place for "--auth-token" in the zuul-admin client command: https://zuul-ci.org/docs/zuul/latest/client.html [16:43:38] er, I guess we should use https://zuul-ci.org/docs/zuul-client/commands.html [16:47:16] hrm, I think the way I'm reading this is: the operator can override access rules temporarily if needs be. Having never looked at the zuul-client before now, I'm unclear what the need would make that helpful. That is, are admins the folks who need this access? Or is there a process within zuul that needs this access? [16:47:51] If it's used by admins then it seems like temporary overrides would be unnecessary [16:49:50] that is, if we have access to the scheduler via ssh, we should be able to generate an auth token and use the client that way if needs be. [16:50:23] yea, I was thinking "well, do we really _want_ to override access rules temporarily" and "effective admins would have shell access anyways" and "do we really have tenants" [16:50:56] but if the executor uses the zuul-client to do things in some situations: that could get tricky. [16:50:56] we can remove it until the day we feel like we actually need that and revisit if that happens [16:51:38] presumably, though, the executor communicates with the scheduler via zookeeper, so zuul-client is uneeded? [16:52:58] the thing that seems useful is gathering info on builds, but we currently do that via looking at logs anyway. Plus now there's a mariadb that should have this info. [17:03:27] anyway, to the original question: operator is unnecessary/we can't use it anyway. [17:04:14] will we wish we had it later will require some investigation of zuul-client [17:05:09] ack! thank you for getting into this [17:38:41] > that is, if we have access to the scheduler via ssh, we should be able to generate an auth token and use the client that way if needs be. [17:38:54] seems like you need an auth configuration to create a token [17:39:14] e.g. `zuul-admin create-auth-token --tenant wikimedia --user admin --auth-config zuul_operator` [17:40:23] the above command gives me a bearer token which i can then pass to `zuul-admin` or `zuul-client` (testing this currently on zuul-1001.zuul3.eqiad1.wikimedia.cloud`) [17:41:07] but without the auth configuration section and `--auth-config zuul_operator` i don't think there's a way to get a token to then use with those CLIs [17:54:00] my current thinking: we should have an `[auth zuul_operator]` section in `zuul.conf` with a statically provisioned password for administrative tasks initially. we should also research whether we can set up something better such as integration with idp.wikimedia.org [17:57:03] I can add another static password to the private repo and make it so that the "secret=" line gets that password. [17:57:29] +1 [17:57:30] thanks mutante [17:57:32] assuming that can simply be a password and isn't "name of the secret" like secret-name with the client [17:57:53] as far as i can tell, it is just a password [17:58:05] alright, yes [17:58:37] and as long as the user running `zuul-admin` can read the `zuul.conf`, they can generate a token to then use with `zuul-client` for admin tasks [17:59:45] seems like the zuul.conf might be a little bit too readable so far [18:00:51] might limit that to zuul:contint-roots [18:01:07] so the workflow for admins would be: 1) ssh into zuul1001 2) run `docker exec -it zuul-scheduler /usr/local/bin/zuul-admin create-auth-token --tenant wikimedia --user does-this-even-matter --auth-config zuul_operator` 3) run `zuul-client` somewhere with the token to do steuff [18:01:12] *stuff* [18:01:26] mutante: yeah, seems reasonable [18:01:56] i think it can be root readable only actually [18:04:27] er nm. i forgot we're running the container as `zuul` [18:10:16] yea, zuul user and zuul group [18:10:36] but if I can I will avoid adding human users into the zuul group [19:52:59] 10Continuous-Integration-Infrastructure (Zuul upgrade): Add a zuul tenant config on the zuul scheduler host (zuul1001) - https://phabricator.wikimedia.org/T406384 (10thcipriani) 03NEW [19:57:16] 10Continuous-Integration-Infrastructure (Zuul upgrade), 07Essential-Work, 06Release-Engineering-Team (Priority Backlog 📥): Add a zuul tenant config on the zuul scheduler host (zuul1001) - https://phabricator.wikimedia.org/T406384#11242814 (10thcipriani) Tagging in #together since it seems like this will requ...