This task is a wide-ranging discussion of providing policy containers for groups of objects. Use cases broadly include:
- Restricting unprivileged users (like contractors or clients) to a small section of your install.
- Creating privileged areas (like a "Security" space) that make it easier to restrict access to a lot of objects.
These containers are called "Spaces".
Spaces mostly don't do anything new, per se (you can do everything that Spaces allow by manually setting granular policies on individual objects), they just make it a lot easier to apply policies consistently across larger groups of objects, since it's painful and error-prone to manually edit large numbers of objects.
90% of the discussion on this task is out of date or not particularly relevant to the modern plans for Spaces.
---
// Older Discussion //
Until recently, I've sort of been operating under the assumption that when you tag an object with a project, we'll (in some cases) give it that project's policy ("Visible to: Members of project X") by default. But I'm not actually sure this makes much sense.
Some discussion in T2628.
The arguments for doing this are:
- It makes it easier to set policies, since you just add a project instead of separately setting a project and a policy.
- In some cases, it seems clearly correct (for example, a "Security" project should probably imply "Visible to: Security").
However, some arguments against it are:
- Projects are one-to-many, but policies aren't really. Intersecting all the project policies is really complicated and computationally intensive, and probably not what anyone wants. An approach discussed in T2628 is having a "primary" project, but I think this is messy and confusing too.
- To the degree that we have a "primary" project, this creates weirdness when you add a secondary project which normally sets policies -- we either prevent it (weird, feels arbitrary) or add it as non-primary project which doesn't affect policies (confusing, also feels arbitrary).
- Subprojects potentially become kind of a nightmare.
- It's not very explicit.
- I think the "Security" case is a weird edge case, and most projects in most use cases shouldn't imply policies. Broadly, most interest in policies from users is very broad ("users in group X can/can not access entire application Y"). The "Security" case is nice-to-have, but I don't think anyone's actually ever asked for it.
So maybe for v1 we just separate policies from projects completely, and putting something in a project never implies a policy. You can set a policy manually, and otherwise we focus on getting coarse-grained policies and policy defaults correct as often as possible.
For v2, if there's enough feedback, we can work on ways to make projects imply policies. Some thoughts are:
- The project control could make it easy to set the policy to "Visible to: one of the projects you typed".
- The project control could auto-update and prompt you to "Set this project to 'security'?" when you add that project.
- When you add "Security", we could give you a modal prompt.
- When you add "Security", we could hard-add it to the policy constraints as an intersect.
All of these would probably be based on flags on the projects, and these flags would probably be quite rare, since they're only necessary for secret-ish projects.
I'd guess that these default-allow policies will actually be rarer than default-deny policies (e.g., "users shouldn't be able to see anything, except users in group Y can see stuff in project Y"). A case here is clients who you might want to give logins to but shut out of everything except stuff related to their projects.
So maybe we eventually end up with a couple classes of projects:
- Normal projects, with no policy implications. These are the vast majority of projects.
- Projects with a soft or hard "intersect" implication, like "Security". Adding these projects //excludes// non-members, essentially setting the policy to "<The Existing Policy> AND is a member of Security".
- Projects with a soft or hard "union" implication, like "Client X". Adding these projects //includes// members, essentially setting the policy to "<The Existing Policy> OR is a member of Client X".
Exactly how hard/soft those implications are is then a UI/UX thing? Does this seem kind of reasonable?