Deployment Configuration

The Deployment Planning aims to provide in-depth details to RSTUF users to aid in the planning of a more customized deployment.

This document describes all aspects of deploying RSTUF independent of the environment and focuses on the technology stacks required by RSTUF services.

This document also complements the published deployment guides for Docker and Kubernetes (yaml manifest) with some detailed information.

For the purpose of authentication and authorization, make sure that API Gateway is deployed and configured, as the Repository Service for TUF API does not provide a built-in functionality, considering it out of scope for the project’s general purpose

Required Infrastructure Services

Repository Service for TUF API and Worker infrastructure services.

Message Queue/Broker: Redis or RabbitMQ server
Result Backend and RSTUF Settings: Redis server
Database: Postgres server
[Optional] Content Server: Webserver

Message Queue/Broker: Redis or RabbitMQ server

RSTUF API and RSTUF Worker will use the message queue/broker.

RSTUF supports Redis or RabbitMQ server.

RSTUF uses Celery. For more details, see the summary about Celery and these two brokers.

Caution

Make sure the Redis or RabbitMQ uses a persistent storage.

RSTUF configuration

RSTUF_BROKER_SERVER RSTUF API
RSTUF_BROKER_SERVER RSTUF Worker

Caution

Both services, RSTUF API and Worker, must to access the same message queue/broker.

Note

RSTUF API and Worker can use an existing Redis or RabbitMQ server in the host infrastructure. A specific Redis database id or specific RabbitMQ vhost is recommended.

Assign the Redis database id a complete address to the RSTUF_BROKER_SERVER configuration on

RSTUF API and Worker.

Example using Redis database id 5: RSTUF_BROKER_SERVER=redis://redis/5
Example using RabbitMQ vhost rstuf_vhost: RSTUF_BROKER_SERVER="amqp://guest:guest@rabbitmq:5672/rstuv_vhost"

Note

RSTUF requires Redis server as a result backend.

Selecting Redis over RabbitMQ as the message queue/broker, reduces one technology stack.

Result Backend and RSTUF Settings: Redis server

https://redis.io

RSTUF API and RSTUF Worker will use this Redis server as a backend result and to store RSTUF Settings.

Every request to RSTUF API is a unique task. The task result is stored in the backend result for 24 hours.

Caution

Be sure the Redis uses a persistent storage.

RSTUF configuration

RSTUF_REDIS_SERVER RSTUF API
RSTUF_REDIS_SERVER RSTUF Worker

Caution

Both services, RSTUF API and Worker, must access the same Redis.

Note

When using Redis as a message queue/broker, the same

service/instance can be used as the result backend and RSTUF repository settings.

It is recommended to keep the broker, result backend, and RSTUF settings in different Redis database ids.

RSTUF provides optional settings in the container for it

RSTUF_REDIS_SERVER_DB_RESULT RSTUF API
RSTUF_REDIS_SERVER_DB_RESULT RSTUF Worker
RSTUF_REDIS_SERVER_DB_REPO_SETTINGS RSTUF API
RSTUF_REDIS_SERVER_DB_REPO_SETTINGS RSTUF Worker

As example, when setting up a deployment that will use Redis as a broker, result backend, and settings, the configuration for RSTUF API and Workers could use respective Redis database ids 5, 6, and 7.

RSTUF_BROKER_SERVER=redis://redis/5
RSTUF_REDIS_SERVER=redis://redis
RSTUF_REDIS_SERVER_DB_RESULT=6
RSTUF_REDIS_SERVER_DB_REPO_SETTINGS=7

Database: Postgres server

https://www.postgresql.org

Only the RSTUF Worker uses the Postgres server

It uses the database to perform the TUF metadata management.

Caution

Make sure that Postgres uses persistent storage.

RSTUF configuration

RSTUF_DB_SERVER RSTUF Worker

[Optional] Content Server: Webserver

The content server is responsible for exposing the TUF metadata managed by the RSTUF Worker(s). This metadata will be used by TUF client implementations such as python-tuf, go-tuf, etc.

It is recommended to use a web server listing for all JSON files stored and managed by RSTUF Worker(s).

Suggestion:

RSTUF

RSTUF Worker configuration

Storage Backend Service

The Storage Backend Service is responsible for storing TUF Metadata.

(Required) RSTUF_STORAGE_BACKEND

Note

This content is the TUF Metadata and must to be exposed to TUF clients.

RSTUF best practices

HTTP Rest API

Do not expose the HTTP REST API if it is not necessary

When integrating RSTUF into a specific content management or distribution platform, restrict the API access to the hosts where this integration is done.

If it becomes necessary to expose public RSTUF API, deploy RSTUF API containers with disabled administrative endpoints.

See:

RSTUF_DISABLED_ENDPOINTS RSTUF API

Authentication/Authorization

Utilize authentication and authorization to restrict access and define scopes for the API. Since the RSTUF API does not include built-in authentication or authorization, we recommend using a trusted service, such as an API Gateway, to manage these functions.

SSL/HTTPS

Use HTTPS on RSTUF API (SSL certificates).

RSTUF API supports SSL Certificates. Enabling and using trusted certificates is recommended.

See:

SECRETS_RSTUF_SSL_CERT RSTUF API

Secrets

Use secrets always for sensitive configurations.

RSTUF API supports using secrets in the container deployment for sensitive environment variables settings. See RSTUF API and RSTUF Worker Environment variables for more details.

Scaling

It is possible to deploy multiple RSTUF API and Worker instances/replicas in a distributed environment to support multiple HTTP Requests and increase workloads for processing the TUF Metadata.