Page Comparison

1

Summary of development activities

Summary of ongoing development activities.

2

Security Server Sidecar with remote database

Now that we have support for X-Road packages without depending on a local PostgreSQL installation, we have also looked at adding support for it to the Security Server Sidecar Docker image. The way that the X-Road package works is that we have a separate version on the package that doesn't require PostgreSQL as a dependency and then a default one, which does. On the Sidecar, we determined that this left us with the following options for supporting it:

1. Introduce an additional Sidecar image without a local PostgreSQL which is meant to be used alongside an external database

   •  Existing users who already deployed the sidecar with a local database wouldn't need to adjust

   •  We already have 23 different Sidecar variants. If we'd have an additional image for every existing variant, this would mean 46 images altogether

2. Remove the local Postgres from Sidecar images altogether (e.g. since version 7.2.0)

   •  No additional images

   •  We'd force the users to use deploy images "the right way", as having a database in the same container as the app is an anti-pattern in the Docker world

   •  Extra effort is required from end users to adjust

     • Must provide documentation on how to migrate the database to another container and connect the two

3. We leave sidecar images as-is, i.e. always with a local Postgres installation

   • No development resources are required

   •  The Sidecar image allocates an extra 150MB of space, which is just waste when in actuality the Sidecar is used with an external database

For option two, NIIS will provide the following to make the transition smoother:

Guide(s) or tools for existing users to support and simplify database migration. As the amount of different setups might potentially be very large, we would cover the following cases:

• Automated migration for docker-compose with the official Postgres image

• Automated migration for Kubernetes with the official Postgres image

• A high-level guide for other cases

In October 2022, the X-Road Working Group decided that alternative 2 will be implemented. Special attention will be given to the deprecation path so that users don't accidentally install the latest version automatically and break their environment. Most likely the best approach is to deprecate the current image and move it to a new name.

3

Security Server Toolkit handover from DVV to NIIS

We have released version 4.0.0 of the X-Road Security Server toolkit, the first official release by NIIS following the handover from DVV. The release switched the default certificate profile from the Finnish certificate profile to the EJBCA one. It also introduced support for the Estonian SkKlass3 certificate profile.

The toolkit currently supports Ubuntu versions 18 and 20, with the packages available on a PyPy repository hosted on our Artifactory at https://artifactory.niis.org/artifactory/xroad-extensions-release-pypi/.

For more information about how to install and use the toolkit, please refer to the documentation available at https://github.com/nordic-institute/X-Road-Security-Server-toolkit/blob/master/docs/xroad_security_server_toolkit_user_guide.md.

4

Serving Global Configuration over HTTPS

Currently, global configuration is served plaintext over HTTP. The authenticity and integrity are guaranteed using digital signatures. However, the use of HTTP exposes global configuration to some other threats which is why it would be better to distribute it over HTTPS.

In general, moving the global configuration to HTTPS would require the following steps:

• a proxy should be configured that provides the configuration over both HTTP and HTTPS to do the transition

• the proxy should have TLS configured with a certificate signed by a well-known CA (e.g. Let's Encrypt)

• the host URL must match the configuration source URL

• the configuration anchor generation needs a minor code change to be able to generate HTTPS URLs

• the new configuration anchor with HTTPS URLs needs to be distributed to the Security Servers

• no code changes required on the configuration client side

• once all the servers have the new anchor, HTTP can be disabled on the Central Server.

The above method would not provide TLS authentication (there is no guarantee that the Central Server is authentic) since the TLS certificate needs to be a general one. Of course, global configuration itself is signed and verifying the signature proves its authenticity. Adding TLS authentication requires more work, and can be implemented in two different ways:

1. One-way TSL - Central Server is authenticated.

   1. Anyone can download global configuration.

2. Two-way TSL - configuration client and Central Server are authenticated.

   1. Only authenticated configuration clients can download global configuration.

To implement alternative 1, one possibility is to sign the global configuration delivery TLS certificate using the same key that is in the configuration anchor (=global configuration sign key), and the configuration client is modified to require HTTPS and to verify the certificate against the key in the anchor (and to not accept other CAs). However, this would not provide any guarantees about the party downloading the configuration (that is, the Central Server can not authenticate the Security Server downloading the configuration).

Instead, implementing alternative 2 is more complicated (e.g., how to initialize a Security Server without a valid certificate - global conf is downloaded during the initialisation process), but it would make global configuration more secure since only Security Servers with a valid certificate could access it. For example, currently, global configuration is publicly available when federation is enabled.

In June 2022, the X-Road Working Group decided that alternative 1 (One-way TSL - Central Server is authenticated) will be implemented. The implementation will be included inversion 7.3.0 (Q2/2023) or 7.4.0 (Q4/2023).

5

Open topics

Discussion on open topics.

Next meetings

• Meeting 7, December 14, 15:00-16:00 (EET, UTC +2)

• Meeting 8, January 11, 15:00-16:00 (EET, UTC +2)

• Meeting 9, February 15, 15:00-16:00 (EET, UTC +2)

• Meeting 10, March 15, 15:00-16:00 (EET, UTC +2)