Namespace Visibility

Deployment filtering by namespace

Visibility Restriction per Namespace

Namespaces that the user is eligible to see appear in a drop-down namespace selector in the top-right:

namespaceselector

From there the user can search for or choose to drill into deployments:

DeploymentsFilter

Visibility and permissions on namespaces are driven by labels.

Global Visibility

By default Seldon Deploy does not show any namespaces that are not explicitly labelled.

You can make a namespace globally available to all users by providing the following label to the namespace:

seldon.restricted: "true"

This indicates that the namespace is restricted. If the label were seldon.restricted: "false" then the namespace would be open to everyone. Namespaces without a seldon.restricted label would be ignored.

This can be set with kubectl label namespace $namespace seldon.restricted=false --overwrite=true, $namespace is the namespace to label.

Group Based Visibility Restrictions

For fine-grained restrictions on a group level for namespace access, you can add namespaces with the label in the format:

seldon.group.{YOUR_GROUP_NAME}: "write"

Some examples of these, which would be linked to your LDAP integration include:

seldon.group.admins: "write"
seldon.group.developers: "read"

This would indicate that members of the admins group could make changes in the namespace and developers can read. Groups could, for example, come from LDAP. See Authentication under Architecture.

User-Based Visibility Restrictions

For fine-grained restrictions on a user level for namespace access, you can add namespaces with the label:

seldon.user.{USERNAME}: "[write/read]"

Some examples of these, which would be linked to your LDAP integration include:

seldon.user.myusername: "write"
seldon.user.anotherusername: "read"

The claim to be used for user-based visibility restriction can be changed by updating the seldon deploy helm chart environment variable USERID_CLAIM_KEY. This value defaults to preferred_username but can be configured to other user info claim values.

env:
  USERID_CLAIM_KEY:"name" # claim to be used as userid (defaults to "preferred_username")