The X-Road Security Server Sidecar is a Docker container optimized as a provider or consumer X-Road Security Server for being deployed next to an Information System. The Security Server Sidecar is intended to be running in the same context (virtual host, Kubernetes cluster, etc.) where the Information System is running. The containerized approach makes running the Security Server more cost-effective and better suited for environments where Information Systems exchanging data using X-Road are already running in containers. The Security Server Sidecar was originally developed for the Finnish Digital Agency and is published as free MIT-licenced open source component through X-Road data exchange platform managed by the Nordic Institute for Interoperability Solutions (NIIS).
With Sidecar, the Security Server installation process becomes much simpler than setting it up in dedicated server hardware, requiring only an existing installation of Docker on a Linux platform. Windows and MacOS are not officially supported, but they may be used for test and/or development purposes.
The X-Road ecosystem member can run one of the several Security Server Sidecar images published on NIIS Dockerhub repository. Some user-defined parameters are required, such as X-Road database and Admin UI credentials and software token PIN, to ensure the configuration for the Security Server Sidecar running on the container is unique. During the first run of the Security Server Sidecar container, the entrypoint script generates unique internal and admin UI TLS keys and certificates and configures custom admin credentials and software token PIN code for the user.
The Security Server Sidecar provides the option to configure an external database instead of the default local one by providing the remote database name, port and superuser credentials as parameters. It also supports a variety of cloud databases including AWS RDS and Azure Database for PostgreSQL. This deployment option is useful when the cloud-native database is the preferred choice.
The X-Road ecosystem member can make use of different Security Server Sidecar Docker image versions. Each image version installs a custom set of pre-built X-Road Security Server modules. Depending on the image version they want to use, it will install the basic X-Road Security Server modules or additional ones. For example, the 6.25.0 version of the Security Server Sidecar includes message log, operational monitoring, and environmental monitoring modules, whereas the 6.25.0-slim version does not include them. In both cases, the Security Server Sidecar can be used for both consuming and producing services, although the slim version is recommended for the service consumer role. Additionally, there are some country-specific configuration versions available, such as the 6.25.0-fi version including the Finnish meta-package configuration (currently the only one).
One of the advantages of using the Security Server Sidecar is that it runs alongside the client’s or service’s Information System on the same host but in a separate container. Security Server Sidecar container can serve one or more Information Systems on the same cluster. Later, the Security Server Sidecar can be scaled up and down independently from the Information System in the cluster to accommodate the fluctuation of requests. However, in this deployment scenario, the footprint of the Sidecar container is relatively high compared to the footprint of average containers and it must be taken into consideration for dimensioning the cluster size appropriately.
When Security Server Sidecar is run in a production system, it’s not acceptable to have a single point of failure. Fortunately, the Security Server supports high-availability configuration via internal load balancing mechanism. This configuration is natively supported. For the purpose, user needs to configure several Security Server Sidecar containers with the same combination of member/member class/member code/subsystem/service code. The X-Road Central Services will then route the request to the Security Server Sidecar container that responds the fastest.
External database and volumes
Another benefit of using the Security Server Sidecar is that it can use either a local database running inside the container or a remote database running externally. Since the Security Server is a stateful application, it is strongly recommended to configure the Sidecar container to use volumes and external database to persist information outside the Security Server Sidecar container in a production environment so that the Security Server Sidecar configuration is not lost when the container is destroyed. Docker volumes allow using the same configuration for several Security Server Sidecar containers, making it possible to keep the configuration even if the Security Server Sidecar container is removed or updated. The Security Server Sidecar can easily be updated by creating a backup, running the image with the new version, and restoring the backup or re–using the volume with the previous configuration. A major version update may require changes, so before updating the Security Server Sidecar, it is always advisable to check the specific version release notes for the version update.
From a security point of view, Docker guarantees that applications running on containers are completely isolated from each other. However, running the Security Server Sidecar in a Docker container has some security risks derived from the separation of the application layer and the infrastructure layer. The user should carefully review some of the Docker security best practices for securing the Security Server Sidecar container. A comprehensive Security guide can be found on the Security Server Sidecar documentation, which describes the most relevant recommendations to avoid common security pitfalls.
To avoid unrelated services or containers running on the same host to reach the Security Server Sidecar, a user-defined bridge network should be employed, allowing only containers attached to that network to communicate with each other. It is also strongly recommended to store configuration files with sensitive information into volumes outside the Security Server Sidecar container.
More information about sidecar:
Finnish Digital and Population Data Services Agency: A new highly requested sidecar option