sf-client network list has no --namespace option

[mandoonandy]

Should allow listing by namespace.

$ sf-client network list --help
Usage: sf-client network list [OPTIONS]

  List networks

Options:
  -a, --all  Include networks in error and deleted networks
  --help     Show this message and exit.

[mikalstill]

In fact, most calls lack a namespace argument. I think this is more complicated than I want it to be though -- at the moment we only support specifying a namespace if you're in the system namespace. Is that really worth adding something to every call? Or do we need a more complicated namespace permissions model?

[mandoonandy]

This is a good question.

Should namespaces just be a separation tool or should they be a proper tenant separation?
Do we want a full RBAC model or should each SF cluster be used by cooperating trusted users.

At the moment (today), I like the idea of separate namespaces for separating jobs because I can use a single clean command to delete all the instances and networks in that namespace.

So maybe a tenant permissions model goes over the top of namespaces? (k8s style)

[mikalstill]

Yeah, I like the simplicity of what we have now. What I really want to do is something like:

• you create a system client (if you're in the system namespace)
• system clients can create sub-clients which are in another namespace
• remove all the namespace arguments on individual calls

Something like:

system_client = apiclient.Client()
foo_client = system_client.subclient('foo')

When the subclient makes a call, how does the API server know that its authorized? Maybe _actual_request_url() could insert a header or something?

[mikalstill]

What about an X-ShakenFist-Namespace header which only works if you're authed in the system namespace?

[mandoonandy]

I'm not sure about the actual efficiency of sending the namespace in the header vs as a parameter. Each call still needs to check the namespace for the particular parameter. I think you are also suggesting further change?

In the case where we have multiple CI jobs running plus a couple of people working in the same cluster - a perfect example of the SF use case - it would be great to just list the instances/networks in a particular namespace. As a user, I want to quickly create a namespace, test an idea for a few days then clean away everything in the namespace. I don't want to inadvertently interfere with other work or CI jobs but still have a quick clean up option.

[mikalstill]

So I think that use case is a good thought experiment. Here's my concern...

I have a CI cluster at home. I use it for other things as well, so CI currently runs in a namespace called "ci". I like the idea of putting jobs into their own namespaces, but that menas that either: jenkins needs to run as the system namespace (yuck); or I need some way to "bless" the CI namespace as being allowed to act as other namespaces.

Thoughts?

[mandoonandy]

Continuing the thought experiment - standard "just throwing out ideas" disclaimer:

Sub-namespaces. (Stick with me.)

Just a simple implementation. Allow a forward slash to indicate a sub-namespace.

• Namespaces can be created as a sub-namespace by using a slash
  ** ci/ci_andy
  ** ci/ci_mikal
  ** home/automation/test1
  ** bob
• For creation to succeed, the parent namespace must exist.
• The new sub-namespace can have a different key or just inherit the key above (completed at create time, no search shenanigans)
• Users with access to a namespace can create a namespace beneath it
• A Namespace can be accessed by a user if they have a key for that namespace or any namespace above it

[mikalstill]

I actually quite like that idea. So you'd populate the auth details for the subnamespace on creation, not just do some sort of lookup at auth time? The lookup at auth time would involve a bunch of etcd reads, so is probably expensive I suppose.

[mandoonandy]

The auth lookup could involve more than one DB lookup but it's limited to the depth of the namespace tree. It can be optimised by loading the whole namespace tree rather than executing individual DB reads.

The comment relating to key inheritance is probably an implementation detail I should not have touched. I was trying to say that a user can create a sub-namespace without specifying a key. In that case the system defaults to the key for the namespace immediately above.

[mikalstill]

I actually think that inheritance in namespaces is quite interesting. For example, I always forget to add a SSH key to my instances, could that be something which is inherited from the namespace? What about other attributes (uefi boot, default network, etc etc).

[mandoonandy]

A default ssh key and even user-data would definitely be excellent.

This does complicate issues though. Do we inherit from namespaces above? Do we have a flag to not inherit? Hierarchical inheritance would be very convenient to set one ssh key and have it always used, but could lead to unexpected outcomes. Maybe inheritance in a namespace off by default. (The inheritance flag could be inherited!?)

Inheritance from a namespace is probably a separate problem to sub-namepsaces. The third issue of "Hierarchical inheritance of attributes" could be a feature of sub-namespaces but I think is separate from hierarchical auth.