Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keycloak support for public clients and device flow (enables sigstore) #509

Closed
Racer159 opened this issue Jun 25, 2024 · 2 comments · Fixed by #630
Closed

Keycloak support for public clients and device flow (enables sigstore) #509

Racer159 opened this issue Jun 25, 2024 · 2 comments · Fixed by #630
Assignees
Labels
enhancement New feature or request operator Issues pertaining to the UDS Operator (Pepr) security sso Issues related to the SSO stack (Keycloak/Authservice)

Comments

@Racer159
Copy link
Contributor

Racer159 commented Jun 25, 2024

Is your feature request related to a problem? Please describe.

As Kay I want to have Sigstore integrated with Keycloak so that I can sign images, git commits and more without needing to manage keys

Describe the solution you'd like

  • Given I have an image I want to sign
  • And the Sigstore stack is available in my environment
  • When I run something like cosign sign with the fulcio, rekor, and oidc-issuer urls
  • Then I am taken through the Keycloak signin process (device flow)
  • And the action completes without needing a client secret

Describe alternatives you've considered

We could not integrate with Keycloak directly and instead use something like Dex to issue the id tokens: https://dexidp.io/

Additional context

Currently the uds-core operator does not allow the creation of clients without a client secret.

@bburky
Copy link
Member

bburky commented Jun 26, 2024

I discussed localhost:* in defenseunicorns/uds-identity-config#115 (comment). I would instead recommend using the device flow.

The second part does make sense. A "client without a secret" is a "public" client in Keycloak terms (in contrast to a "confidential" client). The pepr UDS operator could be extended to support this. This is fine... but we really do need to review the impact of introducing "public" clients into UDS. They really don't make any thing worse but do kind of make some existing bugs easier to exploit.

  • That would be the (only?) public client, need to understand the side effects. This would probably be one of the few ways currently that an end user can get their hands on a JWT (authservice hides it from you)
  • If users can get JWTs and depending on some other code... we need to make sure we check aud everywhere, so that these JWTs can't incorrectly be used to log into other stuff (we don't yet check aud in the authservice code but I'm already recommending to add it, I'm unsure what most apps like GitLab etc do)
  • I think the OIDC token API may bypass the group protection code (feat: group authorization plugin uds-identity-config#111) we're doing... I can probably fix that now

@Racer159 Racer159 changed the title Keycloak support for clients without secrets (and wildcard ports in redirect URLs) - enables sigstore Keycloak support for public clients and device flow (enables sigstore) Jun 26, 2024
@Racer159
Copy link
Contributor Author

Added to the SWF board as well in case we get to it - this isn't the main use case for sigstore but it is a nice thing to enable for flexibility for users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request operator Issues pertaining to the UDS Operator (Pepr) security sso Issues related to the SSO stack (Keycloak/Authservice)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants