api: Scoped tokens

[peterthomassen]

e.g. by domain, or use case (_acme-challenge)

[appliedprivacy]

coming from: https://talk.desec.io/t/restricted-access-tokens-for-letsencrypt-dns-challenge/37

When designing scoped tokens please allow for a token that is authorized to create multiple
DNS records in one or multiple zones so that this use case can be achieved:

Token is authorized to edit/create:

• _acme-challenge.desec1.example.com TXT
• _acme-challenge.desec2.example.com TXT
• _acme-challenge.desec1.example2.com TXT

but not

• _acme-challenge.desec1.example.com AAAA
• _acme-challenge.desec3.example.com
• _acme-challenge.desec4.example2.com

Multiple tokens should be possible with the same set of permissions.
This would be handy when a multiple servers requests a certificate for multiple domains using the dns-01 challenge.

[Knight1]

From my other Ticket I would like to see a Limit for IP addresses in Ranges like (1.1.1.1/32), (1.1.1.1/30).

[nils-wisiol]

I'd love to see tokens limited by IP range, but any implementation should be compatible to further extension of scopes, e.g. by domain, namespace (as in "everything below foobar.example.com"), record type, yada yada.

[peterthomassen]

consider to allow token expiration after a certain time

[peterthomassen]

blocked by #430

[peterthomassen]

drafting in #456

[peterthomassen]

#474 (subnet scoping) is done and has been deployed.

[peterthomassen]

#478 (expiration by age and non-use) is done and has been deployed.

[Valodim]

This is pretty useful already, thanks 👍

As originally requested, please consider implementing scoped tokens by domain and record type. That would be a killer feature and a considerable security improvement over the current "all or nothing" permission scheme.

[generalmanager]

Great to see that some parts of this feature are already implemented.
I'm especially looking forward to be able to hand out subdomain-specific tokens to be saved on several routers, vms and appliances which update dyndns records of my custom domains.
Right now I have to use several accounts as I don't like credentials with rw access to my whole account saved on hardware of customers, family & friends.

[MrSuicideParrot]

I saw the accepted pull request to implement the scoped tokens. Do you have any idea when it will be put into production?

[peterthomassen]

It is in production. The docs describe in which ways the token scope can be narrowed, and how to do that using the API: https://desec.readthedocs.io/en/latest/auth/tokens.html#token-scoping-domain-policies

Some more features may come in the future (e.g. ACME-only tokens).

[Valodim]

Great to see this moving forward, I appreciate it 👍

I did notice that token access can only be narrowed to dyndns or RRSet access per managed domain, and not to specific subdomains or record types. Those latter options will make the feature really shine. I imagine is why this issue is still open, are there any plans yet along those lines?

[peterthomassen]

Yes, that's why the issue is open (and ACME scoping, which is kind of a sub-case) of what you're proposing. However, I'm planning to work on 2FA (#316) first (starting this month).

Subdomains / record types token scoping is challenging as far as the API data schemas are concerned. I played with it a bit on paper a while ago, and couldn't come up with "the obvious solution". Perhaps we can do some sparring when the time has come.

[Valodim]

Subdomains / record types token scoping is challenging as far as the API data schemas are concerned. I played with it a bit on paper a while ago, and couldn't come up with "the obvious solution". Perhaps we can do some sparring when the time has come.

I don't know much about desec's internals, but feel free to give me a ping if you need someone to bounce some thoughts off of :)

[peterthomassen]

Not really internal data structures, rather interface aspects / exposed schemas. Such as: how to deal with wildcards like _acme-challenge.*.$DOMAIN? This particular instance is not a valid DNS name, as DNS requires wildcard labels to the leftmost label; parsing with dnspython may fail etc. So perhaps there should be an perm_acme permission flag, instead of going the subname route? Also, how does that interact with building a client (aka: does it integrate nicely with the web GUI)?

Things like that -- I'll let you know.

[s-hamann]

So perhaps there should be an perm_acme permission flag, instead of going the subname route?

Personally, I would prefer the subname/record-type route. It covers more use cases. For example, my own ACME-update token also needs to have permission to manage my TLSA records on certificate renewal.

[peterthomassen]

For those interested: We're working on an implementation of this feature, and it is mostly done (modulo review + potential adjustments). If you're interested, you can preview the new functionality's documentation here: https://desec--840.org.readthedocs.build/en/840/auth/tokens.html#token-scoping-policies