Repository navigation
tufclient: authenticate repo requests as this machine #82
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -77,3 +77,14 @@ cache_dir = "/var/lib/quarry-client/latest-metadata" | |
| ## overridden by setting the following two settings. | ||
| #meta_root_url = "https://tufmetadata.example.com/tuf/%m" | ||
| #data_root_url = "https://cloud-storage.example.com/repo/%m/foobar" | ||
|
|
||
| ## Requests to the meta_root_url host can be signed as this machine, for | ||
| ## servers that only serve a repository to the machine it belongs to. Each | ||
| ## request then carries the machine's WIMSE workload identity token for | ||
| ## "audience", from the varlink service at "varlink" implementing | ||
| ## com.amutable.IdentityAgent (default: amutablectl's, at | ||
| ## unix:/run/amutable/com.amutable.IdentityAgent), and an RFC 9421 signature | ||
| ## by a key quarry-client holds in memory and the token binds. Requests to | ||
| ## other hosts (such as a separate data_root_url) are not signed. "wimse" is | ||
| ## the only supported type. | ||
| #auth = { type = "wimse", audience = "urn:amutable:quarry-worker" } | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As I mentioned when we first talked about this, links make this model a little complicated -- I think we would need to model this more like "providers" and then eventually we can come up with some kind of allow-list policy for providers.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To flesh this out a bit more -- I think links would likely need to be able to provide something like "I want a provider with this rough shape of type + audience/user fields" and then the policy would determine whether a link can request such a provider and which one should be used. The "shape" thing is needed because using provider identifiers is too fragile and allowing all of the bits of a provider to be configured is an obvious security issue (a hypothetical basic auth provider might support getting the user and password from a file and allowing a link to configure it would allow for local file leaks). The simplest policy would be to only allow a repository to use providers that the linking repository has access to (which would walk back to the "root" set specified in configuration). That might be okay for the first version but that is not really the right model -- ideally you would also want the provider to specify which repositories are allowed to use the auth. The WIT-signed headers include the whole request URI so for the WIMSE provider this restriction isn't strictly required but I'm just a little apprehensive about letting a repo specify what auth the client should send without any restrictions. |
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is quite unfortunate, though since only the method and URI are included in the signature I guess we can eventually pre-compute the signed headers and provide them to
sd-pullonce it switches to UAPI.16 (and a UAPI.16 extension is added to support it).@davidstrauss Do we plan to extend the scope of things we would sign for WIMSE/WIT? If we start signing other headers then we would just need to accept that we are going to be proxying data a lot. (Though we could of course choose to proxy based n what headers are needed to be signed...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might need more context, but I wasn't expecting we'd use WIT/WIMSE for repo auth at all. I thought we only wanted to rely on authZ mechanisms that (1) we can delegate to the delivery system itself (mainly for cost, DoS protection, and maybe some basic infrastructure disclosure control) or (2) we can achieve via sealing the data going through Quarry (for load-bearing secret delivery to specific machines).
In short, I assumed our entire model would work fine with publicly readable buckets.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the "front door" access control we discussed in January, BTW.