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

Groups in ACL #94

New Issue
Closed
opened 2025-12-29 01:22:55 +01:00 by adam · 5 comments
adam commented 2025-12-29 01:22:55 +01:00
Owner
Copy Link

Originally created by @jhjadmin on GitHub (Jan 7, 2022).

Issue description

Adding "Groups" to ACL file only works when using "namespace". I thougt using "node@namespace" would make more sense but when trying this, I get the ERR Could not load the ACL policy error="invalid namespace" path=/etc/headscale/acl.hujson

To Reproduce

Just add a "Groups" section to the acl file and add an entry only with the name of the namespace. That will work, but when you add a host part in front of the namespace, like node@namespace, it throws the mentioned error "invalid namespace"
BTW same issue for "Users" as well.

Context info

headscale v0.12.1
Debian 11, 5.13.19

Originally created by @jhjadmin on GitHub (Jan 7, 2022). <!-- If you have a question, please consider using our Discord for asking questions --> **Issue description** Adding "Groups" to ACL file only works when using "namespace". I thougt using "node@namespace" would make more sense but when trying this, I get the ERR Could not load the ACL policy error="invalid namespace" path=/etc/headscale/acl.hujson **To Reproduce** Just add a "Groups" section to the acl file and add an entry only with the name of the namespace. That will work, but when you add a host part in front of the namespace, like node@namespace, it throws the mentioned error "invalid namespace" BTW same issue for "Users" as well. **Context info** headscale v0.12.1 Debian 11, 5.13.19 <!-- Please add relevant information about your system. For example: - Version of headscale used - Version of tailscale client - OS (e.g. Linux, Mac, Cygwin, WSL, etc.) and version - Kernel version - The relevant config parameters you used - Log output -->
adam added the bug label 2025-12-29 01:22:55 +01:00
adam closed this issue 2025-12-29 01:22:55 +01:00
adam commented 2025-12-29 01:22:55 +01:00
Author
Owner
Copy Link

@jhjadmin commented on GitHub (Jan 7, 2022):

After getting a bit deeper into the concept, I am not sure if it is working as intended. What I now did, is creating several namespaces (e.g. one for servers and one for clients) and sharing the nodes between the namespaces. With that deployment I am now able to use the "Group" logic in the acl.

Is this just a workaround or is that the way, how groups are working in headscale acl's?

@jhjadmin commented on GitHub (Jan 7, 2022): After getting a bit deeper into the concept, I am not sure if it is working as intended. What I now did, is creating several namespaces (e.g. one for servers and one for clients) and sharing the nodes between the namespaces. With that deployment I am now able to use the "Group" logic in the acl. Is this just a workaround or is that the way, how groups are working in headscale acl's?
adam commented 2025-12-29 01:22:56 +01:00
Author
Owner
Copy Link

@restanrm commented on GitHub (Jan 7, 2022):

Currently the namespaces are used as user in ACL's. Some work needs to be done regarding this issue.

@restanrm commented on GitHub (Jan 7, 2022): Currently the namespaces are used as `user` in ACL's. Some work needs to be done regarding this issue.
adam commented 2025-12-29 01:22:56 +01:00
Author
Owner
Copy Link

@jhjadmin commented on GitHub (Jan 10, 2022):

Means that sometime it may work as I described and my workaround is obsolete?

@jhjadmin commented on GitHub (Jan 10, 2022): Means that sometime it may work as I described and my workaround is obsolete?
adam commented 2025-12-29 01:22:57 +01:00
Author
Owner
Copy Link

@restanrm commented on GitHub (Jan 10, 2022):

Currently the only supported solution is to create multiple namespaces and share the nodes. You're workaround is not obsolete.

@restanrm commented on GitHub (Jan 10, 2022): Currently the only supported solution is to create multiple namespaces and share the nodes. You're workaround is not obsolete.
adam commented 2025-12-29 01:22:57 +01:00
Author
Owner
Copy Link

@jhjadmin commented on GitHub (Jan 10, 2022):

ok, further development will show then. Thanks for your answers.

@jhjadmin commented on GitHub (Jan 10, 2022): ok, further development will show then. Thanks for your answers.
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 bug
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#94
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?