Preconditions for projects on the container platform

Customer project managers and product owners should understand, that the following preconditions are valid at the moment of writing (11.12.2020) for the UoH (University of Helsinki)  IT Center container platform

This page will be updated if necessary. There is also a possibility of some information being missing. If you have any questions, see the contact information on the right.

Some of the preconditions mentioned in this text are permanent, others are valid until further notice and exist since there are early phase limitations to OpenShift.

Temporary preconditions

• The container service offers ABSOLUTELY NO BACKUPS for project files. The container platform, platform administration or the underlying VMWare administration does or has not made automatic backups (or reverting from backups) possible for any parts of your projects.
  
  • This includes Kubernetes-manisfests, container images in the OpenShift internal registry or the PersistentVolumes, which are used by projects.
  • Quay.io is a cloud service, with it's own backup arrangements.
  • We recommend that databases are run outside the container platform (for other reasons as well) and that all Kubernetes manifests are saved in version control so they can be deployed if necessary.
  • The container platform administration knows that the situation is not preferable. Improvements are coming at a later date, but for now each project is responsible for their own backups.
    • A VSphere-volume can be connected to multiple pods at the same time, however all of these pods must be run on the same node (virtual machine). This may be useful in situations such as copying critical data outside the container platform.
    • Let it be known that datacloud.helsinki.fi exists. This option also requires manual configuration on a per project basis.
    • Additionally check out the shared database service.
• Diskspace (PersistentVolume) on the container platform is implemented as VSphere dynamic volumes, and therefore is only RWO.
  • Additional information: 3.8 Levyn käyttö Tiken OpenShiftissä (Copy) ja Tilauslomakkeen "teknisistä tiedoista" (Copy)
  • NFS-disk partitions are not supported due to limitations in access control.
  • Support for Ceph-disks is coming later.
• All communcation from outside the container platform (inc. customer communications from the end users) are limited to ports 80 and 443.
  • Outbound communications for an application on the container platform are not limited.
  • Incoming traffic itself does not need to be http/https, but whatever it is that's connecting to your service from outside to Openshift cluster must be able to use those ports and only those ports.
• At its current state the container platform is not suitable for handling sensitive user data. If your project handles such data, its place is somewhere else than on the shared OpenShift cluster.
  • With time and other resources permitting, we might come back to this question. But building the system to handle sensitive user data is not the priority at the moment.

Constant preconditions

• Applications must be built to withstand pods and the underlying  machines being restarted.
  • OpenShift is reqularly updated to the latest stable version, and part of this update is starting the underlying virtual machines one-by-one. This means that all containers will be restarted on a regular schedule.
  • If it is in the interest of the project that the application survives with as little downtime as possible, it is the responsibility of the project to define the right replication strategies and (anti-)affinities in the project's Kubernetes manifests (check the FAQ) - and to make sure that the application within the containers functions correctly.
• A project running on the container platform is personally in charge of information security in its containers. If there are vulnerabilities in an applications security, and especially if these vulnerabilities compromise the container platform or other projects, the containers may be stopped and/or routes closed. The container platform administration aims to help in regards to using secure Images as best as we can.
  • The project must be committed to software administration for the entire time that the project is being run on the container platform.
  • Quay.io offers security scans for Images. In the near future, the results for these scans (at least for Images under tike organisation) will be visible in the OpenShift web-console. Access to tike-organisation in quay.io can be asked for.
  • In addition, the usage of tools such as Trivy is recommended, especially if the Image is not scanned in quay.io.
  • Universal Base Image offers Red Hat supported packages - and because our container platform is a licensed version of OpenShift, even RHEL-repositories are accessible.
    • More information: UBI - RedHat Universal Base Images
  • The programs and libraries running within the container platform are not updated as the container platform updates. Updating an application requires at least rebuilding the container Image and restarting the containers (make sure that the new Image is being used).
    • The container platform administration is not responsible for breaking a project's application by running the BuildConfig blindly. The project is responsible for building the container Image and testing the final product regardless of when and how the Image is rebuilt.
• All matters relating to data security are the responsibility of each project. A project must understand all responsibilities it has in regards to information security and the project is reponsible for making sure that all such responsibilities (GDPR etc.) are handled with appropriate care.