Security guide

Rahti applications are exposed to the Internet, and their security should be treated with an appropriate care. The user on whose account a service is running in Rahti is responsible for its security. See the terms of use for details about the responsibilities.

This guide should be treated as the baseline which must be taken in account rather than a checklist for perfect security.

Measures that tighten the security of the services running in Rahti can be roughly divided in two categories.

Securing routes

Enable the TLS encryption of routes. If the DNS name of your service is under the subdomain (e.g., the default wildcard TLS certificate provided by Rahti can be used directly. Otherwise, you need to add your certificate data in the route object.

Access to the services should be limited to selected networks with whitelists whenever applicable (See the chapter Routes). This is relevant whenever access can be restricted in terms of IP addresses.

Secure routes thwart eavesdropping attacks that target e.g. service passwords and usernames, and other critical data sent over the internet.

Image security

Outdated container images are prone to exploits via security vulnerabilities, and unfamiliar images may contain malicious code. For these reasons, a given container image should be used only if:

  1. It is from a known and trusted source so that the known security vulnerabilities are patched and you can trust it not to contain malicious code.
  2. You have reviewed its Dockerfile build configuration and the base layer satisfies Rule #1 or #2.

Other things to keep in mind: