)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":29671,"name":"Albin Vass","email":"opendev@albinvass.com","username":"albin_vass"},"change_message_id":"80ec99f6114b167e87258920845611705ee83e82","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"6e994760_f4667260","updated":"2024-07-16 11:39:09.000000000","message":"Nice! We we\u0027re discussing something like this as well for authentication to trace which jobs were using certain artifacts (instead of allowing anonymous reads).\n\nI understand that this is supposed to generate a JWT for jobs in post-review, but I wonder if it could also generate tokens in pre-review except with a smaller scope (like read only, or only allow uploads to temporary paths). Maybe that could work with a claim for `zuul.post-review`.","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"5832838999180a36d3b6296ab8bb404e5e0e89d9","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"76ee7df5_c272e050","updated":"2024-06-21 07:05:30.000000000","message":"oh, that\u0027s a great idea to solve this finally by Zuul itself\n\nFor now I ended up deploying HashiVault near the Zuul and built a base jobs that gets a Vault session token for the trusted jobs and hands it over to the job so that the job is then able to go to vault and fetch allowed secrets. The session token is then revoked again by the base job","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"13f409e8e21330337172d6585a6da291e5813689","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"9d5c104c_45276b2e","in_reply_to":"57c6a767_b766f42d","updated":"2024-07-18 21:52:28.000000000","message":"Sounds like consensus on 1, so marking this resolved.","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":16068,"name":"Tobias Henkel","email":"tobias.henkel@bmw.de","username":"tobias.henkel"},"change_message_id":"62c42ada34c603646756d61f6f7599c264537a01","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"57c6a767_b766f42d","in_reply_to":"687c5be2_084a949e","updated":"2024-07-18 19:20:13.000000000","message":"I think option 2 is interesting. However I think this might come the risk to be insecure by default. The reason is that the admin of the target system must not forget to not just match for job/pipeline whatever but also for the post-review claim in case speculative use of the secret should be prohibited (which should be the default and is also how secrets in zuul work). However I also can think of various use cases where this would be really useful.\n\nIf we do this I\u0027d suggest that we don\u0027t include a secret fqdn claim into the token and mark usage of this as potentially dangerous when not matching against the post-review claim. Use cases which demand a higher level of security could then still define their own secret and match the claims against the secret fqdn.\n\nI think I\u0027m leaning slightly towards option 1 for the start. Adding option 2 later should be quite easy if option 1 is becoming too cumbersome doesn\u0027t support all use cases.","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"9e81ddd2e91f62f551fb9e9321a78b02693285d9","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"8c45b9d7_ec22f5ba","in_reply_to":"6e994760_f4667260","updated":"2024-07-17 00:12:41.000000000","message":"I like that idea.\n\nFirst a clarification: this spec leverages the \"secret\" framework in Zuul, which means that the tokens aren\u0027t restricted to jobs that run in post-review, but rather they will be provided to playbooks which request access to those secrets.  This normally does mean playbooks that are defined in a trusted project, but those can be on jobs that are parent jobs of untrusted jobs (think how log uploads use a secret but run on untrusted jobs).  Now, if an untrusted playbook requests a secret, that flips some bits in zuul and turns off speculative execution and restricts the job to post-review pipelines.  That may be what you were referring to, but I just wanted to be clear because it\u0027s important for what follows.\n\nSince you want to use one of these tokens in an untrusted playbook, and presumably you also want to retain the ability to have speculative execution in untrusted playbooks, then that presents some incompatibilities with this spec and the current state of Zuul.  We could consider relaxing the restriction around using secrets in untrusted playbooks specifically for this kind of secret, but then that makes the whole system harder to understand (for users and zuul maintainers) because most secrets behave one way except this kind of secret that behaves another way.\n\nBut I can see two ways of doing what you want without opening that can of worms:\n\n1) With the spec as currently written, you could have a base-job pre-run playbook in a trusted repo (probably your \"base\" job) request a secret for this purpose and write it to disk as an Ansible cached fact.  Then subsequent playbooks which needed to download artifacts could use this cached token to access them.\n\nor\n\n2) We could automatically create a token as an \"implied\" secret that meets this criteria and supply it to every playbook.  This would be sort of like how the project ssh key shows up for post-review playbooks.  Since this one would show up everywhere automatically, we don\u0027t have to deal with attaching different kinds of secrets to jobs.\n\nI have an ever-so-slight preference for option #1 because it\u0027s fewer moving parts and I like being able to build functionality from simple primitives.  But if we think that it\u0027s too onerous I think #2 would be fine.","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":29671,"name":"Albin Vass","email":"opendev@albinvass.com","username":"albin_vass"},"change_message_id":"fa97d79f735afe2d7e7d077f5e9c727f8264ec9c","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"687c5be2_084a949e","in_reply_to":"8c45b9d7_ec22f5ba","updated":"2024-07-17 08:15:21.000000000","message":"\u003e 1) With the spec as currently written, you could have a base-job pre-run playbook in a trusted repo (probably your \"base\" job) request a secret for this purpose and write it to disk as an Ansible cached fact. Then subsequent playbooks which needed to download artifacts could use this cached token to access them.\n\nYep that makes sense.","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"e4c55053f1584cc9fc4ff35b630513597e25b957","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"f1f27047_693d7d94","updated":"2024-09-16 17:08:21.000000000","message":"Adding a -1 because i think the inline comment about the subject scheme should be decided now in order to future proof.","commit_id":"20430d6ecdd8e12cea02950357c8755b2186dd2d"},{"author":{"_account_id":7186,"name":"Matthieu Huin","email":"mhuin@redhat.com","username":"mhu"},"change_message_id":"ac9e7fc0cf5f468f9b04da72a99e45b7a5a6e003","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":8,"id":"4512626f_68c96e92","updated":"2024-09-27 07:27:27.000000000","message":"LGTM","commit_id":"4bb51770f91b0b555776557a930153201b5852e4"}],"doc/source/developer/specs/zuul-workload-identity-federation.rst":[{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"5895537e1527060c459c3b30e800d2a50eb39549","unresolved":true,"context_lines":[{"line_number":86,"context_line":""},{"line_number":87,"context_line":"  {"},{"line_number":88,"context_line":"    \"issuer\": \"https://zuul.example.org\","},{"line_number":89,"context_line":"    \"jwks_uri\": \"https://zuul.example.org/jwks/keys\","},{"line_number":90,"context_line":"    \"claims_supported\": ["},{"line_number":91,"context_line":"      \"aud\","},{"line_number":92,"context_line":"      \"iat\","}],"source_content_type":"text/x-rst","patch_set":1,"id":"ec6b739f_adfa26e6","line":89,"updated":"2024-06-27 14:27:55.000000000","message":"(note) I believe that much like drivers with webhooks, this will be a global url regardless of whether zuul is deployed in whitelabel mode.","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":16068,"name":"Tobias Henkel","email":"tobias.henkel@bmw.de","username":"tobias.henkel"},"change_message_id":"62c42ada34c603646756d61f6f7599c264537a01","unresolved":true,"context_lines":[{"line_number":86,"context_line":""},{"line_number":87,"context_line":"  {"},{"line_number":88,"context_line":"    \"issuer\": \"https://zuul.example.org\","},{"line_number":89,"context_line":"    \"jwks_uri\": \"https://zuul.example.org/jwks/keys\","},{"line_number":90,"context_line":"    \"claims_supported\": ["},{"line_number":91,"context_line":"      \"aud\","},{"line_number":92,"context_line":"      \"iat\","}],"source_content_type":"text/x-rst","patch_set":1,"id":"7407ad74_eb7cc230","line":89,"in_reply_to":"6f534837_5039edf5","updated":"2024-07-18 19:20:13.000000000","message":"I made this more clear in the zuul-web section.","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"13f409e8e21330337172d6585a6da291e5813689","unresolved":false,"context_lines":[{"line_number":86,"context_line":""},{"line_number":87,"context_line":"  {"},{"line_number":88,"context_line":"    \"issuer\": \"https://zuul.example.org\","},{"line_number":89,"context_line":"    \"jwks_uri\": \"https://zuul.example.org/jwks/keys\","},{"line_number":90,"context_line":"    \"claims_supported\": ["},{"line_number":91,"context_line":"      \"aud\","},{"line_number":92,"context_line":"      \"iat\","}],"source_content_type":"text/x-rst","patch_set":1,"id":"fb39558d_16da6fb0","line":89,"in_reply_to":"7407ad74_eb7cc230","updated":"2024-07-18 21:52:28.000000000","message":"Done","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":16068,"name":"Tobias Henkel","email":"tobias.henkel@bmw.de","username":"tobias.henkel"},"change_message_id":"282e7b9900f7d494d95c5452eecee4d68330b9b0","unresolved":true,"context_lines":[{"line_number":86,"context_line":""},{"line_number":87,"context_line":"  {"},{"line_number":88,"context_line":"    \"issuer\": \"https://zuul.example.org\","},{"line_number":89,"context_line":"    \"jwks_uri\": \"https://zuul.example.org/jwks/keys\","},{"line_number":90,"context_line":"    \"claims_supported\": ["},{"line_number":91,"context_line":"      \"aud\","},{"line_number":92,"context_line":"      \"iat\","}],"source_content_type":"text/x-rst","patch_set":1,"id":"6f534837_5039edf5","line":89,"in_reply_to":"ec6b739f_adfa26e6","updated":"2024-06-27 16:22:53.000000000","message":"I agree","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"5895537e1527060c459c3b30e800d2a50eb39549","unresolved":true,"context_lines":[{"line_number":109,"context_line":"The second endpoint required is the `jwks_uri` which publishes the public keys"},{"line_number":110,"context_line":"of the sigining keys as a JSON Web Key Store which the third party service can"},{"line_number":111,"context_line":"download and use to validate the ID token. This document contains a list of keys"},{"line_number":112,"context_line":"which are referred as `kid` in the JWT header part:"},{"line_number":113,"context_line":""},{"line_number":114,"context_line":".. code-block:: json"},{"line_number":115,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"52f865bd_a7c2f465","line":112,"updated":"2024-06-27 14:27:55.000000000","message":"(note) This will be a small set of keys for the system as a whole (not per-project); we will have multiples if/when they are rotated.","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":16068,"name":"Tobias Henkel","email":"tobias.henkel@bmw.de","username":"tobias.henkel"},"change_message_id":"62c42ada34c603646756d61f6f7599c264537a01","unresolved":true,"context_lines":[{"line_number":109,"context_line":"The second endpoint required is the `jwks_uri` which publishes the public keys"},{"line_number":110,"context_line":"of the sigining keys as a JSON Web Key Store which the third party service can"},{"line_number":111,"context_line":"download and use to validate the ID token. This document contains a list of keys"},{"line_number":112,"context_line":"which are referred as `kid` in the JWT header part:"},{"line_number":113,"context_line":""},{"line_number":114,"context_line":".. code-block:: json"},{"line_number":115,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"cae9edfd_dc742f02","line":112,"in_reply_to":"52f865bd_a7c2f465","updated":"2024-07-18 19:20:13.000000000","message":"Made this more clear.","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"13f409e8e21330337172d6585a6da291e5813689","unresolved":false,"context_lines":[{"line_number":109,"context_line":"The second endpoint required is the `jwks_uri` which publishes the public keys"},{"line_number":110,"context_line":"of the sigining keys as a JSON Web Key Store which the third party service can"},{"line_number":111,"context_line":"download and use to validate the ID token. This document contains a list of keys"},{"line_number":112,"context_line":"which are referred as `kid` in the JWT header part:"},{"line_number":113,"context_line":""},{"line_number":114,"context_line":".. code-block:: json"},{"line_number":115,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3ce5db48_0f603914","line":112,"in_reply_to":"cae9edfd_dc742f02","updated":"2024-07-18 21:52:28.000000000","message":"Done","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"5895537e1527060c459c3b30e800d2a50eb39549","unresolved":true,"context_lines":[{"line_number":137,"context_line":"`oidc` mutually exclusive."},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"The ID token will be generated during the secrets preparation phase in the"},{"line_number":140,"context_line":"executor right before running the Ansible playbook which requires it."},{"line_number":141,"context_line":""},{"line_number":142,"context_line":".. code-block:: yaml"},{"line_number":143,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"f64346e1_0fb03b97","line":140,"updated":"2024-06-27 14:27:55.000000000","message":"We currently prepare the secrets before running any playbooks (ie, we prepare all the secrets, then run all the playbooks).  Are you suggesting that for this we prepare each oidc secret before each playbook?  That would make sense because it would reduce the time delta between generation and first use.  If that\u0027s what you mean, let\u0027s change this to read:\n\n  The ID token will be generated in the executor immediately before running a playbook which requires it.\n\nIt\u0027s also the case that one secret may be used by more than one playbook.  Each of pre-run, run, and post-run (and also cleanup) can take a list of playbooks, and a job can have all of those.  So an open question for me is:\n\n  Do we use the same ID token for a given secret across all playbooks that have access to it?  Or do we generate a new ID token for each playbook?\n\nThe expiration time seems to be the main concern here.  It may need to be quite large to be used both in pre-run and post-run playbooks of a large job.","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"13f409e8e21330337172d6585a6da291e5813689","unresolved":false,"context_lines":[{"line_number":137,"context_line":"`oidc` mutually exclusive."},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"The ID token will be generated during the secrets preparation phase in the"},{"line_number":140,"context_line":"executor right before running the Ansible playbook which requires it."},{"line_number":141,"context_line":""},{"line_number":142,"context_line":".. code-block:: yaml"},{"line_number":143,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"8c9f8d0b_786c22de","line":140,"in_reply_to":"d4995573_68a464de","updated":"2024-07-18 21:52:28.000000000","message":"Acknowledged","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":16068,"name":"Tobias Henkel","email":"tobias.henkel@bmw.de","username":"tobias.henkel"},"change_message_id":"282e7b9900f7d494d95c5452eecee4d68330b9b0","unresolved":true,"context_lines":[{"line_number":137,"context_line":"`oidc` mutually exclusive."},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"The ID token will be generated during the secrets preparation phase in the"},{"line_number":140,"context_line":"executor right before running the Ansible playbook which requires it."},{"line_number":141,"context_line":""},{"line_number":142,"context_line":".. code-block:: yaml"},{"line_number":143,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"d4995573_68a464de","line":140,"in_reply_to":"f64346e1_0fb03b97","updated":"2024-06-27 16:22:53.000000000","message":"Yes, generating the ID token immediately before running a playbook was my intention here. I will update this. Regarding multiple playbooks using the same secret I think it makes sense to re-generate the ID token due to the TTL. So I\u0027ll make this clear as well/","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"1bfd71a6f87d40c699e417354e576a1960dd7943","unresolved":true,"context_lines":[{"line_number":158,"context_line":".. code-block:: yaml"},{"line_number":159,"context_line":""},{"line_number":160,"context_line":"  # Sub is important as most third party services will likely match on this"},{"line_number":161,"context_line":"  # claim to determin the permissions. This is kind of an FQDN to uniquely"},{"line_number":162,"context_line":"  # identify the zuul secret used."},{"line_number":163,"context_line":"  sub: \"\u003czuul-tenant\u003e/\u003ccanonical-project-name\u003e/\u003csecret name\u003e\""},{"line_number":164,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"0ec14467_6e3d5dbc","line":161,"updated":"2024-06-21 11:42:40.000000000","message":"typo: determine","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"13f409e8e21330337172d6585a6da291e5813689","unresolved":false,"context_lines":[{"line_number":158,"context_line":".. code-block:: yaml"},{"line_number":159,"context_line":""},{"line_number":160,"context_line":"  # Sub is important as most third party services will likely match on this"},{"line_number":161,"context_line":"  # claim to determin the permissions. This is kind of an FQDN to uniquely"},{"line_number":162,"context_line":"  # identify the zuul secret used."},{"line_number":163,"context_line":"  sub: \"\u003czuul-tenant\u003e/\u003ccanonical-project-name\u003e/\u003csecret name\u003e\""},{"line_number":164,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"32500fb0_eb58a0f9","line":161,"in_reply_to":"0ec14467_6e3d5dbc","updated":"2024-07-18 21:52:28.000000000","message":"Done","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"5895537e1527060c459c3b30e800d2a50eb39549","unresolved":true,"context_lines":[{"line_number":163,"context_line":"  sub: \"\u003czuul-tenant\u003e/\u003ccanonical-project-name\u003e/\u003csecret name\u003e\""},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"  # Some information on the job\u0027s context might be useful"},{"line_number":166,"context_line":"  job-name: \"\u003cjob-name\u003e\""},{"line_number":167,"context_line":"  playbook: \"\u003cplaybook\u003e\""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"0bd40794_3fdfead2","line":166,"updated":"2024-06-27 14:27:55.000000000","message":"The job-name will change if inherited from (unless you mean the job-name of the job that uses the secret, not the final job that it inherits from).  That seems useful to me, in that if someone sets up a base job that uses a secret and someone inherits from it, there is some indication to the IDC which job is actually using it.  But this would be dangerous to rely on instead of sub, so we should probably put a big warning sign in the docs about this.","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":16068,"name":"Tobias Henkel","email":"tobias.henkel@bmw.de","username":"tobias.henkel"},"change_message_id":"282e7b9900f7d494d95c5452eecee4d68330b9b0","unresolved":true,"context_lines":[{"line_number":163,"context_line":"  sub: \"\u003czuul-tenant\u003e/\u003ccanonical-project-name\u003e/\u003csecret name\u003e\""},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"  # Some information on the job\u0027s context might be useful"},{"line_number":166,"context_line":"  job-name: \"\u003cjob-name\u003e\""},{"line_number":167,"context_line":"  playbook: \"\u003cplaybook\u003e\""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"c8fa9e06_cbaa6e76","line":166,"in_reply_to":"0bd40794_3fdfead2","updated":"2024-06-27 16:22:53.000000000","message":"I think we still can discuss wether we\u0027ll need this at all as standard claims. In most cases I think the matching will be against the sub which is probably the only identifier which is really protected by zuul\u0027s secret mechanism. If we decide to put that information there by default (for informational, maybe logging purposes on the target service) I agree that we should put a warning in the docs.","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"7b83d62434944ef433471de5c8306b46a7ed26f6","unresolved":false,"context_lines":[{"line_number":163,"context_line":"  sub: \"\u003czuul-tenant\u003e/\u003ccanonical-project-name\u003e/\u003csecret name\u003e\""},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"  # Some information on the job\u0027s context might be useful"},{"line_number":166,"context_line":"  job-name: \"\u003cjob-name\u003e\""},{"line_number":167,"context_line":"  playbook: \"\u003cplaybook\u003e\""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"63f69846_f12011f4","line":166,"in_reply_to":"1ef8d00b_3397b392","updated":"2024-08-28 18:14:16.000000000","message":"Sounds good.  We can always add it later, but it\u0027s more conservative to omit it if we\u0027re not really sure we want it.  I\u0027ve updated the spec to drop it for now.","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":29671,"name":"Albin Vass","email":"opendev@albinvass.com","username":"albin_vass"},"change_message_id":"7d36dd8f9bc46b80bd34bf29dedb8e2f188eaf06","unresolved":true,"context_lines":[{"line_number":163,"context_line":"  sub: \"\u003czuul-tenant\u003e/\u003ccanonical-project-name\u003e/\u003csecret name\u003e\""},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"  # Some information on the job\u0027s context might be useful"},{"line_number":166,"context_line":"  job-name: \"\u003cjob-name\u003e\""},{"line_number":167,"context_line":"  playbook: \"\u003cplaybook\u003e\""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ef8d00b_3397b392","line":166,"in_reply_to":"289e7511_b43e9152","updated":"2024-08-28 18:12:39.000000000","message":"\u003e We can add the \"zuul.project\" to this, but I think it is potentially problematic to use. In the case of circular dependencies between different projects, the zuul.project is an arbitrary value chosen from the list of zuul projects triggering the job. It makes sense for single-job projects but may not make sense for integration jobs.\n\n\u003e Depending on the exact use you have in mind, that might be fine, or it may not. It should still give you a scratch space designated for one of the projects involved, it just may not always be the same one.\n\nI didn\u0027t think about circular dependencies when I suggested adding `zuul.project`, with that in mind I agree that it can be problematic and may be worth excluding from the initial implementation.","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"3b35e59668324c417388f3bdab1aba642cfe59f7","unresolved":true,"context_lines":[{"line_number":163,"context_line":"  sub: \"\u003czuul-tenant\u003e/\u003ccanonical-project-name\u003e/\u003csecret name\u003e\""},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"  # Some information on the job\u0027s context might be useful"},{"line_number":166,"context_line":"  job-name: \"\u003cjob-name\u003e\""},{"line_number":167,"context_line":"  playbook: \"\u003cplaybook\u003e\""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9e2178cd_dedfd841","line":166,"in_reply_to":"577bcabe_b457e0cd","updated":"2024-07-17 13:30:05.000000000","message":"I think for the use case you describe (which is mostly logging), you\u0027d want to include the build uuid.  I definitely think we can/should include that here.\n\nhttps://stackoverflow.com/questions/26033983/what-is-the-maximum-size-of-jwt-token\n\nI think we can put a few standard claims in there, but we may want to avoid adding too many.  As for generalized templating, that opens a potential issue with whether they can be trusted, since it isn\u0027t necessarily zuul making the claims at that point, but the user who created the secret.  So we probably want to avoid that unless we have a really good reason.","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"13f409e8e21330337172d6585a6da291e5813689","unresolved":false,"context_lines":[{"line_number":163,"context_line":"  sub: \"\u003czuul-tenant\u003e/\u003ccanonical-project-name\u003e/\u003csecret name\u003e\""},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"  # Some information on the job\u0027s context might be useful"},{"line_number":166,"context_line":"  job-name: \"\u003cjob-name\u003e\""},{"line_number":167,"context_line":"  playbook: \"\u003cplaybook\u003e\""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"b2f66cc1_bbdfd711","line":166,"in_reply_to":"7c92f41a_3ed5372b","updated":"2024-07-18 21:52:28.000000000","message":"Done","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":29671,"name":"Albin Vass","email":"opendev@albinvass.com","username":"albin_vass"},"change_message_id":"d54681fc2de98116ed08d54179eedd8f20fb7def","unresolved":true,"context_lines":[{"line_number":163,"context_line":"  sub: \"\u003czuul-tenant\u003e/\u003ccanonical-project-name\u003e/\u003csecret name\u003e\""},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"  # Some information on the job\u0027s context might be useful"},{"line_number":166,"context_line":"  job-name: \"\u003cjob-name\u003e\""},{"line_number":167,"context_line":"  playbook: \"\u003cplaybook\u003e\""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"c397bf63_0e13ec3e","line":166,"in_reply_to":"7cccb17d_5b2eb0c4","updated":"2024-07-19 08:28:09.000000000","message":"Unchecking resolved. I thought commenting would do that automatically :)","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"8bc18e4700a8c9110c33fece8ef0fe13afd0d66d","unresolved":true,"context_lines":[{"line_number":163,"context_line":"  sub: \"\u003czuul-tenant\u003e/\u003ccanonical-project-name\u003e/\u003csecret name\u003e\""},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"  # Some information on the job\u0027s context might be useful"},{"line_number":166,"context_line":"  job-name: \"\u003cjob-name\u003e\""},{"line_number":167,"context_line":"  playbook: \"\u003cplaybook\u003e\""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"289e7511_b43e9152","line":166,"in_reply_to":"95e0741f_6d9b1ac7","updated":"2024-08-21 20:25:43.000000000","message":"We can add the \"zuul.project\" to this, but I think it is potentially problematic to use.  In the case of circular dependencies between different projects, the zuul.project is an arbitrary value chosen from the list of zuul projects triggering the job.  It makes sense for single-job projects but may not make sense for integration jobs.\n\nDepending on the exact use you have in mind, that might be fine, or it may not.  It should still give you a scratch space designated for one of the projects involved, it just may not always be the same one.\n\nTo answer the question about whether there\u0027s a drawback in adding too many claims: I don\u0027t think we\u0027re going to run into the actual size limit (it\u0027s several kb).  But I do think the more we add, the more ammunition we give folks to shoot themselves in the foot by matching against claims that are not as definitive as the sub.\n\nSince I think no one objects to adding \"project\", I\u0027ll rev this spec with that addition, but I\u0027m going to leave this comment open for Albin to resolve based on whether what I just wrote is \"okay\" or needs further discussion.","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":16068,"name":"Tobias Henkel","email":"tobias.henkel@bmw.de","username":"tobias.henkel"},"change_message_id":"62c42ada34c603646756d61f6f7599c264537a01","unresolved":true,"context_lines":[{"line_number":163,"context_line":"  sub: \"\u003czuul-tenant\u003e/\u003ccanonical-project-name\u003e/\u003csecret name\u003e\""},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"  # Some information on the job\u0027s context might be useful"},{"line_number":166,"context_line":"  job-name: \"\u003cjob-name\u003e\""},{"line_number":167,"context_line":"  playbook: \"\u003cplaybook\u003e\""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"7c92f41a_3ed5372b","line":166,"in_reply_to":"9e2178cd_dedfd841","updated":"2024-07-18 19:20:13.000000000","message":"I added build-uuid, pipeline and tenant as well.","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":29671,"name":"Albin Vass","email":"opendev@albinvass.com","username":"albin_vass"},"change_message_id":"8da94401cde2c47d5f8c454a7ebf1fe0231c79ad","unresolved":false,"context_lines":[{"line_number":163,"context_line":"  sub: \"\u003czuul-tenant\u003e/\u003ccanonical-project-name\u003e/\u003csecret name\u003e\""},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"  # Some information on the job\u0027s context might be useful"},{"line_number":166,"context_line":"  job-name: \"\u003cjob-name\u003e\""},{"line_number":167,"context_line":"  playbook: \"\u003cplaybook\u003e\""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"7cccb17d_5b2eb0c4","line":166,"in_reply_to":"b2f66cc1_bbdfd711","updated":"2024-07-19 08:27:17.000000000","message":"Sorry for opening this thread again. But is there a reason we don\u0027t want the project to be included? I understand that it\u0027s not necessary in the case where a project has it\u0027s own oidc secrets defined because then it\u0027s possible to match on subject. However for the pre-review case where tokens are generated in a trusted project and passed to the untrusted context that doesn\u0027t apply. I can see it being very useful to have a project claim that can be matched against to, for example, give projects their own scratch space in say artifactory where they can write artifacts to pass them between jobs in a buildset.","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":16068,"name":"Tobias Henkel","email":"tobias.henkel@bmw.de","username":"tobias.henkel"},"change_message_id":"d78476feca4e4923dcfe3be42b72cb7151e6546c","unresolved":true,"context_lines":[{"line_number":163,"context_line":"  sub: \"\u003czuul-tenant\u003e/\u003ccanonical-project-name\u003e/\u003csecret name\u003e\""},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"  # Some information on the job\u0027s context might be useful"},{"line_number":166,"context_line":"  job-name: \"\u003cjob-name\u003e\""},{"line_number":167,"context_line":"  playbook: \"\u003cplaybook\u003e\""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"95e0741f_6d9b1ac7","line":166,"in_reply_to":"c397bf63_0e13ec3e","updated":"2024-07-19 08:37:13.000000000","message":"I think we can add the project as well. I just forgot to add this.","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":29671,"name":"Albin Vass","email":"opendev@albinvass.com","username":"albin_vass"},"change_message_id":"fa97d79f735afe2d7e7d077f5e9c727f8264ec9c","unresolved":true,"context_lines":[{"line_number":163,"context_line":"  sub: \"\u003czuul-tenant\u003e/\u003ccanonical-project-name\u003e/\u003csecret name\u003e\""},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"  # Some information on the job\u0027s context might be useful"},{"line_number":166,"context_line":"  job-name: \"\u003cjob-name\u003e\""},{"line_number":167,"context_line":"  playbook: \"\u003cplaybook\u003e\""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"577bcabe_b457e0cd","line":166,"in_reply_to":"c8fa9e06_cbaa6e76","updated":"2024-07-17 08:15:21.000000000","message":"\u003e In most cases I think the matching will be against the sub which is probably the only identifier which is really protected by zuul\u0027s secret mechanism.\n\nAs discussed below, if we were to generate tokens from a trusted context in pre-review I believe we would mostly match against a post-review and project claim rather than subject.\n\nIf the default claims are limited to subject (secret fqdn/id), job name and playbook we may want to allow templating in the additional claims configured in the oidc secret to make it possible to add information about the context the token was generated for. Instead I\u0027m leaning towards adding more zuul data as default claims since it seems easier to build standardized tooling around that.\n\nIs there a drawback to adding too many claims?","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"5895537e1527060c459c3b30e800d2a50eb39549","unresolved":true,"context_lines":[{"line_number":188,"context_line":""},{"line_number":189,"context_line":"3. Wait for max-ttl over all tenants"},{"line_number":190,"context_line":""},{"line_number":191,"context_line":"4. Remove the old signing key"},{"line_number":192,"context_line":""},{"line_number":193,"context_line":""},{"line_number":194,"context_line":"Zuul Web"}],"source_content_type":"text/x-rst","patch_set":1,"id":"df5519f4_4d9a68ec","line":191,"updated":"2024-06-27 14:27:55.000000000","message":"Our keystorage schema currently has a schema for handling rotation of keys by using the following data structure at the key location:\n{ \u0027schema\u0027: 1,\n  \u0027keys\u0027: [\n    {\u0027version\u0027: 0,\n     \u0027created\u0027: timestamp,\n     \u0027private_key\u0027: blob},\n    ...\n  ]}\n\nWe might use the same for this.  Then just store that data structure at `/keystorage/oidc`.  That would increase parity with the other key systems.","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"13f409e8e21330337172d6585a6da291e5813689","unresolved":false,"context_lines":[{"line_number":188,"context_line":""},{"line_number":189,"context_line":"3. Wait for max-ttl over all tenants"},{"line_number":190,"context_line":""},{"line_number":191,"context_line":"4. Remove the old signing key"},{"line_number":192,"context_line":""},{"line_number":193,"context_line":""},{"line_number":194,"context_line":"Zuul Web"}],"source_content_type":"text/x-rst","patch_set":1,"id":"4531b948_78ca5d7f","line":191,"in_reply_to":"d8286ca2_daca0c29","updated":"2024-07-18 21:52:28.000000000","message":"Done","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":16068,"name":"Tobias Henkel","email":"tobias.henkel@bmw.de","username":"tobias.henkel"},"change_message_id":"282e7b9900f7d494d95c5452eecee4d68330b9b0","unresolved":true,"context_lines":[{"line_number":188,"context_line":""},{"line_number":189,"context_line":"3. Wait for max-ttl over all tenants"},{"line_number":190,"context_line":""},{"line_number":191,"context_line":"4. Remove the old signing key"},{"line_number":192,"context_line":""},{"line_number":193,"context_line":""},{"line_number":194,"context_line":"Zuul Web"}],"source_content_type":"text/x-rst","patch_set":1,"id":"d8286ca2_daca0c29","line":191,"in_reply_to":"df5519f4_4d9a68ec","updated":"2024-06-27 16:22:53.000000000","message":"Good idea","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"5895537e1527060c459c3b30e800d2a50eb39549","unresolved":true,"context_lines":[{"line_number":201,"context_line":""},{"line_number":202,"context_line":"* `\u003czuul-root\u003e/oidc/jwks`: The JSON Web Key Store used to publish all currently"},{"line_number":203,"context_line":"  active public signing keys. This can be put pre-rendered into zk when"},{"line_number":204,"context_line":"  performing signing key rotation."},{"line_number":205,"context_line":""},{"line_number":206,"context_line":""},{"line_number":207,"context_line":"Security considerations"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3d219f70_4ea59a7c","line":204,"updated":"2024-06-27 14:27:55.000000000","message":"Probably easier to just have the web server regenerate the public keys on startup or whenever the keystore is updated.  Will only take a second, and we don\u0027t have to deal with extra data storage/sync.","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":16068,"name":"Tobias Henkel","email":"tobias.henkel@bmw.de","username":"tobias.henkel"},"change_message_id":"282e7b9900f7d494d95c5452eecee4d68330b9b0","unresolved":true,"context_lines":[{"line_number":201,"context_line":""},{"line_number":202,"context_line":"* `\u003czuul-root\u003e/oidc/jwks`: The JSON Web Key Store used to publish all currently"},{"line_number":203,"context_line":"  active public signing keys. This can be put pre-rendered into zk when"},{"line_number":204,"context_line":"  performing signing key rotation."},{"line_number":205,"context_line":""},{"line_number":206,"context_line":""},{"line_number":207,"context_line":"Security considerations"}],"source_content_type":"text/x-rst","patch_set":1,"id":"6d2d34e7_686287f1","line":204,"in_reply_to":"3d219f70_4ea59a7c","updated":"2024-06-27 16:22:53.000000000","message":"Sounds good as well, my main thought about this was to cache the rendered response so we don\u0027t have to call into cryptography on every request.","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"13f409e8e21330337172d6585a6da291e5813689","unresolved":false,"context_lines":[{"line_number":201,"context_line":""},{"line_number":202,"context_line":"* `\u003czuul-root\u003e/oidc/jwks`: The JSON Web Key Store used to publish all currently"},{"line_number":203,"context_line":"  active public signing keys. This can be put pre-rendered into zk when"},{"line_number":204,"context_line":"  performing signing key rotation."},{"line_number":205,"context_line":""},{"line_number":206,"context_line":""},{"line_number":207,"context_line":"Security considerations"}],"source_content_type":"text/x-rst","patch_set":1,"id":"af00a47a_2c038821","line":204,"in_reply_to":"6d2d34e7_686287f1","updated":"2024-07-18 21:52:28.000000000","message":"Done","commit_id":"0eaff41a012f0b9c232f0f22593b69c994275a40"},{"author":{"_account_id":7186,"name":"Matthieu Huin","email":"mhuin@redhat.com","username":"mhu"},"change_message_id":"032aadff0fa1e4dc11c7cb203fb557e84d6bbb9f","unresolved":true,"context_lines":[{"line_number":85,"context_line":".. code-block:: json"},{"line_number":86,"context_line":""},{"line_number":87,"context_line":"  {"},{"line_number":88,"context_line":"    \"issuer\": \"https://zuul.example.org\","},{"line_number":89,"context_line":"    \"jwks_uri\": \"https://zuul.example.org/jwks/keys\","},{"line_number":90,"context_line":"    \"claims_supported\": ["},{"line_number":91,"context_line":"      \"aud\","},{"line_number":92,"context_line":"      \"iat\","}],"source_content_type":"text/x-rst","patch_set":6,"id":"87e5992a_2ad5ecfc","line":89,"range":{"start_line":88,"start_character":0,"end_line":89,"end_character":53},"updated":"2024-09-12 13:03:37.000000000","message":"The .well-known and jwks URIs would need to be shared across whitelabeled setups, or these claims should always be set with a root URL that must be reachable by the third party service validating the JWT.","commit_id":"20430d6ecdd8e12cea02950357c8755b2186dd2d"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"a0bb966cbf6f47bc4a73ab45836fe063c843c095","unresolved":false,"context_lines":[{"line_number":85,"context_line":".. code-block:: json"},{"line_number":86,"context_line":""},{"line_number":87,"context_line":"  {"},{"line_number":88,"context_line":"    \"issuer\": \"https://zuul.example.org\","},{"line_number":89,"context_line":"    \"jwks_uri\": \"https://zuul.example.org/jwks/keys\","},{"line_number":90,"context_line":"    \"claims_supported\": ["},{"line_number":91,"context_line":"      \"aud\","},{"line_number":92,"context_line":"      \"iat\","}],"source_content_type":"text/x-rst","patch_set":6,"id":"f1afd8f7_8f564f8e","line":89,"range":{"start_line":88,"start_character":0,"end_line":89,"end_character":53},"in_reply_to":"87e5992a_2ad5ecfc","updated":"2024-09-16 16:04:15.000000000","message":"Agreed.  We discussed this a bit on PS1 and noted that it should probably behave like the connection webhook URLs.  There\u0027s a small note about that in the \"zuul-web\" section below.","commit_id":"20430d6ecdd8e12cea02950357c8755b2186dd2d"},{"author":{"_account_id":7186,"name":"Matthieu Huin","email":"mhuin@redhat.com","username":"mhu"},"change_message_id":"032aadff0fa1e4dc11c7cb203fb557e84d6bbb9f","unresolved":true,"context_lines":[{"line_number":99,"context_line":"      \"id_token\""},{"line_number":100,"context_line":"    ],"},{"line_number":101,"context_line":"    \"id_token_signing_alg_values_supported\": ["},{"line_number":102,"context_line":"      \"RS256\""},{"line_number":103,"context_line":"    ],"},{"line_number":104,"context_line":"    \"subject_types_supported\": ["},{"line_number":105,"context_line":"      \"public\""}],"source_content_type":"text/x-rst","patch_set":6,"id":"12bdd0e0_712fe2c9","line":102,"range":{"start_line":102,"start_character":6,"end_line":102,"end_character":13},"updated":"2024-09-12 13:03:37.000000000","message":"Deployers may want to choose supported algorithms, ECDSA may have some appeal over RSA","commit_id":"20430d6ecdd8e12cea02950357c8755b2186dd2d"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"87e1c18d25947526ee247d4f8dc80fa5422d257a","unresolved":true,"context_lines":[{"line_number":99,"context_line":"      \"id_token\""},{"line_number":100,"context_line":"    ],"},{"line_number":101,"context_line":"    \"id_token_signing_alg_values_supported\": ["},{"line_number":102,"context_line":"      \"RS256\""},{"line_number":103,"context_line":"    ],"},{"line_number":104,"context_line":"    \"subject_types_supported\": ["},{"line_number":105,"context_line":"      \"public\""}],"source_content_type":"text/x-rst","patch_set":6,"id":"11a7590b_471c02bf","line":102,"range":{"start_line":102,"start_character":6,"end_line":102,"end_character":13},"in_reply_to":"0b6e0012_24cce437","updated":"2024-09-26 20:17:44.000000000","message":"Okay, I think I have synthesized all of this in PS8.","commit_id":"20430d6ecdd8e12cea02950357c8755b2186dd2d"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"a0bb966cbf6f47bc4a73ab45836fe063c843c095","unresolved":true,"context_lines":[{"line_number":99,"context_line":"      \"id_token\""},{"line_number":100,"context_line":"    ],"},{"line_number":101,"context_line":"    \"id_token_signing_alg_values_supported\": ["},{"line_number":102,"context_line":"      \"RS256\""},{"line_number":103,"context_line":"    ],"},{"line_number":104,"context_line":"    \"subject_types_supported\": ["},{"line_number":105,"context_line":"      \"public\""}],"source_content_type":"text/x-rst","patch_set":6,"id":"1b1afbc3_c12abb80","line":102,"range":{"start_line":102,"start_character":6,"end_line":102,"end_character":13},"in_reply_to":"12bdd0e0_712fe2c9","updated":"2024-09-16 16:04:15.000000000","message":"This is based on the private key(s) we generate, right?  This spec anticipates having a single RSA key; Jeremy also suggested that folks may want other values but we could add them later.\n\nDo you think we should automatically generate a key for each algorithm we add (so RSA and ECDSA if we add that)?  Or should we allow admins to exclude some?  (It sounds like that\u0027s what you\u0027re suggesting.)  In the second case, we would need to add a zuul.conf section like:\n\n```\n[oidc]\nsupported_algos\u003dECDSA\n```\n\nWhich, if Zuul supported both RSA and ECDSA, would mean that Zuul should only generate ECDSA keys.  The default might be something like:\n\n```\n[oidc]\nsupported_algos\u003dRSA,ECDSA\n```\n\nWhich means Zuul would generate both.\n\nThat sounds fine to me, but I want to make sure that\u0027s what you\u0027re suggesting.","commit_id":"20430d6ecdd8e12cea02950357c8755b2186dd2d"},{"author":{"_account_id":16068,"name":"Tobias Henkel","email":"tobias.henkel@bmw.de","username":"tobias.henkel"},"change_message_id":"1e43f214e838ae222b42fd212fe04011819163eb","unresolved":true,"context_lines":[{"line_number":99,"context_line":"      \"id_token\""},{"line_number":100,"context_line":"    ],"},{"line_number":101,"context_line":"    \"id_token_signing_alg_values_supported\": ["},{"line_number":102,"context_line":"      \"RS256\""},{"line_number":103,"context_line":"    ],"},{"line_number":104,"context_line":"    \"subject_types_supported\": ["},{"line_number":105,"context_line":"      \"public\""}],"source_content_type":"text/x-rst","patch_set":6,"id":"c74e9f0a_74e294bc","line":102,"range":{"start_line":102,"start_character":6,"end_line":102,"end_character":13},"in_reply_to":"1b1afbc3_c12abb80","updated":"2024-09-16 16:17:26.000000000","message":"I think if we intend to support both we might want to add an attribute to the secret in order to choose the algorithm for that token. In that case we could also just define the default algorithm in zuul.conf.","commit_id":"20430d6ecdd8e12cea02950357c8755b2186dd2d"},{"author":{"_account_id":7186,"name":"Matthieu Huin","email":"mhuin@redhat.com","username":"mhu"},"change_message_id":"ef43d3e7e73c42bd519779093393c783dca5c7ef","unresolved":true,"context_lines":[{"line_number":99,"context_line":"      \"id_token\""},{"line_number":100,"context_line":"    ],"},{"line_number":101,"context_line":"    \"id_token_signing_alg_values_supported\": ["},{"line_number":102,"context_line":"      \"RS256\""},{"line_number":103,"context_line":"    ],"},{"line_number":104,"context_line":"    \"subject_types_supported\": ["},{"line_number":105,"context_line":"      \"public\""}],"source_content_type":"text/x-rst","patch_set":6,"id":"0b6e0012_24cce437","line":102,"range":{"start_line":102,"start_character":6,"end_line":102,"end_character":13},"in_reply_to":"c74e9f0a_74e294bc","updated":"2024-09-26 07:55:55.000000000","message":"If I understand this RFC ( https://www.rfc-editor.org/rfc/rfc7518#section-3.1 ) properly, a valid implementation should at least always support HS256, with RS256 and ES256 being also recommended. Most IdPs provide support for all the algorithms in the list, then you can fine-tune which you want enabled or not.\n\nI don\u0027t know how strict a client would be in that use case (ie would the auth\u0027s workflow fail if HS256 isn\u0027t supported by Zuul?), so it may be worth to implement support for every algorithm at the \"recommended\" level or above to be RFC-compliant, and add support for more algorithms in the future if there is a need for it.\n\nBesides these considerations, ECDSA is interesting to support because it requires less computing power at same strength level than RSA.","commit_id":"20430d6ecdd8e12cea02950357c8755b2186dd2d"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"e4c55053f1584cc9fc4ff35b630513597e25b957","unresolved":true,"context_lines":[{"line_number":164,"context_line":"  # Sub is important as most third party services will likely match on this"},{"line_number":165,"context_line":"  # claim to determine the permissions. This is kind of an FQDN to uniquely"},{"line_number":166,"context_line":"  # identify the zuul secret used."},{"line_number":167,"context_line":"  sub: \"\u003czuul-tenant\u003e/\u003ccanonical-project-name\u003e/\u003csecret name\u003e\""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"  # Some information on the job\u0027s context might be useful.  Caution"},{"line_number":170,"context_line":"  # should be used if these are used for matching; documentation should"}],"source_content_type":"text/x-rst","patch_set":6,"id":"50cc5cac_02ad50b2","line":167,"updated":"2024-09-16 17:08:21.000000000","message":"Albin has drawn my attention to the fact that Azure (unlike AWS) does not appear to support wildcards in subject matches; nor does it allow matching on anything other than subject.  See this github issue for a bunch of folks lamenting that fact: https://github.com/Azure/azure-workload-identity/issues/373\n\nThat makes some things difficult for Azure.  For example, having a credential that just acts in the scope of the defining project means that you have to over-specify the subject.  Where an admin might want to match a subject of \"\u003czuul-tenant\u003e/\u003ccanonical-project-name\u003e/*\" they would have to specify a secret name even if that wasn\u0027t interesting to them.\n\nWe might want to make this easier in the future by supporting other schemes in the subject.  For example, we might want to support exactly the project-level scheme described above.  Or we might want to encode the triggering project (and possibly branch) as the subject.\n\nI\u0027m not sure we need to decide all the things we might want to do right now, but if we decide that we may want to explore other schemes later, then we should encode the scheme in the subject now so that we are future-proof.\n\nI suggest we update this to specify the subject as:\n\n```\nsub: \"secret:\u003czuul-tenant\u003e/\u003ccanonical-project-name\u003e/\u003csecret name\u003e\"\n```\n\nSo that our first (and so far only) subject scheme is `secret` -- meaning, the subject is the canonical name of the secret itself.  Future subject schemes might be `secret-project` (for the scheme described above) or `triggering-project` (which, as discussed in other comments, could be problematic for deduplicated jobs in circular dependencies, but could nonetheless be useful).  Or `tenant` or `queue`.","commit_id":"20430d6ecdd8e12cea02950357c8755b2186dd2d"},{"author":{"_account_id":16068,"name":"Tobias Henkel","email":"tobias.henkel@bmw.de","username":"tobias.henkel"},"change_message_id":"e91b3c1bcb2d7606c27f64c5394a85ad45aa63ae","unresolved":true,"context_lines":[{"line_number":164,"context_line":"  # Sub is important as most third party services will likely match on this"},{"line_number":165,"context_line":"  # claim to determine the permissions. This is kind of an FQDN to uniquely"},{"line_number":166,"context_line":"  # identify the zuul secret used."},{"line_number":167,"context_line":"  sub: \"\u003czuul-tenant\u003e/\u003ccanonical-project-name\u003e/\u003csecret name\u003e\""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"  # Some information on the job\u0027s context might be useful.  Caution"},{"line_number":170,"context_line":"  # should be used if these are used for matching; documentation should"}],"source_content_type":"text/x-rst","patch_set":6,"id":"f3e3695c_f8b654d6","line":167,"in_reply_to":"50cc5cac_02ad50b2","updated":"2024-09-17 06:23:20.000000000","message":"I like this suggestion.","commit_id":"20430d6ecdd8e12cea02950357c8755b2186dd2d"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"05b3a500cf5f76d684a08557a9597f2c53bc9c46","unresolved":false,"context_lines":[{"line_number":164,"context_line":"  # Sub is important as most third party services will likely match on this"},{"line_number":165,"context_line":"  # claim to determine the permissions. This is kind of an FQDN to uniquely"},{"line_number":166,"context_line":"  # identify the zuul secret used."},{"line_number":167,"context_line":"  sub: \"\u003czuul-tenant\u003e/\u003ccanonical-project-name\u003e/\u003csecret name\u003e\""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"  # Some information on the job\u0027s context might be useful.  Caution"},{"line_number":170,"context_line":"  # should be used if these are used for matching; documentation should"}],"source_content_type":"text/x-rst","patch_set":6,"id":"abe6e996_bdabf174","line":167,"in_reply_to":"67e41d38_734e6064","updated":"2024-09-17 16:20:52.000000000","message":"Done","commit_id":"20430d6ecdd8e12cea02950357c8755b2186dd2d"},{"author":{"_account_id":27582,"name":"Simon Westphahl","email":"simon.westphahl@bmw.de","username":"simon.westphahl"},"change_message_id":"d74b3eba469a12e66453b8a202c1ddecb877cffa","unresolved":true,"context_lines":[{"line_number":164,"context_line":"  # Sub is important as most third party services will likely match on this"},{"line_number":165,"context_line":"  # claim to determine the permissions. This is kind of an FQDN to uniquely"},{"line_number":166,"context_line":"  # identify the zuul secret used."},{"line_number":167,"context_line":"  sub: \"\u003czuul-tenant\u003e/\u003ccanonical-project-name\u003e/\u003csecret name\u003e\""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"  # Some information on the job\u0027s context might be useful.  Caution"},{"line_number":170,"context_line":"  # should be used if these are used for matching; documentation should"}],"source_content_type":"text/x-rst","patch_set":6,"id":"67e41d38_734e6064","line":167,"in_reply_to":"f3e3695c_f8b654d6","updated":"2024-09-17 06:50:13.000000000","message":"sgtm","commit_id":"20430d6ecdd8e12cea02950357c8755b2186dd2d"},{"author":{"_account_id":7186,"name":"Matthieu Huin","email":"mhuin@redhat.com","username":"mhu"},"change_message_id":"032aadff0fa1e4dc11c7cb203fb557e84d6bbb9f","unresolved":true,"context_lines":[{"line_number":216,"context_line":"2. As soon as the new key is existing the executors start using the new one when"},{"line_number":217,"context_line":"   issuing new ID tokens"},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"3. Wait for max-ttl over all tenants"},{"line_number":220,"context_line":""},{"line_number":221,"context_line":"4. Remove the old signing key"},{"line_number":222,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"e7c15dad_84a69034","line":219,"updated":"2024-09-12 13:03:37.000000000","message":"How about adding a subcommand to the admin cli in case the keys were compromised?","commit_id":"20430d6ecdd8e12cea02950357c8755b2186dd2d"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"a0bb966cbf6f47bc4a73ab45836fe063c843c095","unresolved":true,"context_lines":[{"line_number":216,"context_line":"2. As soon as the new key is existing the executors start using the new one when"},{"line_number":217,"context_line":"   issuing new ID tokens"},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"3. Wait for max-ttl over all tenants"},{"line_number":220,"context_line":""},{"line_number":221,"context_line":"4. Remove the old signing key"},{"line_number":222,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"ef361b27_27f4eaa4","line":219,"in_reply_to":"e7c15dad_84a69034","updated":"2024-09-16 16:04:15.000000000","message":"Sounds reasonable.","commit_id":"20430d6ecdd8e12cea02950357c8755b2186dd2d"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"87e1c18d25947526ee247d4f8dc80fa5422d257a","unresolved":false,"context_lines":[{"line_number":216,"context_line":"2. As soon as the new key is existing the executors start using the new one when"},{"line_number":217,"context_line":"   issuing new ID tokens"},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"3. Wait for max-ttl over all tenants"},{"line_number":220,"context_line":""},{"line_number":221,"context_line":"4. Remove the old signing key"},{"line_number":222,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"cf887b10_9c3016bf","line":219,"in_reply_to":"ef361b27_27f4eaa4","updated":"2024-09-26 20:17:44.000000000","message":"Included in PS8.","commit_id":"20430d6ecdd8e12cea02950357c8755b2186dd2d"}]}