We use analytics and cookies to understand site traffic. Information about your use of our site is shared with Google for that purpose.You can read our privacy policies and terms of use etc by clicking here.
Namespace Visibility
Visibility Restriction per Namespace
Namespaces that the user is eligible to see appear in a drop-down namespace selector in the top-right:
From there the user can search for or choose to drill into deployments:
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")