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

[Feature] Sub-ACLs can be made with the abbilty to affect a limited-number of devices #951

New Issue
Closed
opened 2025-12-29 02:26:37 +01:00 by adam · 3 comments
adam commented 2025-12-29 02:26:37 +01:00
Owner
Copy Link

Originally created by @SpiderUnderUrBed on GitHub (Feb 22, 2025).

Use case

Me and some other people want to use my tailnet hosted on my vps, under my headscale domain, they would also like to configure their own exit nodes, and several other aspects and rules when it comes to their devices, I have quite a few people who want to do this, the use-case being that, there isnt a restriction on users with headscale, as well as some other benefits, and they intend to configure the ACL regularly, given that I am not available alot of the time, it would make this difficult, and I think configuring multiple ACL instances is not preferably and could still lead to some security issues on my end.

Description

What I propose is that with ACL's you can essentially include a sub-acl, with restrictions, such as devices it can affect, ip ranges, and so on, this way you can ensure security of whatever device you are using when hosting headscale as well as allowing freedom to users who wants to configure their own devices and who can access them. I dont have a idea on a fleshed-out implementation of this but I think this summerises what I would like to have done.

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 @SpiderUnderUrBed on GitHub (Feb 22, 2025). ### Use case Me and some other people want to use my tailnet hosted on my vps, under my headscale domain, they would also like to configure their own exit nodes, and several other aspects and rules when it comes to their devices, I have quite a few people who want to do this, the use-case being that, there isnt a restriction on users with headscale, as well as some other benefits, and they intend to configure the ACL regularly, given that I am not available alot of the time, it would make this difficult, and I think configuring multiple ACL instances is not preferably and could still lead to some security issues on my end. ### Description What I propose is that with ACL's you can essentially include a sub-acl, with restrictions, such as devices it can affect, ip ranges, and so on, this way you can ensure security of whatever device you are using when hosting headscale as well as allowing freedom to users who wants to configure their own devices and who can access them. I dont have a idea on a fleshed-out implementation of this but I think this summerises what I would like to have done. ### Contribution - [ ] I can write the design doc for this feature - [ ] I can contribute this feature ### How can it be implemented? _No response_
adam added the enhancementstale labels 2025-12-29 02:26:37 +01:00
adam closed this issue 2025-12-29 02:26:37 +01:00
adam commented 2025-12-29 02:26:37 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Feb 22, 2025):

This sounds like features that does not align with upstream. We strive to keep it in sync and we are currently behind on the basics so adding our own features custom behaviour is likely infeasible. At least for years.

@kradalby commented on GitHub (Feb 22, 2025): This sounds like features that does not align with upstream. We strive to keep it in sync and we are currently behind on the basics so adding our own features custom behaviour is likely infeasible. At least for years.
adam commented 2025-12-29 02:26:38 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (May 24, 2025):

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

@github-actions[bot] commented on GitHub (May 24, 2025): This issue is stale because it has been open for 90 days with no activity.
adam commented 2025-12-29 02:26:38 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (May 31, 2025):

This issue was closed because it has been inactive for 14 days since being marked as stale.

@github-actions[bot] commented on GitHub (May 31, 2025): This issue was closed because it has been inactive for 14 days since being marked as stale.
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 stale
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#951
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?