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

Require JWTs for write/delete operations on the "unsecured" route #16

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

Conversation

LRitzdorf
Copy link
Collaborator

This PR implements JWT validation for sensitive (i.e. writing and deleting) operations on the "unsecured" route, i.e. the one that doesn't require auth for basic data retrieval. This requires a little bit of weirdness with multiple routers, but should generally make sense.

Resolves #14

@LRitzdorf
Copy link
Collaborator Author

I can build this on my system, but am not in a position to properly test my changes — that requires access to a functioning OPAAL instance, without which the code doesn't get to the point of adding the newly-created secondary router which enforces JWT validation. Any chance @travisbcotton or @davidallendj could help with this?

@davidallendj
Copy link
Contributor

davidallendj commented Oct 8, 2024

I can have a look at it tomorrow at some point. Do you have a guide or instructions to test?

@LRitzdorf
Copy link
Collaborator Author

The only material change is that POST/PUT/DELETE requests on the unsecured route should now require a JWT (GETs, of course, still do not). E.g. attempting to add cloud-init data without a JWT should fail

@travisbcotton
Copy link
Collaborator

I built a new container image and tried running it in an existing OpenCHAMI environment.

Initializing JWKS from URL: http://opaal:3333/keys
panic: chi: attempting to Mount() a handler on an existing path, '/cloud-init'

goroutine 1 [running]:
github.com/go-chi/chi/v5.(*Mux).Mount(0xc0001100c0, {0x842d28, 0xb}, {0x8dede0, 0xc000110180?})
	/root/go/pkg/mod/github.com/go-chi/chi/[email protected]/mux.go:303 +0x445
main.main()
	/tmp/cloud-init-server/cloud-init/cmd/cloud-init-server/main.go:66 +0x8dc

@travisbcotton
Copy link
Collaborator

I don't think you can Mount multiple times to the same path:

	router.Mount("/cloud-init", router_unsec)
	router.Mount("/cloud-init", router_unsec_writes)

@davidallendj
Copy link
Contributor

I don't think you can Mount multiple times to the same path:

	router.Mount("/cloud-init", router_unsec)
	router.Mount("/cloud-init", router_unsec_writes)

Were these meant to be the same endpoint but different routers or maybe just a typo?

@davidallendj
Copy link
Contributor

davidallendj commented Oct 8, 2024

This is what I get with a locally built cloud-in container without the JWKS_URL being set:

Initializing JWKS from URL:                                                                                                                                                                                      
JWKS initialization failed: failed to fetch "": Get "": unsupported protocol scheme ""

Should this be an error saying that the JWKS URL is required or am I doing something wrong?

Adding the JWKS_URL is also giving me the same error as @travisbcotton.

@LRitzdorf
Copy link
Collaborator Author

I don't think you can Mount multiple times to the same path:

	router.Mount("/cloud-init", router_unsec)
	router.Mount("/cloud-init", router_unsec_writes)

Ah, that'd make sense. Okay, time to dig back into how routers work, then. Currently, we add JWT validation middleware to an entire router, which clearly has to change.

Initializing JWKS from URL:                                                                                                                                                                                      
JWKS initialization failed: failed to fetch "": Get "": unsupported protocol scheme ""

Okay, yes, good catch. Forgot that the Dockerfile overrides defaults in the Go program itself; that's an easy fix.

@alexlovelltroy alexlovelltroy self-assigned this Oct 24, 2024
@alexlovelltroy
Copy link
Member

I was having a little trouble understanding the intent of the subrouters so I followed what I thought the intent was and added comments to make it clearer. We should review this at the next standup.

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.

[DEV]Protect insecure cloud-init endpoints for everything but GET
4 participants