Description of image

Public and Protected Endpoints in Gradient Deployments

Paperspace Deployments are containers-as-a-service that allow you to run container images and serve machine learning models using a high-performance, low-latency service with a RESTful API.

Gradient deployments currently have two levels of endpoint security:

  • Public: Public endpoints are the default status for Gradient deployments if left unspecified. Public endpoints allow any user with access to the deployment endpoint to access the service. This can be used for internal testing, allowing others access to your service, or prototyping.

  • Protected: Protected endpoints restrict access to the deployment using a basic access authentication encoded token. To access these endpoints, users need to pass in the encoded token in the authorization header with the API request. If no authorization header, or an incorrect token is passed, the user receives a 401 Unauthorized response.

Endpoint security configuration

If creating a deployment through the console, users can configure endpoint security under Advanced Options. Users can either generate a new secret or use the value of an existing secret as the security token.

Once the deployment is set up with this configuration, the authentication token does not change unless there is a re-deploy, even if the underlying value for the Paperspace secret used to create the token is changed.

Authorization header usage

Once a protected endpoint is set up, you need two values to generate the authorization header: username and password.

The username for all Gradient deployments is paperspace. The password is the value of the secret specified during the deployment creation process.

To generate the authorization header value, you then need to encode username:password using basic access authentication. See an example site to do the encoding.

As an example, if the password is my_password, encode paperspace:my_password using basic access authentication, which returns Basic cGFwZXJzcGFjZTpteV9wYXNzd29yZA==.

You can then pass that value in as through an authorization header like:

curl -H "Authorization: Basic cGFwZXJzcGFjZTpteV9wYXNzd29yZA=="

The authentication token only changes on a redeploy of the deployment.

If a secret value was used to create the authorization, and then later changed while the deployment stays active, the security token does not change to that new value.

However, when the user redeploys, the authentication token updates to the current value of the Paperspace secret.