Authorization Policies Management

Managing authorization policies when using Open Policy Agent authorization.

Open Policy Agent (OPA) policies is one of the ways of managing authorization in Deploy. To enable it follow the production installation guide or enable it via the trial install setup.

Policy schema

The OPA policies are a list of resource-action pairs, defined in a JSON files that must be present to Seldon Deploy on startup. The Helm chart is able to load the file from a config map specified in the installation guide, but any other way of providing the file will also work.

Targets

Seldon Deploy can authorize users based on their groups and their ID. This information is obtained from the OIDC token fetched during the authentication step.

The claim to be used for user-based authorization 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")

The base schema of the policy file consists of two fields - role_grants and user_grants mapping the groups and user IDs respectively:

{
  "role_grants": {
//    policies based on the user's groups...
  },
  "user_grants": {
//    policies based on the user's ID...
  }
}

A special target is the user * which can be used to give global policies. To see how this can be used check the examples section.

Resources

Seldon Deploy serves various resources like ML models and the deployments of these models. Right now these resources are grouped in two categories:

  • Namespace based resources - deployments.

  • Project based resources - models.

The actions one can perform on these resources are write and read, where write corresponds to all actions that modify a resource like crating it, updating it, and deleting it. read corresponds to actions that only inspect the resource but do not modify it.

A policy resource-action pair looks like this:

{
  "action": "read",
  "resource": "namespace/seldon"
}

For more details on the specifics of each resource type policies please see the namespace visibility and project visibility guides.

Examples

A full example of a policy file looks like this:

{
  "role_grants": {
    "data_scientist": [
      {
        "action": "read",
        "resource": "project/iris"
      },
      {
        "action": "write",
        "resource": "project/iris"
      },
      {
        "action": "read",
        "resource": "namespace/seldon"
      }
    ],
    "ops": [
      {
        "action": "read",
        "resource": "project/iris"
      },
      {
        "action": "read",
        "resource": "namespace/seldon"
      },
      {
        "action": "write",
        "resource": "namespace/seldon"
      }
    ]
  },
  "user_grants": {
    "*": [
      {
        "action": "read",
        "resource": "project/default"
      },
      {
        "action": "write",
        "resource": "project/default"
      },
      {
        "action": "read",
        "resource": "namespace/default"
      },
      {
        "action": "write",
        "resource": "namespace/default"
      }
    ],
    "alice": [
      {
        "action": "read",
        "resource": "namespace/alice"
      },
      {
        "action": "write",
        "resource": "namespace/alice"
      }
    ]
  }
}

In this example, users part of the data_scientist group will be able to create, modify, and read models from the iris project, as well as see deployments in the seldon namespace. However, they do not have permissions to deploy or modify deployments in that namespace. Similarly, users part of the ops group do not have permissions to modify models in the iris project, but can see these models as well as deploy to the seldon namespace.

The * user grant specifies that all users have read and write permissions on the default project and namespace. Another example of the user grant is the permissions given to the user alice - no matter their groups, they will have read and write access to the alice namespace.

Policy evaluation

The final list of policies that a user has is a combination of:

  • the policies that they explicitly have from the user_grants policy list.

  • the policies given to all users - the policies in the user_grants list for the * user.

  • all the policies in the role_grants list associated with groups that the user belongs to.

Right now, negative authorization (denials) is not supported.

Policy operations

The policy file can be modified and stored in various ways. The simplest way to start using OPA policies in Seldon Deploy is by mounting it from a config map as described in the production installation guide.

To interact with the policy config map there is a utility command line tool that can be downloaded from the seldon-deploy-resources repo. Once downloaded the correct binary for your architecture you can start using the policy_client tool. For full documentation of the tool you can run policy_client --help.

Seldon Deploy listens for changes to the policy file and will automatically reload the policies if they change.

Migrating from Namespace labels

To migrate from using namespace labels for defining access requirements to a namespace you can use the following command:

policy_client sync

It will create a config map called seldon-deploy-policies in the seldon-system namespace if one is not present. The name and namespace are configurable by flags. It will then populate policies corresponding to the namespace labels in the cluster. The command will not delete any existing policies in the config map.

To confirm the change has been successful you can check the config map by running:

kubectl get cm -nseldon-system seldon-deploy-policies -o jsonpath='{.data.data}' | jq

Adding a new policy

To add a new policy you can run:

policy_client addPolicy --resource=namespace/seldon --action=write --target_users=alice --target_groups=admin

The arguments target_groups and target_users can take multiple entries.

Deleting an existing policy

Similarly to adding, to remove an existing policy you can run:

policy_client removePolicy --resource=namespace/seldon --action=write --target_users=alice --target_groups=admin

Limitation

Using a config map for the policy file is flexible and easy to setup. However, it comes with a limitation which is true for all Kubernetes resources - it is limited to 1MB size since the underlying etcd value limit. If your use case requires a bigger size for the policy file consider mounting the file from somewhere else like an object store (S3, minio), or a database. We are working on adding native support for such use cases which should be generally available in future releases.