[Feature] Implement user segmentation with Kubernetes namespaces

[alexellis]

Expected Behaviour

Each user should be onboarded with their own Kubernetes namespace that corresponds to their username. A policy can be applied for quotas and additional network policies can be added for isolation.

System functions will be deployed to the ofc-system namespace.

Current Behaviour

Users are segregated by the use of prefixes for objects and access control lists in the control-plane combined with network policies.

It's harder to apply a limit per user due to the shared openfaas-fn namespace.

Possible Solution

• All functions deployed by buildshiprun will need to take a namespace parameter
• The dashboard will need to query the list-functions function with a namespace parameter
• list-functions will need to become namespace-aware
• Any other functions such as system-metrics and those which take could take a function name, may need to become namespace aware also by accepting a namespace query string parameter
• SealedSecrets will need to be sealed into the namespace allocated to the user instead of openfaas-fn, so there is a small burden of migration
• We may also want to add com.openfaas.cloud.namespace to each function as an annotation
• We'll need to update stack.yml, gitlab.yml and aws.yml to deploy into a ofc-system or simply a system namespace
• The edge-router and edge-auth may need updates - the edge router as it forms URLs for invocations will move from /function/alexellis-fn-name to /function/fn-name.alexellis

Changes to ofc-bootstrap may also be needed.

Changes to the RBAC policy will be needed for the faasnetes controller so that it can perform CRUD in any namespace, right now it's limited to just the installation namespace i.e. openfaas-fn.

[martindekov]

Has anyone started working on this ?

[Waterdrips]

We also need to consider the impact on the in-progress OFC Helm Chart

[martindekov]

Well in order to move things forward in parallel, why don't we just agree on variable name which configures the available namespaces and which functions will possibly need the variable. I suppose the variable should as environmental variable for multiple functions like buildshiprun/git-tar... not really sure which exactly ATM as comma separated list. I suppose the helm chart will contain list of namespaces in the form key=[ns1,ns2,ns3]. I would name the environmental variable ... namespaces 😄 like namespaces=ns1,ns2,ns3 and in the stack.yaml for github-push(example) we can have:

...
  github-push:
...
    environment:
      namespaces: ns1,ns2,ns3
...

[Waterdrips]

the namespaces are going to be based on the users in the CUSTOMERS file are they not?

[martindekov]

You are right Alistair it would be better to make the configuration in a file as opposed to environmental variable. Though I believe we should make the naming of the file custom. CUSTOMERS is semantically good for the public OFC. If I am to deploy the solution, my file would probably be named NAMESPACES. As my "customers" would be most likely prod and stage possibly dev/test

Also if the namespaces configuration is in a file, there will probably be no dependence between this feature and the helm bootstrapping process if I am correct?

[alexellis]

This is on hold until there is enough demand and/or interest in it. It's a non-trivial investment from everyone to make this happen.