Namespace borders not applied by default

[GrigoriyMikhalkin]

As stated in documentation:

When using ACL's the Namespace borders are no longer applied.

Implying that the default behavior is to disallow communication between namespaces. By digging into the code we can find the comment:

// If ACLs rules are defined, filter visible host list with the ACLs
// else use the classic namespace scope

Which was actually true previously, as peers were filtered by namespace.

The question is, should we assume that documentation is outdated(and fix it and provide an example with ACLs for achieving the same behavior?) or should the stated behavior be reimplemented?

There's definitely demand for namespace borders(metal-stack/metal-roles#105 and #841).

[doebi]

Coming across this issue as I created a second namespace right now, just to find out that from a ACL perspective it made no difference at all. I explicitly created a second namespace for a group of devices that have nothing to do with the first one.

I would love to see a per-default blocking between namespace as this is what most users would expect.

Another note: I was surprised to see that the new namespace uses the same IP pool. Is there a reasoning behind, which I do not see yet?
My thinking was that namespaces are complete distinct networks (tailnets).

[razza-guhl]

I notice the same behavior, devices in different namespaces can communicate with each other per default / without ACLs.

I am unsure if it is a bug because this behavior also seems logical - without ACLs there no traffic restrictions.

On the other hand, this behavior is misleading because it is documented differently. Users might get unwanted results.

[madjam002]

Another note: I was surprised to see that the new namespace uses the same IP pool. Is there a reasoning behind, which I do not see yet? My thinking was that namespaces are complete distinct networks (tailnets).

Tailnets in vanilla Tailscale are not distinct networks and everyone actually shares the 100.64.0.0/10 space. This behaviour is mirrored in Headscale. In Tailscale however, they isolate peers based on the Tailnet, even though the address space is shared across all users.

If you're using ACL rules I think it makes sense for Headscale not to get in the way and instead you can define the boundaries for your use-case in ACL rules.

[darookee]

Sorry to resurrect this issue but I'm not sure if this is marked as completed and working as intended now and my assumptions are incorrect or if it's a bug that still exists.

The documentation states When using ACL's the User borders are no longer applied. All machines whichever the User have the ability to communicate with other hosts as long as the ACL's permits this exchange.. As I'm not using ACLs I expect devices/nodes/machines that are registerred to a nother user/namespace cannot 'see' each other.

For example:

• User1, Nodes Host1 and Host2
• User2, Nodes Host3 and Host4

=> I would assume that Host1 and Host2 can communicate, Host1 and Host3 cannot

Is my interpretion of the documentation incorrect?

I'm currently using 0.22.3 (which was released on 2023-05-12, so two days after this issue was closed, so I would asume if it was a bug it would be fixed in this version).

[Hobby-Student]

I'm currently testing 0.22.3 (podman rootless) and expected the namespaces/users to be isolated. My tests gave me the following results:

• Using no ACL file --> all Nodes can access each other across all namespaces/users
• Using an ACL file with { "action": "accept", "src": ["namespace"], "dst": ["namespace:*"] } (namespace has to be replaced with the actual name) for every namespace/user --> expected behaviour of splitting the namespaces/users

I started to tag all nodes to prevent accidental access between the namespaces/users. For now this seems to be the best way for my usecase.

Offtopic:
Thank you very much for this great project. I just started few days ago and it's amazing!

[ohdearaugustin]

Maybe you could test it on a new alpha release if this still is a use there, as we won't fix anything in 0.23.3 anymore.

Can't answer if it should have been fixed in 0.22.3.

[Hobby-Student]

Maybe you could test it on a new alpha release if this still is a use there, as we won't fix anything in 0.23.3 anymore.

Can't answer if it should have been fixed in 0.22.3.

I did try 0.23.0-alpha9 and ran (unknowingly) straight into the postgres bug. While troubleshooting I switched to 0.22.3 (with sqlite in the end). It feels more reliable to stick with it and not using an alpha version. Using an ACL file is no problem for me, because I need one to reach my goal. Just wanted to share my findings.