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

Rearchitect to remove Gin server package, add JWT-protected HTTP routes #10

Merged
merged 23 commits into from
Jul 17, 2024

Conversation

LRitzdorf
Copy link
Collaborator

@LRitzdorf LRitzdorf commented Jul 9, 2024

This PR is a rework of the cloud-init server's high-level structure. Notably, it:

  • Replaces the Gin web server package with the OpenCHAMI-standard Chi package
  • Adds a set of endpoints under /cloud-init-secure whose access is controlled via JWT authorization
    • This is to be used in conjunction with OpenCHAMI/TPM-manager, to allow secret storage in cloud-init without exposure to compute clients
  • When requesting the cloud-init configuration for a name, the name is initially parsed as a MAC address. If no matching MACs are found, it is treated as a hostname, and used as a lookup key into the internal datastore. This allows admins to query configuration data for a particular node without using its MAC address, and to query configuration data for a node group (which was not previously possible).
  • We now accept an OIDC token endpoint, rather than a single static JWT. This is used to fetch new JWTs as required throughout the service's lifetime, allowing it to run for longer than the lifetime of a single token.

See also, the updated CHANGELOG.md.

alexlovelltroy and others added 16 commits May 7, 2024 13:18
This code was originally written before OpenCHAMI services standardized
on Chi. Also, Gin uses a very different Context-based interface for
handler functions, and is therefore not easily interoperable with
existing handlers like those used for JWT verification.
We now return a 404 error when the cloud-init datastore for the
requested name is empty. In context, this means that the requested name:
    a) has no node-specific cloud-init data assocated with it
    b) is not part of any SMD groups whose data it would otherwise
       inherit
The actual verification isn't yet implemented — this work forms a base
for that.
This copies much JWKS helper code (`cmd/cloud-init-server/auth.go`) from
https://github.com/OpenCHAMI/smd/blob/cdac4f1a606401a2b150513b935143238e3eb026/cmd/smd/routers.go
with certain irrelevant-to-us parts stripped out.
This is the key that must be included in future GET/DELETE/etc. requests
in order to access the node in question. May be different from the
originally specified name, particularly if the latter includes special
characters which may not be URL-safe.
This ensures the flag is always given a value (even an empty one),
preventing parse errors.
This seriously complicates the data-retrieval process, especially when
talking to SMD. Also, since we're dealing with MAC addresses here, the
colons will *always* be "slugged" into dashes, so there's no real way to
avoid this mangling.
This is the case when no xname can be found for the given MAC address,
in which case we consider the possibility that the input isn't a MAC
address at all, and use it as directly as a datastore key.
Apparently Chi gets mad if you don't follow their expected setup order.
These are based on the routers present in SMD.
}

// Refresh the cached access token, using the provided JWT server
func (s *SMDClient) RefreshToken() error {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One thing to keep in mind is that OPAAL's token endpoint returns a JWT bearer token without having to perform an authorization grant that's expected from OAuth 2 servers. I may be worth implementing some way to do a client credentials grant (which is what OPAAL is doing here) to get a token later on. For now though, this should be fine.

Copy link

@davidallendj davidallendj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. I left one comment specifically about the OPAAL token endpoint and how it does not require performing an authorization grant like a typical OAuth 2 server implementation would.

Copy link
Contributor

@alexlovelltroy alexlovelltroy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@alexlovelltroy alexlovelltroy merged commit e99542a into main Jul 17, 2024
@LRitzdorf LRitzdorf deleted the lritzdorf/rearchitect branch July 17, 2024 16:35
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.

3 participants