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 with some detailed information.

../../../_images/2_2_rstuf.png

Required Infrastructure Services

Repository Service for TUF API and Worker infrastructure services.

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

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

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

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

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

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

[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

Key Vault Backend Service

The Key Vault Backend Service is responsible for storing the Online Key.

Warning

DO NOT EXPOSE THIS CONTENT. It must be restricted to the RSTUF Workers.

Storage Backend Service

The Storage Backend Service is responsible for storing TUF Metadata.

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:

Authentication/Authorization

Use the Authentication/Authorization to restrict scopes

Use an API Gateway to manage API endpoints’ access.

RSTUF API has a built-in authentication service, however this feature is not for production. Using external authentication technology is recommended.

SSL/HTTPS

Use HTTPS on RSTUF API (SSL certificates).

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

See:

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.