Why Docker Image?
Simplifier will only be distributed as complete docker image over dockerhub
This distribution package has the following advantages:
- All Components that need for Simplifier like JVM are pre configured and tested
- Updates and Upgrades of Simplifier Version can be done easily
- Data and Application are separated from the beginning
- Docker Images are more secure than direct installation of applications due Container Sandboxes
- Docker Images runs under different environments like various container engines, kubernetes or several cloud container engines like Azure AKS or AWS ECS.
Docker Repository
Simplifier will only be distributed as complete docker image over dockerhub
simplifierag/runtime:<major-version>.<minor-version>
Example
simplifierag/runtime:6.5
This tag includes always the latest hotfixes
Configuring Docker Images via Environment Parameters
Simplifier Docker Images can be configured via Environment Parameters to ensure maximal flexibility
Docker Environment Parameter | Default Value | Example Value | Description |
DB
|
mysql | If value is “mysql”, databases for:
will be automatically created if non-existent |
|
SIMPLIFIER_VERSION_TEMPLATE
|
Technical Simplifier version | ||
JVM_PARAMETER |
-Xmx8g
-Xms2g -XX:MaxMetaspaceSize=512m -XX:+UseG1GC -XX:+UseStringDeduplication -XX:-UseGCOverheadLimit -Xss256m |
JVM Settings for Simplifier service | |
MYSQL_HOST |
mysql | Hostname or IP Address of MySQL Server | |
MYSQL_PORT |
3306 | 3306 | Standard Port of MySQL Server |
MYSQL_USER |
simplifier | Username of Connection Credentials | |
MYSQL_PASSWORD |
MyC0mPle!Pa$$word | Password of Connection Credentials | |
MYSQL_DB |
simplifier | Name of MySQL Database | |
MYSQL_DB_SESSION | Mysql database name for session plugin | ||
MYSQL_DB_STEPBYSTEP | Mysql database name for step by step plugin | ||
PLUGINLIST |
|
jsonStore | Standard Comma Separated Lists of Plugins |
VIRTUAL_HOST |
mysimplifier.mycompany.de | DNS Name of Simplifier | |
CLUSTER_MEMBER_NAME |
BOX_1 | If set, cluster member name of simplifier server, else ignored | |
SSH_ACCESS |
no or yes | If yes a SSH Daemon will be started within the container – this is useful for serverless environments like AWS Fargate | |
SSH_PUBLIC_KEY |
ssh-rsa AAAAB…. GTLxyuPuQ== myadmin@mycompany.com | SSH Public Key for Access Terminal via SSH |
The following plugins are contained in the simplifier docker image
Plugin Name | Description | Documentation |
keyValueStorePlugin |
No-SQL Database for storing Key Values | KeyValueStore |
pdfPlugin |
PDF Designer and Generator for Forms or Reports | PDFPlugin |
powerSupplyPlugin |
deprecated | |
wordGeneratorPlugin |
Word Generator | |
kundenMarktplatzPlugin |
Database for Netzportal 4.0 Template | |
postCdPlugin |
Support or Adress Validation against Deutsche Post Database | |
captcha |
Generates Captchas for Login Protection | captcha |
contentRepoPlugin |
Meta Repository for Files | contentRepo |
jsonStore |
NoSQL Database based on MapDB | jsonStore |
When transferring data among networked systems, trust is a central concern. In particular, when communicating over an untrusted medium such as the internet, it is critical to ensure the integrity and the publisher of all the data a system operates on. You use the Docker Engine to push and pull images (data) to a public or private registry. Content trust gives you the ability to verify both the integrity and the publisher of all the data received from a registry over any channel.
Docker Content Trust is a feature in the Docker containerization platform that enables remote registry content to be digitally signed, ensuring that the content is unaltered and is the most current available version when users access it. It works via cryptographic keys. Docker Content Trust was introduced in Docker Engine with version 1.8.
Docker Content Trust adds security controls that verify the integrity of container images — the container files that hold application components and content — stored in a registry, such as Docker Hub. Enterprise developers and other users can push or pull (upload or download) container images to a registry. Docker Content Trust addresses two concerns with registries. Users might upload a container image infiltrated with malware, and the users accessing it from that remote repository cannot determine its integrity. And secondly, users can put outdated containers on a registry, which creates interoperability, compatibility or performance problems for the business. In Docker parlance, a repository is a collection of container images with the same name, distinguished by tags, placed in the registry.
When a publisher pushes a container image to a remote registry, Docker Engine applies a cryptographic signature to the container image, using the publisher’s cryptographic key. The signed image can be pulled from the registry by users, at which point Docker Engine uses the original publisher’s public key to verify it is the same. This key check only verifies that the image is the original file, unaltered. Docker Content Trust does not certify the suitability or performance of a container for any particular task. It is possible to pull a verified container image, only for that container to generate errors or perform poorly because it is not production-ready. A user can still upload a malicious container image, and Docker Content Trust will sign the image. Public registry and repository users still bear the responsibility to test and vet a container image.
DCT Components
Docker Content Trust security advantages
The verification system helps guard against man-in-the-middle attacks, as it prevents an attacker from secretly forging or tampering with content. DCT also prevents replay attacks, wherein valid actions are copied and replayed by attackers to fool a system. For example, DCT timestamps prevent attackers from passing off older (typically compromised) images from being passed off as most recent. The TUF framework and use of multiple keys allow DCT to guard the system against tagging key compromise, and allow publishers to change tagging keys on demand, without disrupting users.
Docker designed the Content Trust feature to be unobtrusive for developers that upload images and the people who use this content. Content publishers do not have to learn new commands, or change workflows, but they do need to create and manage keys. Users are completely insulated from the digital signage system, and can use the same push, pull, build, run and other commands as they would without Docker Content Trust.
Check Signature of Simplifier Image
To verify the Image you can run the below command
docker trust inspect --pretty simplifierag/runtime:6.5
If the Docker Image is one of the original simplifier image, you will get the following output
SIGNER KEYS
simplifier 30aa71c9ab2a
Repository Key: 7a50f4ba027a885a670160d307f02bee85085bffa104c1b200a8d2753d3fd7db
Root Key: 412960d3c77b40d688b37a57acd6a683cf30c5afe0b510f89d10005aafbf20bf