-
Notifications
You must be signed in to change notification settings - Fork 61
Description
Caddy has the concept of placeholders that allow injecting dynamic values in the Caddy configuration. These can come from a variety of sources such as environment variables, file contents, HTTP Request data, etc. caddy-tailscale currently populates various user data in the http.auth.user
placeholder object.
One key thing that we don't currently expose is application capabilities. This is application-specific data that is defined in the Tailscale policy file, and then passed along to the application to interpret and use. We should make this available to pass along to applications as well as for using it in Caddy CEL expressesions.
So, for example, given the following grant in a Tailscale policy file:
{
"src": "autogroup:admins",
"dst": "tag:caddy",
"app": {
"example.com/app": [
{ "admin": true },
],
},
}
You could theoretically use that in a Caddyfile with something like:
handle /admin {
@admin `{tailscale.grants["example.com/app"].admin} == true`
respond @admin `Hello admin, {{placeholder "http.auth.user.id"}}`
respond "not authorized" 401
}
or just pass it along to the backend appplication:
header_up X-Tailscale-Grants {tailscale.grants}
A good example of hooking into the placeholder replacer system can be seen in https://github.com/caddyserver/caddy/blob/master/modules/caddyhttp/replacer.go. Because the application grant itself is opaque, if we want to allow exposing it all then we can't do simple prefix matching like caddyhttp. We might have to bring in a full JSONPath library to evaluate the placeholder.