Skip to content
This repository has been archived by the owner on Dec 5, 2023. It is now read-only.

Deploy and Configure the PEP

Jump to bottom
Alvaro Villanueva edited this page Nov 5, 2021 · 20 revisions

In order to initialize a local PEP instance, it will be necessary to:

  • Pre-configure the PEP
  • Build the PEP Docker Image
  • Run the PEP Docker Image

Configuration

General Configuration

The PEP gets all its configuration from the file located under config/config.json. The parameters that are accepted, and their meaning, are as follows:

  • realm: 'realm' parameter answered for each UMA ticket. Default is "eoepca"
  • auth_server_url: complete url (with "https") of the Authorization server.
  • service_host: Host for the proxy to listen on. For example, "0.0.0.0" will listen on all interfaces
  • proxy_service_port: Port for the proxy endpoint to listen on. By default, 5566. Keep in mind you will have to edit the docker file and/or kubernetes yaml file in order for all the prot forwarding to work.
  • resources_service_port: Port for the resources endpoint to listen on. By default, 5576. Keep in mind you will have to edit the docker file and/or kubernetes yaml file in order for all the prot forwarding to work.
  • s_margin_rpt_valid: An integer representing how many seconds of "margin" do we want when checking RPT. For example, using 5 will make sure the provided RPT is valid now AND AT LEAST in the next 5 seconds.
  • check_ssl_certs: Toggle on/off (bool) to check certificates in all requests. This should be forced to True in a production environment
  • use_threads: Toggle on/off (bool) the usage of threads for the proxy. Recommended to be left as True.
  • debug_mode: Toggle on/off (bool) a debug mode of Flask. In a production environment, this should be false.
  • resource_server_endpoint: Complete url (with "https" and any port) of the Resource Server to protect with this PEP.
  • rpt_limit_uses: Number of uses for each of the RPTs.
  • working_mode: Either "FULL" or "PARTIAL". Introduced with v1.0 of the PEP, the "FULL" function has the PEP behave as before, but the "PARTIAL" option has it working solely as an Authorization API for an external nginx instance.
  • client_id: string indicating a client_id for an already registered and configured client. This parameter is optional. When not supplied, the PEP will generate a new client for itself and store it in this key inside the JSON.
  • client_secret: string indicating the client secret for the client_id. This parameter is optional. When not supplied, the PEP will generate a new client for itself and store it in this key inside the JSON.

Default scopes for HTTP verbs

The PEP also has a configuration file available at config/verb_config.json that contains the scopes that should be registered by default, with every resource, for later usage in policy verification by the PDP. These are set for the HTTP verbs of GET, HEAD, POST, PUT, PATCH and DELETE, with the current default setting being in the format protected_. The file follows the format:

  • default_scopes: A list of default scopes that will be registered for HTTP actions, for PDP functionality. These must match the scopes existing on the Login Service’s persistence repository.
  • list of scope-action associations: for each of the scopes specified in the above list, there will be one entry with an associanted action-id

Default resources registration

The PEP reads the definition of the default resources inserted in the database from the file located under config/default-resources.json of the source path, but also has its own definition under the path charts/pep-engine/scripts/default-resources.json.

The first option usage is mainly for a local deployment using Docker and a local image built from the um-pep-engine repository with no help of Helm Charts. The second option is for a Helm Chart deployment which will mount the file as a volume directly into the /data path of the container. Notice that if this second option of deployment is followed, the unique resources for both files will be added to the database.

An example of default resources would be as follows:

{
  "default_resources": [
    {"name": "Sample Resource", resource_uri": "/", "scopes": "[protected_access]", "default_owner": <uuid>},
    {"name": "Sample Resource", resource_uri": "/workspace", "scopes": "[protected_access]", "default_owner": <uuid>}
  ]
}
  • Mandatory Parameters:

name: String Value

resource_uri: String Value

scopes: String Value

  • Optional Parameters (default values):

default_owner: String Value -> "0000000000000"

description: String Value -> "Default description"

Usage & functionality

For simplicity, docker is the best approach to run. Using Docker-Compose it is possible to both build and run the PEP and its default persistence method (MongoDB) pointing towards the configured endpoints:

docker-compose up

The main flow for the compose will be first building the image (make sure you are in the folder where Dockerfile is):

docker build -t um-pep-engine .

Then simply run:

docker run -p 5567:5567 -d um-pep-engine

If by any reason you are unable to bind port 5567, you can use a different one:

docker run -p <desired-port>:5576 -d um-pep-engine

As the pep engine runs aside with a MongoDB service as sidecar in a kubernetes context, a service of the database has to be up before the pep launches. For that you can run the following command:

sudo docker run -p 27017:27017 -d mongo

If this is running in a development environment without proper DNS setup, add the following to your docker run command:

--add-host <auth-server-dns>:<your-ip>

When launched, the PEP will answer to all requests that start with the configured path. These answers will come in the form of UMA tickets (if there are no RPT provided, or an invalid one is used). In case the request is accompanied by an "Authorization: Bearer <valid_RPT>", the PEP will make a request to the resource server, for the resource located exactly at the path requested (minus the configured at config), and return the resource's server answer.

Deployment using Helm Charts

Pre-requisites

Installed Helm v2 (Official installation guide)

Installed Minikube (Can be achieved by following the instructions in the main EOEPCA Repository)

Configuration

The global values used in the definition of the charts can be modified in the values.yaml of the chart definition.

Installation

In order to deploy this repository with Helm Charts is needed to navigate to the /charts path within the repo. Run the following command specifying the name of the release:

helm install myRelease ./pep-engine/

⏭️ Next step: Chart Configuration

Clone this wiki locally