Assumptions and Warnings#

Warnings#

The following are warnings that apply to the cluster and/or all guides.

  1. Do Not Expose These Systems or Services To The Internet

These guides assume that the cluster will be on an isolated subnet within a larger organization and will utilize additional security monitoring tools that are beyond the scope of these guides. These guides do not provide hardening techniques for exposing them to the internet.

  1. Use Trusted Certificates

These guides utilize self signed certificates for TLS encryption. Self signed certificates are suspectable to Man In The Middle (MITM) attacks and should not be considered secure. It is recommended that certificates be issued by an internal or reputable Certificate Authority (CA). Keep in mind that most Certificate Authorities publish recently issued certificates to Certificate Transparency (CT) logs and you should not use sensitive server names.

Search the Certificate Transparency logs: https://ui.ctsearch.entrust.com/ui/ctsearchui

  1. Implement a Backup Strategy

These guides do not cover backing up the cluster. Backups and restoration strageties is a required element to a cluster. RAID is not a backup.

  1. Implement a Redundancy/Resilancy Strategy

These guides only provide techniquies for improving fault tolerance such as providing RAID on systems. Redundancy strageties is a required element to a cluster.

Assumptions#

The guides make a couple fundamental assumptions which have guided how things are implemented. Anyone implementing these systems will need to evaluate their specific requirements and tailor them for their specific usage scenarios.

1. The hosted applications are run on separate virtual machines and do not utilize Docker. While Docker is one of the provided applications, its usage is intended for internally developed and deployed images only. This limitation is in place to eliminate the need for third-party image hosting.

2. Yum/DNF repositories are utilized, if available. To reduce friction in performing updates yum repositories provided by the application authors have been utilized. Only in cases where repositories are not available (e.g. Slurm) are they not used. While updates require coordination with users, utilizing the vendor repositories and yum/dnf commands to execute updates reduces the amount of work required. Source code and RPMs for applications should be accessed directly from the developer.

3. The cluster does not require a specific uptime Service Level Agreement (SLA). These guides are intended to be used in an environment that can tolerate modest down times and system unavailability. While down time should be cordinated with users, unexpected down time should not result in downtime of critical corporate resources.