Example of token attenuation

[rossk]

I read with interest the blog about macaroons.

We have a use case where we would like to generate a Fly access token that is restricted to listing and creating certs. I’m assuming that the process will be something like:

t=$(fly tokens deploy)

echo "some-magic-incantation" | fly -t "$t" tokens attenuate

I know this is new, but it would be helpful to have some I was looking for some kind of example of something that could go in some-magic-incantation.

Has anyone done anything like this?

[catflydotio]

I don’t have first-hand knowledge but I wonder if this is interesting:

What are some ways to prevent someone from accidentally destroying an app?

This is possible with org/deploy tokens, but it’s a bit complicated. Quick overview: Org tokens are limited to managing a single org and its resources Deploy tokens are limited to managing a single app and its resources From the sounds of it, an org token most suits your needs, but just letting you know it’s possible to do a similar thing with a deploy token if needs be. First, create an org token. You have to do this interactively at the moment, there’s no way to pass the organization as a …

[rossk]

I’d seen that actually. I’m rather assuming that I can build a caveat like

{ "type": "Resource", "body": { "method": "POST or GET", "uri": "/something/something/certificates" } }

Not sure if that’s even possible, but given the blog about how they are implemented, I’d imagine something like that might be, or might be someday.

I think that being able to do this kind of attenuation is the promise of macaroons?

[thomas]

@btoews may correct me on this but I’m not sure if we’ve lit certificates up yet with macaroon caveats? Assuming this is all stuff happening in the API (I’m pretty sure it is), it shouldn’t be hard to do.

(Don’t take this as a final word; every time I’ve assumed something doesn’t work with macaroons yet, Ben has turned around and showed me that it does).

The current UX for this is what you expect it to be; flyctl tokens attenuate reads a JSON caveat from stdin (let me figure out what the shape of that JSON would be for you!) and spits a new attenuated token out.

superfly/flyctl/blob/master/internal/command/tokens/attenuate.go

[btoews]

@rossk

I was looking for some kind of example of something that could go in some-magic-incantation.

Proving some examples is a great idea I put up some examples of your specific use case here.

A few things to note:

We don’t have specific caveats for managing certificates (we can and should add this). The best workaround is to allowlist the GraphQL mutations that the token can be used for. In the case of adding certificates to an app, that’s the addCertificate mutation.

Allowlisting mutations, prevents the token from being used for anything but those mutations. So the add-cert token won’t be allowed to list certs. You’d want to create a separate app-ready-only token for that. Juggling multiple tokens is kind of a pain, but it works.

Lastly, it’s a bit hard to use flyctl with tokens that are super locked down because it tends to do a bit more than the bare minimum of what you asked for. In the example of flyctl certs add, it first calls the addCertificate mutation and then attempts to read the app. So, running flyctl certs add will result in an error message from flyctl even though the addCertificate mutation succeeded.

[thomas]

One thing we should say here is that this JSON format is NOT THE FINAL WORD in how we’re expressing token privileges. If any of you have opinions on what the right way to express these conditions (caveats, each of which pulls away further privileges from a token) is, we’d love to hear about it.