Docker Explained

Docker is a container system that is used to supplement and augment virtualization. Docker automates the deployment of applications inside software containers. Docker containers wrap up a piece of software in a complete file system that contains everything it needs to run: code, runtime, system tools, system libraries – anything you can install on a server. This guarantees that it will always run the same, regardless of the environment it is running in.

• https://docker.io - Explanation of the technology behind Docker containers, Docker hosts etc.
• https://docs.docker.com - Detailed documentation on all aspects of Docker.
• https://hub.docker.com - Platform for companies and open source communities around the world to provide and share Docker images.
• https://hub.docker.com/r/unblu/renderingservice/ - The rendering service Docker image, which must be used for universal co-browsing. (Please note the various tags. Make sure to use the image corresponding to the collaboration server version)

Note: From version 4.2 onwards, the collaboration server requires the Docker rendering service tags to be version-specific to the collaboration server version used. So, if you use unblu 4.2 then 4.2 is the tag version number of the unblu Docker rendering service you must use. unblu 4.3 will use 4.3, and so on.

In on-premises installations, unblu uses Docker for the renderingservice component. This is part of universal and document co-browsing. Note that the Docker Hub renderingservice image is not the complete software. Instead, it is only the unblu-prepared image of Linux. The unblu functionality is held exclusively within the collaboration server.

When you start the rendering service Docker image on the Docker host, the image becomes a container. After starting, the container is contacted by the collaboration server via SSH and the rendering service application is "uploaded". As soon as the application is started, it connects again via http or https (as required) back to the server and is ready for use.

The Docker image "unblu renderingservice" makes it possible to start a "partitioned Linux" which shares the Linux kernel of the host system. For this purpose, a so-called "Docker image" which defines what is part of the "isolated" Linux, is created.

The rendering service was fine-tuned on OpenSUSE and requires predefined packages (fonts, libraries etc.). Since not every customer is able to use OpenSUSE, or because it is complex to prepare the packages "manually" for the different systems, unblu decided instead to create a Docker image, which is based on the official OpenSUSE image and pre-installed packages.

Note: The fact that the image is based on OpenSUSE and exactly what packets are used is not carved in stone. It is possible that unblu could change the content or the Linux distribution base of the rendering service image in future releases, without prior notice.

It is best to imagine the image as an "appliance" or "black box". This does not mean that unblu has secrets regarding the image - on the contrary; since our image is in the Docker Hub, everyone can download and examine it. Unblu adjusts the content of the image as needed. Unblu's Docker images use "tags" that define to which unblu version they belong.

It is possible that the Linux tools used have, for example, bugs or vulnerabilities. Since our renderingservice image is based on the official OpenSUSE image and distribution and regularly created Update Manager packets but also new docker images. unblu, on the other hand, rebuilds its own image on a regular basis, so that the problems fixed by OpenSUSE are also fixed in unblu.

It is highly recommended to retrieve the renderingservice image directly from Docker hub. Pull the image in a regular fashion and update your Docker container with the new images.

However, if this is perceived as too uncertain, it is also possible to order the Docker image directly from us - this is only possible on a request basis.

Content Trust in Docker

Content Trust in Docker is an optional feature. That is, customers who would like to pull the rendering service image with content trust can do so, and customers who do not want to pull the service with content trust do not have to. Correspondingly, renderingservice with tag 4.2 can be pulled with content trust turned on or off. The important part is, that it is possible to pull it with content trust turned on.

In order for content trust to work properly with Docker hub, it is required that https://docker.io as well as https://notary.docker.io are accessible from the location where the docker pull is executed. https://notary.docker.io is where the trust keys are located.

To check that requirement you may want to use the Docker Notary client (see https://docs.docker.com/notary/getting_started/). The following command shows which images are signed on unblu's Docker Hub account:

$ notary -s https://notary.docker.io -d ~/.docker/trust list docker.io/unblu/renderingservice
NAME       DIGEST                                                              SIZE (BYTES)    ROLE
----       ------                                                              ------------    ----
4.2        fd8d037b1c0bfa7599118ccf6516b3d454486b9a26ad1db65ca7b30333cf61d5    742             targets
develop    5226383889cba03d48dfd7fe72957e4f92c432540616b1accaacc997b5f1d8f4    742             targets

It may be necessary to configure http proxies in order to access the servers: https://docs.docker.com/engine/admin/systemd/#httphttps-proxy

Docker Q & A

How does unblu ensure that the image is safe from abuse and/or change?

We have an account at Docker Hub and provide our images in this context. The security of this account is highly dependent on the operation of the Docker Hub, which is not in our hands. (Nevertheless, it should be be noted that many well-known, and large, companies provide their images on Docker.)

How can we be sure that the correct software is always downloaded?

It is not the complete unblu functionality but only a basic Linux image. Basically, Docker ensures that the transfer is correct and the image integrity is correct when it has been loaded. The images can / should not be downloaded "by hand" but with the help of the docking tools, thus guaranteeing security.

In order to provide the images with the highest possible security, you can turn on Docker content trust. All unblu Docker rendering service images have been built with content trust turned on.

How do I access the Docker image?

Using the docker pull unblu/renderingservice command on the Docker host. (Making sure to use the tag version number of Docker that matches the unblu release you are using. Alternatively, the image can also be loaded on a different system then exported and imported again onto the final Docker host. In this case the Docker host would not need access to the Docker Hub.

Do other banks use the Docker solution?

Yes. Docker's usage numbers are going through exponential growth with over 12 billion 'pulls'. Docker (the company) claims that their sales pipeline is 'disproportionately' filled with finance companies.

Is there a Docker white paper?

Yes, the Docker docs are excellent: https://docs.docker.com

Has the Docker hub been checked by an external company?

Docker itself is usually integrated as a "strategic decision" by a company's IT department. In the context of such a decision it may be that such reviews take place - but this has nothing to do with unblu. To this extent, unblu does not know what customers have clarified beforehand.

Is it possible to get the Docker image directly from unblu?

Yes, as mentioned above, but not at regular (automated) intervals: only on request.

Is Unblu's Docker image signed (keyword content trust)?

We have the unblu / renderingservice Docker image actually signed and thus Docker's content trust in operation. Content trust is therefore implemented and available according to the Docker documents.

Does the Docker host system check the certificate of the Docker Hub server (Certificate Pinning)?

The loading of the Docker image from the Docker hub is carried out by means of Docker pull functionality. As far as we can gather, it is currently only checking whether it has been signed by a trustworthy CA - but there seem to be initiatives to explicitly define CAs that are allowed resp. Even to define your own client certificates.

Does Unblu call any Docker commands?

Neither the collaboration server, nor the rendering service execute Docker commands. It is the responsibility of the admin or infrastructure tools to setup and start the rendering service docker container.

In ongoing operations there is a connection between the collaboration server and the docking container (rendering service) via SSH. The Collaboration Server uses this connection to extract the rendering service from itself at the start and to transfer it to the Docker container. Subsequently, the rendering service is started in the container (again via ssh) from the collaboration server. This connects to https back to the collaboration server. The rendering service will then connect to those sites that are to be viewed together for the co-browsing in a running universal co-browsing session.

What is required to update the Docker container?

All Docker-specific actions must be initiated by the administrator (or by appropriate administrator scripts or infrastructure tool such as Puppet etc.). unblu does not use Docker commands. In order to update the Docker container it is necessary to regularly "Docker pull" and to re-start the Docker container. (Remember to use the correct tag version number that matches the version of unblu you are using.)

• deployonprem