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 or by authorization policies.

Using namespace 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")

Using Open Policy Agent policies

With OPA enabled the visibility of namespaces can be controlled via authorization policies.

To understand how the authorization policies work in more detail please see their documentation first.

Global Visibility

Making namespaces globally visible is possible by giving read and write permissions to that namespace to all users (*). An example policy will look like this:

{
  "role_grants": {},
  "user_grants": {
    "*": [
      {
        "action": "read",
        "resource": "namespace/seldon"
      },
      {
        "action": "write",
        "resource": "namespace/seldon"
      }
    ]
  }
}

This policy file is a bare minimum which will allow all users to see the seldon namespace and operate on resources in that namespace.

Group Based Visibility Restrictions

To give access to a namespace on a group level, the role_grants policy list can be used. The group list in the request is obtained from the groups claim in the OIDC authentication token. An example of giving the data-scientist group access to the prod namespace looks like this:

{
  "role_grants": {
    "data-scientist": [
      {
        "action": "read",
        "resource": "namespace/prod"
      },
      {
        "action": "write",
        "resource": "namespace/prod"
      }
    ]
  },
  "user_grants": {}
}

User-Based Visibility Restrictions

To give access to a namespace on a user level, the user_grants policy list can be used.

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")

An example of giving the alice user access to the prod namespace looks like this:

{
  "role_grants": {},
  "user_grants": {
    "alice": [
      {
        "action": "read",
        "resource": "namespace/prod"
      },
      {
        "action": "write",
        "resource": "namespace/prod"
      }
    ]
  }
}