New year new ideas. I thought it would be nice to write down some news I stumble upon and I think are worth sharing. Long story short, lets get to the news.

Red Hat Developer Hub breaking changes: dynamic plugins

At the end of the year I saw that my own managed instance of Developer Hub was down. Of course, the culprit were some breaking changes and because I’m deploying the bleeding edge latest is greatest version which upgrades automatically.

A quick look at the logs showed that the init container which installs the dynamic plugins is running into errors. The last time I checked and worked on this deployment was at version 1.2. The current release is 1.3, so I checked the release notes of these two versions:

The breaking changes were due to renamings of the janus plugins. The Janus project is the Red Hat Developer Hub downstream project, or, more precisely, it WAS the downstream project. The project was dissolved and development flowed directly into the upstream backstage or Developer Hub project.

What helped me solving the renaming issue was, looking into the dynamic plugins defaults which are shipped in every 1.4 instance. I compared each dynamic plugin which runs into errors and found the correct name easily. Most of the changes were the renaming from janus-idp to backstage-community.

Here’s a link:
https://github.com/janus-idp/backstage-showcase/blob/release-1.4/dynamic-plugins.default.yaml

Red Hat Developer Hub App Arcade Pages

There’s a very helpful application to create our demos more interactively: App Arcade. This tool offers the possibility to create documented click dummies from screenshots to tell a more coherent story.

An engineering team at Red Hat has created a collection of App Arcade pages for Developer Hub. And there are more to come.

Here’s the link: https://app.arcade.software/share/collections/OYnKUgFimiemJrmr0MVC

Volkswagen data leak @38c3 2024 - Quarkus, Connectivity Link, ACS

At the end of 2024, the 38c3 (Chaos Communication Congress) took place in Hamburg and a problem in the Volkswagen software was uncovered. Here is the recording (in German): https://streaming.media.ccc.de/38c3/relive/598

The reason for the data leak was that the developers of their Spring software had left the actuator and in particular the path <url>/actuator/heapdump enabled in production software. This allowed the guys from the CCC to create heap dumps and perform data analysis.

1. Fix Spring configuration

The obvious solution is to fix the Spring configuration. The issue was quickly resolved, so I suppose that’s what the Volkswagen development team (Cariad) did. They deactivated all actuator endpoints except the health endpoint in the application.properties file:

management.endpoints.enabled-by-default = false
management.endpoint.health.enabled = true

2. Use Quarkus

I asked the in the quarkus forum, if Quarkus has any heap dump endpoints. And the answer was: No, it doesn’t. Heapdumps are only possible to create locally. So, using Quarkus instead of Spring, would be a good solution. With Migration Toolkit for Applications we also have a super easy way to migrate from Spring to Quarkus. And on top of that, Quarkus has a Spring API compatibility, if you don’t want to make any code changes Quarkus has you covered.

Another idea was, to have a more language independent solution. Whitelisting of all of the supported paths would it make possible to deactivate <url>/actuator/heapdump and still have the health endpoint available. Without the need to touch the application codebase.

Issues with languages and frameworks always can occur, this is the most flexible and fast solution.

There’s also an app arcade for connectivity link: https://developers.redhat.com/products/red-hat-connectivity-link/getting-started#seeItInAction

4. Use Advanced Cluster Security

The last idea was to use Advanced Cluster Security (ACS). ACS is a security solution for OpenShift, which allows you to define policies for your applications. With ACS you could define for example that a /actuator/heapdump path is not allowed. This solution would result in a logged error and the pod would not be able to startup.

This solution would make the error more transparent but wouldn’t solve it. On the other hand it is possible to add guidance in the policy on how to solve this issue.

Summary/My 5 cents

There are many possible solutions to the problem. They are not mutually exclusive, so the best thing would be to try everything.