-
-
Notifications
You must be signed in to change notification settings - Fork 50
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
api: Scoped tokens #347
Comments
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 Token is authorized to edit/create:
but not
Multiple tokens should be possible with the same set of permissions. |
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). |
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. |
consider to allow token expiration after a certain time |
|
drafting in #456 |
The migration sets perm_manage_tokens = True for all existing tokens, and then sets the default to False. Related: #347
The migration sets `perm_manage_tokens = True` for all existing tokens, and then sets the default to `False`. Related: #347
The migration sets `perm_manage_tokens = True` for all existing tokens, and then sets the default to `False`. Related: #347
The migration sets `perm_manage_tokens = True` for all existing tokens, and then sets the default to `False`. Related: #347
The migration sets `perm_manage_tokens = True` for all existing tokens, and then sets the default to `False`. Related: #347
The migration sets `perm_manage_tokens = True` for all existing tokens, and then sets the default to `False`. Related: #347
The migration sets `perm_manage_tokens = True` for all existing tokens, and then sets the default to `False`. Related: #347
The migration sets `perm_manage_tokens = True` for all existing tokens, and then sets the default to `False`. Related: #347
The migration sets `perm_manage_tokens = True` for all existing tokens, and then sets the default to `False`. Related: #347
The migration sets `perm_manage_tokens = True` for all existing tokens, and then sets the default to `False`. Related: #347
The migration sets `perm_manage_tokens = True` for all existing tokens, and then sets the default to `False`. Related: #347
The migration sets `perm_manage_tokens = True` for all existing tokens, and then sets the default to `False`. Related: #347
The migration sets `perm_manage_tokens = True` for all existing tokens, and then sets the default to `False`. Related: #347
#474 (subnet scoping) is done and has been deployed. |
#478 (expiration by age and non-use) is done and has been deployed. |
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. |
Great to see that some parts of this feature are already implemented. |
I saw the accepted pull request to implement the scoped tokens. Do you have any idea when it will be put into production? |
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). |
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? |
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. |
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 :) |
Not really internal data structures, rather interface aspects / exposed schemas. Such as: how to deal with wildcards like Things like that -- I'll let you know. |
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. |
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 |
e.g. by domain, or use case (_acme-challenge)
The text was updated successfully, but these errors were encountered: