Deployment Requirements

Kubernetes Version Compatibility

Depending on your KOTS version, the Kubernetes Compatibility can be seen here.

Hardware Requirements

The actual cluster hard-ware requirements heavily depend on the amount of repositories, the number of commits, and the programming languages that are being scanned. We recommend to start with a given number of nodes and then keep reviewing/tuning it over the first couple of days/weeks of the initial rollout.

Please work with your technical support contact to get your recommendations.

For any cluster nodes, the following is recommended:

• 8 CPU Cores (at least 2.3 GHz each)
• 64 GB RAM
• 100 GB Storage

Operating System

Here are the latest supported Operating Systems as of May 30th, 2023. The latest version can be seen here

• Ubuntu 18.04
• Ubuntu 20.04 (Docker version >= 19.03.10)
• Ubuntu 22.04 (Requires Containerd version >= 1.5.10 or Docker version >= 20.10.17. Collectd add-ons are not supported.)
• CentOS 7.4*, 7.5*, 7.6*, 7.7*, 7.8*, 7.9, 8.0*, 8.1*, 8.2*, 8.3*, 8.4* (CentOS 8.x requires Containerd)
• RHEL 7.4*, 7.5*, 7.6*, 7.7*, 7.8*, 7.9, 8.0*, 8.1, 8.2, 8.3, 8.4, 8.5, 8.6, 8.7, 9.0, 9.1, 9.2 (RHEL 8.x and 9.x require Containerd)
• Rocky Linux 9.0, 9.1, 9.2 (Rocky Linux 9.x requires Containerd)
• Oracle Linux 7.4*, 7.5*, 7.6*, 7.7*, 7.8*, 7.9, 8.0*, 8.1, 8.2, 8.3, 8.4, 8.5, 8.6, 8.7, 8.8 (OL 8.x requires Containerd)
• Amazon Linux 2

Database

For a self hosted PostgreSQL instance, the following specs are recommended:

• 4 CPU Cores (2.3 GHz each)
• 16 GB RAM
• PostgreSQL version 10+

Proxies

The GuardRails install script provides several configuration options for working with an HTTP proxy. Passing the no-proxy flag to the install script will disable all proxy discovery and configuration.

More information about installations using proxies can be found here.

Network

General

• SSL Certificate for HTTPS (OpenSSL/Apache compatible format)

DNS Record

You will need to configure only one DNS record (i.e.: guardrails.your-company.com) for the entire deployment.

Firewall Requirements

The GuardRails on-premise application is packaged using Replicated. For IP based firewalls the latest list of the Replicated IP address range, can be found here and here.

Also, review the requirements for the online installation here.

GuardRails Port Requirements

Depending on the deployment mode, e.g. Kubernetes Nodeports, the different services will be exposed under different ports. Here's the list of services and ports that typically have to be accessible by all users, with the recommended port numbers:

• GuardRails Enterprise Admin Interface: 8800 or any other port that is configured: Only need to be accessed by administrators, and the port can be closed unless needed to administer the platform.
• Dashboard: 80, 443: All GuardRails users have to be able to access it.
• API: 1444: All GuardRails users have to be able to access it.
• Probot: 1445: Has to be accessible by the version control system (e.g. GitHub, Bitbucket).
• SCA Oracle: 1446: Has to be accessible from the cluster.
• Minio: 1448: All GuardRails users have to be able to access it.

On further steps you will see the use of guardrails.your-company.com or <YOUR_HOST> as the host for all url configurations. As well you will need to use the API URL (i.e.: https://guardrails.your-company.com:1444) and Probot URL (i.e.: https://guardrails.your-company.com:1445) in order to configure your version control provider application.

For outgoing communication the following is required:

Host	Required	Description
All	Yes	Outbound HTTPS traffic for fetching signature updates for some of our security engines and Slack webhook notifications.
Docker Hub	Yes	Security Engines are hosted on Docker Hub and are continuously updated.

Versioning Control Systems

Bitbucket Server and Bitbucket Data Center

We recommend that you use a version greater than 7.4 of Bitbucket server (or Bitbucket data center) to experience the full functionality of Guardrails. If you use an older version you will experience these limitations:

• Version lower than 7.4:
  • No scan status will be displayed in the Bitbucket UI as build statuses was introduced in version 7.4
• Version lower than 7.0:
  • Pushing additional commits to an existing pull request won't trigger a new scan. The event for detecting new commits was introduced in Bitbucket version 7.0.
• Version lower than 6.7:
  • Fetching a raw diff of changes made in a pull request aren't available in Bitbucket versions lower than 6.7. This means that pull requests will affectively not be scanned and always report 0 vulnerabilities.

Note: Versions of Bitbucket server and Bitbucket data center lower than version 5.5 are not supported as these versions of Bitbucket server and Bitbucket data center don't have support for personal access tokens which is required for Guardrails to integrate with Bitbucket.