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

az-jenkins-controller: handle auth by delegating to oauth2-proxy #352

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

flokli
Copy link
Collaborator

@flokli flokli commented Jan 22, 2025

This configures caddy to delegate authentication to a deployment of
oauth2-proxy, which will redirect the user to GitHub for authentication.

We peek at the user profile, and in case they're part of the tiiuae
organization, let them in.

As GitHub redirects back to the application after the users consent, we
need to have one GitHub application per Jenkins deployment.
Said GitHub OAuth application also needs to have access to see
membership in the tiiuae application.

This will become easier in the future by adding a "trampoline" IdP
like Dex in between, allowing us to manage individual clients and their
redirect URIs locally, with only the Dex URL needing to be configured
in GitHub.

@flokli
Copy link
Collaborator Author

flokli commented Jan 22, 2025

This is currently blocked on the oauth2 application setup, as the one that's configured isn't allowed to see membership in the tiiuae org.

This changes the jenkins-casc variable to be a data structure, which can
be extended later on.

We write it out to JSON (which is also valid YAML of course), to be
re-ingested by Jenkins.

We cannot keep YAML as an input format, as Nix cannot parse YAML without
using IFD.

Signed-off-by: Florian Klink <flokli@flokli.de>
This means we can stop using jenkins-job-builder, which wants to
authenticate using jenkins-cli.

Signed-off-by: Florian Klink <flokli@flokli.de>
This configures caddy to delegate authentication to a deployment of
oauth2-proxy, which will redirect the user to GitHub for authentication.

We peek at the user profile, and in case they're part of the tiiuae
organization, let them in.

As GitHub redirects back to the application after the users consent, we
need to have one GitHub application per Jenkins deployment.
Said GitHub OAuth application also needs to have access to see
membership in the tiiuae application.

This will become easier in the future by adding a "trampoline" IdP
like Dex in between, allowing us to manage individual clients and their
redirect URIs locally, with only the Dex URL needing to be configured
in GitHub.

Once the user gets redirected back, it's passed through to Jenkins.
We inject certain X-Forwarded-* headers into the request, which Jenkins
picks up.

Signed-off-by: Florian Klink <flokli@flokli.de>
The only thing this systemd service still did was disabling the initial
setup, by running a groovy script (via jenkins-cli), and then triggering
a Jenkins reboot.

As we don't need the initial password anymore, we can simply disable the
setup wizard entirely, and remove the need for that unit alltogether.

Signed-off-by: Florian Klink <flokli@flokli.de>
@flokli
Copy link
Collaborator Author

flokli commented Feb 4, 2025

Depends on #361. Might also need changes to deal with authentication of the agents.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant