starred/headscale
1
0
Fork 0
mirror of https://github.com/juanfont/headscale.git synced 2026-01-12 04:10:32 +01:00
Code Issues 98 Packages Projects Releases 10 Wiki Activity

[Feature] Expose pending interactive registrations via admin API/CLI #1087

New Issue
Open
opened 2025-12-29 02:28:12 +01:00 by adam · 2 comments
adam commented 2025-12-29 02:28:12 +01:00
Owner
Copy Link

Originally created by @oneingan on GitHub (Aug 18, 2025).

Use case

Use cases

  • An admin-side service or UI that:
    • lists pending interactive registrations
    • approves a subset based on an allow/deny list, or after human review
  • Automation using a periodic job that approves known devices, while still using registrationId.

Description

Background

  • Since the registrationId flow was introduced (replacing mkey-based approval for interactive registration), pending registrations are short‑lived and tracked in memory until approved (AuthURL follow-up).
  • This decouples identity from machine keys and fixes multi-user/same-machine cases, which is great.

Problem today

  • For interactive registrations there’s no way for an external controller to see “what’s pending” and act on it.
  • The pending registrations live only in the in-memory registration cache:
  • As a result, an external approval service cannot discover pending registrationIds to approve them, and polling the DB won’t help (not persisted).

Is exposing pending interactive registrations acceptable within headscale’s design?

Contribution

  • I can write the design doc for this feature
  • I can contribute this feature

How can it be implemented?

No response

Originally created by @oneingan on GitHub (Aug 18, 2025). ### Use case Use cases - An admin-side service or UI that: - lists pending interactive registrations - approves a subset based on an allow/deny list, or after human review - Automation using a periodic job that approves known devices, while still using registrationId. ### Description Background - Since the registrationId flow was introduced (replacing mkey-based approval for interactive registration), pending registrations are short‑lived and tracked in memory until approved (AuthURL follow-up). - This decouples identity from machine keys and fixes multi-user/same-machine cases, which is great. Problem today - For interactive registrations there’s no way for an external controller to see “what’s pending” and act on it. - The pending registrations live only in the in-memory registration cache: - As a result, an external approval service cannot discover pending registrationIds to approve them, and polling the DB won’t help (not persisted). Is exposing pending interactive registrations acceptable within headscale’s design? ### Contribution - [x] I can write the design doc for this feature - [x] I can contribute this feature ### How can it be implemented? _No response_
adam added the enhancementno-stale-bot labels 2025-12-29 02:28:12 +01:00
adam commented 2025-12-29 02:28:12 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Aug 19, 2025):

  • An admin-side service or UI that:
    • lists pending interactive registrations
    • approves a subset based on an allow/deny list, or after human review
  • Automation using a periodic job that approves known devices, while still using registrationId.

I believe that if you have access to the registration token, then the "write" part here is already solved right? Since the approval of registrations is already implemented in the API (and used in the CLI)?

So this should only be about programatically expose the current pending registrations?

Is exposing pending interactive registrations acceptable within headscale’s design?

I would like to hear others opinions in regards to exposing this, but as far as I can think, it should not be a problem and it should not expose any additional attack surface because:

  • If you have API access, you can already issue pre authenticated keys
  • API access can already approve/register the machines, you just need the ID.

I cannot remember how much metadata is associated with the registration key, I think it is at least the nodekey/machinekey, but not sure if you have enough to make it a nice UX (hostname etc).

My only holdback right now is that I kind of want to explore to reimplement (#2305), so adding more to the current one is more work later, but should be ok.

@kradalby commented on GitHub (Aug 19, 2025): > - An admin-side service or UI that: > - lists pending interactive registrations > - approves a subset based on an allow/deny list, or after human review > - Automation using a periodic job that approves known devices, while still using registrationId. I believe that if you have access to the registration token, then the "write" part here is already solved right? Since the approval of registrations is already implemented in the API (and used in the CLI)? So this should only be about programatically expose the current pending registrations? > Is exposing pending interactive registrations acceptable within headscale’s design? I would like to hear others opinions in regards to exposing this, but as far as I can think, it should not be a problem and it should not expose any additional attack surface because: - If you have API access, you can already issue pre authenticated keys - API access can already approve/register the machines, you just need the ID. I cannot remember how much metadata is associated with the registration key, I think it is at least the nodekey/machinekey, but not sure if you have enough to make it a nice UX (hostname etc). My only holdback right now is that I kind of want to explore to reimplement (#2305), so adding more to the current one is more work later, but should be ok.
adam commented 2025-12-29 02:28:12 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Nov 18, 2025):

This issue is stale because it has been open for 90 days with no activity.

@github-actions[bot] commented on GitHub (Nov 18, 2025): This issue is stale because it has been open for 90 days with no activity.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
CLI
DERP
DNS
Nix
OIDC
SSH
bug
database
documentation
duplicate
enhancement
faq
good first issue
grants
help wanted
might-come
needs design doc
needs investigation
no-stale-bot
out of scope
performance
policy 📝
pull-request
Mirrored from GitHub Pull Request
 question
regression
routes
stale
tags
tailscale-feature-gap
well described ❤️
wontfix
No Label enhancement no-stale-bot
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#1087
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?