Security

General

Development life cycle

At Open Analytics we are continuously improving the development life cycle to prevent that malicious code would sneak into the jar/war files we distribute. We use continuous integration and a deployment process to enable automated security checks in the recipe and guarantee fresh JAR/WAR delivery. Should you discover security issues in the code, please contact us ASAP, ideally via e-mail. One can also file an issue on our Github repository; just ensure not to share sensitive information (IP, names, login, passwords, etc.).

Secure your underlying infrastructure

RDepot is relying on different infrastructure components, depending on the deployment strategy: Docker engine, authentication back-end, operating system, etc. The security of those components should be guaranteed and RDepot features have been added to enable our users to build secure infrastructure. In particular when deploying with Docker on a Docker host, there is a well-known issue should a Docker host API be publicly accessible without appropriate access controls. The host could be remotely compromised or arbitrary Docker instances could run on it.

To protect a Docker daemon the below security controls are mandatory:

• isolate Docker host from public/untrusted network
• never bind the Docker daemon API on 0.0.0.0, only on the loopback interface (127.0.0.1)
• should the Docker API be exposed (in case of a swarm or cloud deployment), ensure to use TLS mutual authentication for enabling communication with the Docker API. It’s a more heavy setup as it would require a proper PKI or certificate management/creation solution but exposing the Docker API should be avoided at all costs.

HTTPS (SSL / TLS)

From an architectural point of view it is recommended to support the off-loading of SSL certificates to a separate reverse proxy. Nginx works perfectly fine with RDepot and below an example configuration is given, using our demo Docker Compose deployment:

server {
  listen                80;
  server_name           rdepot.yourdomain.com;
  rewrite     ^(.*)     https://$server_name$1 permanent;
}

server {
  listen                443;
  server_name           rdepot.yourdomain.com;
  access_log            /var/log/nginx/rdepot.access.log;
  error_log             /var/log/nginx/rdepot.error.log error;

  ssl on;
  ssl_protocols         TLSv1.2 TLSv1.3;
  ssl_ciphers           HIGH:!aNULL:!MD5;

  ssl_certificate       /etc/ssl/certs/yourdomain.com.crt;
  ssl_certificate_key   /etc/ssl/private/yourdomain.com.key;

  location / {
    access_log          /var/log/nginx/rdepot-frontend.access.log;
    error_log           /var/log/nginx/rdepot-frontend.error.log;
    proxy_pass        http://oa-rdepot-frontend:8080;
    proxy_redirect    off;
    proxy_set_header  Host             $http_host;
    proxy_set_header  X-Real-IP        $remote_addr;
    proxy_set_header  X-Forwarded-For  $proxy_add_x_forwarded_for;
    proxy_set_header  X-Forwarded-Protocol $scheme;
  }

  location /backend/ {
    access_log          /var/log/nginx/rdepot-backend.access.log;
    error_log           /var/log/nginx/rdepot-backend.error.log;
    proxy_pass        http://oa-rdepot-backend:8080;
    proxy_redirect    off;
    proxy_set_header  Host             $http_host;
    proxy_set_header  X-Real-IP        $remote_addr;
    proxy_set_header  X-Forwarded-For  $proxy_add_x_forwarded_for;
    proxy_set_header  X-Forwarded-Protocol $scheme;
  }

}

The configuration:

• redirects HTTP traffic (port 80) to HTTPS (port 443)
• proxies traffic intended for the RDepot UI to the frontend Docker container at port 8080
• proxies traffic intended for the RDepot API to the backend Docker container on port 8080

Make sure the allowed-origin, server.port and server.servlet.context-path in the RDepot application.yaml configuration file match your deployment:

# ...
allowed-origin: https://rdepot.yourdomain.com  # only allow requests from https://rdepot.yourdomain.com
server:
  # ...
  port: 8080  # use port 8080
  servlet:
    context-path: /backend  # expect requests from https://rdepot.yourdomain.com/backend

Forward Headers

When only HTTPS is available (i.e. no redirects from HTTP configured in nginx), it is required to configure the RDepot API to use “forward headers”.

server:
  forward-headers-strategy: native

Secure communication between manager and repository

In a production environment, we strongly suggest setting up secure communications between the manager and repository applications. This can be done by using a server certificate for the repository application and configuring the manager application to trust the repository server certificate.

Please see the section on secure communication on the configuration page.

For a full example using a generated CA-signed certificate (using your own CA) and our Docker Compose deployment, please refer to the secure communications guide to learn more.

Mutual authentication between manager and repository

In addition to using secure communications, setting up mutual authentication using mTLS is also supported. This can be done by using a certificate for the repository application and configuring the manager application to trust the repository certificate and vice versa.

Please see the section on mTLS on the configuration page.

For a full example using a generated CA-signed certificate (using your own CA) and our Docker Compose deployment, please refer to the mTLS guide to learn more.

Firewalling

If no reverse proxy is put in front of the RDepot API, the port that needs to be accessible to the outside world is the proxy port specified in the application.yaml file (server.port field) which, by default, will be port 8080. In principle, all other ports can be filtered in the firewall.

Sensitive Configuration

Configuration parameters that contain sensitive information and cannot be stored in the application.yaml file can be provided differently. Note that best practice is to sufficiently protect application.yaml with access rights, but in some cases (e.g. where the configuration is partly maintained via source control) it is useful to externalize sensitive configuration.

• Using a Java System property:

unset HISTFILE
java -jar rdepot-app-2.7.0.war -Ddb.password=abc

Use period as a separator to descend the parameter hierarchy in the application.yaml file.

• Using environment variables:

unset HISTFILE
export DB_PASSWORD=abc
java -jar rdepot-app-2.7.0.war

Since most operating systems disallow period-separated names, the naming syntax differs slightly. To set the environment variable corresponding to a Java system property, use uppercase and replace all periods with underscores.

• A complete list of external configuration options can be found here.

Secure Dependencies

RDepot makes uses of software libraries such as the Spring Boot framework. It is important that these libraries are updated when they contain a security vulnerability. In order to know which libraries contain vulnerabilities we use the OWASP Dependency Check plugin for Maven.

Checking for vulnerable dependencies:

git clone https://github.com/openanalytics/RDepot
cd RDepot
mvn install -DskipTests

The last command first downloads the NVD CVE database (this may take some time). Next, it generates a HTML report rdepot-app/target/dependency-check-report.html that lists all known CVEs in the dependencies.